Re: Что есть value?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.11.12 13:54
Оценка: 1 (1) +1
Здравствуйте, 0x7be, Вы писали:

0>Коллеги,


0>в различных описаниях и дискуссиях на тему agile я часто вижу, что, мол, важно делать "deliver value" с самого начала, причем этот "value" активно противопоставляется разного рода документации. А есть ли где-нибудь глубокое раскрытие темы, что есть "value" и что этим "value" не является?


Value это то, за что клиент готов заплатить деньги.

За что клиенты не готовы платить:
1) "крутость" технологических платформ, языков, фреймворков
2) ускорение в два раза операции, которая выполняется раз в неделю
3) "качество кода"
4) "правильную архитектуру"
5) "исчерпывающую" документацию
6) покрытие тестами
7) Количество функций

За что клиенты платят с радостью:
1) Достижения своих целей с помощью вашего продукта
2) "Человечность" программы
3) Удобство использования
4) Стабильность и предсказуемость
5) Визуальная привлекательность
Что есть value?
От: 0x7be СССР  
Дата: 04.11.12 19:26
Оценка:
Коллеги,

в различных описаниях и дискуссиях на тему agile я часто вижу, что, мол, важно делать "deliver value" с самого начала, причем этот "value" активно противопоставляется разного рода документации. А есть ли где-нибудь глубокое раскрытие темы, что есть "value" и что этим "value" не является?
Re: прок. польза. реальное решение для реальной проблемы
От: ilya.buchkin США http://engineering.meta-comm.com/
Дата: 04.11.12 20:59
Оценка:
0>в различных описаниях и дискуссиях на тему agile я часто вижу, что, мол, важно делать "deliver value" с самого начала, причем этот "value" активно противопоставляется разного рода документации. А есть ли где-нибудь глубокое раскрытие темы, что есть "value" и что этим "value" не является?

не знаю найдется ли где глубокое раскрытие, потому как это не есть "термин" из agile
это как бы понятие из культурологического контекста
мое понимание его сводится примерно к этому:
value = прок; польза; реальное решение для реальной проблемы
--
Ilya Buchkin
MetaCommunications Engineering, Iowa City — Санкт-Петербург
Re[2]: прок. польза. реальное решение для реальной проблемы
От: 0x7be СССР  
Дата: 05.11.12 06:43
Оценка:
Здравствуйте, ilya.buchkin, Вы писали:

IB>не знаю найдется ли где глубокое раскрытие, потому как это не есть "термин" из agile

IB>это как бы понятие из культурологического контекста
Вот именно, что когда говорят об agile, то часто ссылаются на "value" (иногда "business value"), но явно не раскрывают, что имеют в виду, полагая это чем-то известным.

IB>мое понимание его сводится примерно к этому:

IB>value = прок; польза; реальное решение для реальной проблемы
Ну, на таком уровне и мне понятно

А вот у меня недавно возник спор с коллегой на эту тему. Я отстаивал позицию, что value — это то, что потребляют конечные пользователи (работающий софт, пользовательская документация), а он отстаивал мысль, что документ с архитектурой, разработанный заранее, или прототипы, устраняющие технические риски — это тоже value. Этот спор ясно высветил, что понятие слишком нечеткое.
Re[3]: прок. польза. реальное решение для реальной проблемы
От: ylem  
Дата: 05.11.12 07:24
Оценка:
Вполне себе чоткое понятие. Польза по определению субъективна. Для вас устранение рисков -- прок.

Смысл, видимо, в том, что каждый раз собираясь начать рисовать "документ с архитектурой" нужно помнить, что деньги клиент в итоге не за него отвалит (если это не гос.заказа, естественно, там вэлъю другие)
Re[3]: прок. польза. реальное решение для реальной проблемы
От: ilya.buchkin США http://engineering.meta-comm.com/
Дата: 05.11.12 07:33
Оценка:
IB>>это как бы понятие из культурологического контекста
0>Вот именно, что когда говорят об agile, то часто ссылаются на "value" (иногда "business value"), но явно не раскрывают, что имеют в виду, полагая это чем-то известным.
естественно. оно и есть известное и понятное всем — на то есть тот самый культурологический контекст.
если вам лично неизвестно — так это потому что вы с этим контекстом не знакомы. знакомьтесь.


0>А вот у меня недавно возник спор с коллегой на эту тему. Я отстаивал позицию, что value — это то, что потребляют конечные пользователи (работающий софт, пользовательская документация), а он отстаивал мысль, что документ с архитектурой, разработанный заранее, или прототипы, устраняющие технические риски — это тоже value. Этот спор ясно высветил, что понятие слишком нечеткое.


коллега прав.
понятие value (или business value, или tangible value) лежит в плоскости, которая выше технических терминов или определений.
оно именно что предлагает подняться над определениями, которые возможны в рамках технических методов, — туда, где оперируют люди. те люди, ради которых как бы и делается некая разработка.
а там уже как получится — что этим людям принесет ощутимую пользу/прок, что решит их реальные проблемы — то и есть value.
если это на каком-то этапе оказались документация или прототипы, то так тому и быть.
--
Ilya Buchkin
MetaCommunications Engineering, Iowa City — Санкт-Петербург
Re[4]: прок. польза. реальное решение для реальной проблемы
От: 0x7be СССР  
Дата: 05.11.12 10:31
Оценка:
Здравствуйте, ilya.buchkin, Вы писали:

IB>коллега прав.

IB>понятие value (или business value, или tangible value) лежит в плоскости, которая выше технических терминов или определений.
IB>оно именно что предлагает подняться над определениями, которые возможны в рамках технических методов, — туда, где оперируют люди. те люди, ради которых как бы и делается некая разработка.
Я понимаю, как понятие может лежать "выше техники", но как "выше определений" понять не могу

IB>а там уже как получится — что этим людям принесет ощутимую пользу/прок, что решит их реальные проблемы — то и есть value.

IB>если это на каком-то этапе оказались документация или прототипы, то так тому и быть.
Вот именно, если оно решает проблемы. Другими, словами, можно после этого проект останавливать, но некоторая польза уже принесена.

Пример, в рамках которого мы обсуждали этот вопрос — это проект по оптимизации операторской работы, цель которого — снизить время обслуживания оператором одной заявки за счет автоматизации рутинных действий. Критерий оценки результата — снижение времени обслуживания зявки. Что хорошо, это измеримый критерий.

Так вот, в этом примере я считаю, что документ с архитектурой или технические прототипы высоконагруженных сервисов (в примере речь шла о нагруженной системе) не есть value, потому что сами по себе они не могут быть использованы для сокращения времени обслуживания. Но они нужны разработчкикам, что бы в будущем сделать это value.

Коллега же возражал, что и эти артефакты несут value, потому что в будущем позволят достичь цели проекта — сокращения времени обслуживания.
Re[5]: прок. польза. реальное решение для реальной проблемы
От: ilya.buchkin США http://engineering.meta-comm.com/
Дата: 05.11.12 12:52
Оценка:
IB>>понятие value (или business value, или tangible value) лежит в плоскости, которая выше технических терминов или определений.
IB>>оно именно что предлагает подняться над определениями, которые возможны в рамках технических методов, — туда, где оперируют люди. те люди, ради которых как бы и делается некая разработка.
0>Я понимаю, как понятие может лежать "выше техники", но как "выше определений" понять не могу

OK, оно не требует определения в рамках технического метода.
возможно где-то все же обсуждаются его детали или аспекты, но в дефиниции выносить нет нужды.


IB>>а там уже как получится — что этим людям принесет ощутимую пользу/прок, что решит их реальные проблемы — то и есть value.

IB>>если это на каком-то этапе оказались документация или прототипы, то так тому и быть.
0>Вот именно, если оно решает проблемы. Другими, словами, можно после этого проект останавливать, но некоторая польза уже принесена.

неплохой критерий. (особенно если добавить к "можно останавливать" еще и "пришлось останавить")


0>Пример, в рамках которого мы обсуждали этот вопрос — это проект по оптимизации операторской работы, цель которого — снизить время обслуживания оператором одной заявки за счет автоматизации рутинных действий. Критерий оценки результата — снижение времени обслуживания зявки. Что хорошо, это измеримый критерий.


этот критерий может измениться — если изменятся входные условия. (например, если внезапно закончатся деньги на проект, потому что что-то для заказчика вдруг стало более приоритетным.)


0>Так вот, в этом примере я считаю, что документ с архитектурой или технические прототипы высоконагруженных сервисов (в примере речь шла о нагруженной системе) не есть value, потому что сами по себе они не могут быть использованы для сокращения времени обслуживания. Но они нужны разработчкикам, что бы в будущем сделать это value.


0>Коллега же возражал, что и эти артефакты несут value, потому что в будущем позволят достичь цели проекта — сокращения времени обслуживания.


пользуясь критерием выше:
если этот проект остановить, то возобновление работы по этой теме в будущем будет не с нуля. это и будет value.
даже если получение такого value по тому первоначальному критерию обусловлено продолжением работы по теме — получится что деньги потрачены не впустую. и именно потому, что произведены артефакты.

так что подход коллеги получается более agile — потому как он покрывает этот дополнительный сценарий (внезапная временная смена приоритетов). во времена кризиса (что для многих начался в 2008, а для кого-то еще раньше) это весьма распространенный сценарий.


ПС.
и еще: достигнутое и зафиксированное понимание — это часто value само по себе.
--
Ilya Buchkin
MetaCommunications Engineering, Iowa City — Санкт-Петербург
Re[5]: прок. польза. реальное решение для реальной проблемы
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.11.12 14:04
Оценка:
Здравствуйте, 0x7be, Вы писали:


0>Так вот, в этом примере я считаю, что документ с архитектурой или технические прототипы высоконагруженных сервисов (в примере речь шла о нагруженной системе) не есть value, потому что сами по себе они не могут быть использованы для сокращения времени обслуживания. Но они нужны разработчкикам, что бы в будущем сделать это value.


0>Коллега же возражал, что и эти артефакты несут value, потому что в будущем позволят достичь цели проекта — сокращения времени обслуживания.


Коллега неправ. Никто прототипы и документы не купит. Более того, я сомневаюсь что оно вообще полезно для разработки будет. Потому что до реального использования не ясно какая будет нагрузка и где будет узкое место (кроме самых очевидных вещей).

Например я видел один hiload проект, в который заложили такой запас производительности\масштабируемости, что он тупо уперся в пропускную способность сети, до того как достиг 30% утилизации вычислительных ресурсов. Всех факторов учесть невозможно, поэтому проводить глубокий анализ с прототипами для hiload почти бесполезно.
Re[6]: прок. польза. реальное решение для реальной проблемы
От: 0x7be СССР  
Дата: 05.11.12 16:36
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Коллега неправ. Никто прототипы и документы не купит. Более того, я сомневаюсь что оно вообще полезно для разработки будет. Потому что до реального использования не ясно какая будет нагрузка и где будет узкое место (кроме самых очевидных вещей).

Тот пример — это разработка системы для канадских железных дорог и там было заранее известно чисто пользователей системы: ~12.000
Собственно, этот пример был приведен на CEE-SECR2012 докладчиком по теме DAD (Disciplined Agile Delivery), где он высказался в том духе, что выбор User Story по их business value — это, конечно, круто, но когда ты заранее знаешь, что делаешь нагруженную систему на 12.000 пользователей, работающую в весьма заковыристом IT-landscape`е, то надо об этом подумать заранее. Отсюда он рекомендовал поддерживать баланс между "Business value" и "Risk Mitigation".

При обсуждении этого примера с коллегой и возникло разночтение в трактовках.
Re[7]: прок. польза. реальное решение для реальной проблемы
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.11.12 19:53
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, gandjustas, Вы писали:


G>>Коллега неправ. Никто прототипы и документы не купит. Более того, я сомневаюсь что оно вообще полезно для разработки будет. Потому что до реального использования не ясно какая будет нагрузка и где будет узкое место (кроме самых очевидных вещей).

0>Тот пример — это разработка системы для канадских железных дорог и там было заранее известно чисто пользователей системы: ~12.000
0>Собственно, этот пример был приведен на CEE-SECR2012 докладчиком по теме DAD (Disciplined Agile Delivery), где он высказался в том духе, что выбор User Story по их business value — это, конечно, круто, но когда ты заранее знаешь, что делаешь нагруженную систему на 12.000 пользователей, работающую в весьма заковыристом IT-landscape`е, то надо об этом подумать заранее. Отсюда он рекомендовал поддерживать баланс между "Business value" и "Risk Mitigation".

0>При обсуждении этого примера с коллегой и возникло разночтение в трактовках.


Если оценить risk и value в деньгах, то сразу становится понятно чем надо заниматься.

Если разработка заказная и конкретный value в деньгах выразить сложно, то банально работает квадрат risk-value.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.