Подводные камни при осмечивании в Agile разработке

Перевод статьи Дэна Норта "The perils of estimation"


Бизнесмены хотят видеть сметы. Они хотят знать сколько будет стоить решение, и они хотят знать насколько реально вложиться в сроки и бюджет. И качество, конечно, не является предметом торга.

Agile-команды, которые я встречал, в лучшем случае очень нервничали, когда речь заходила о сметах, а в худшем – просто их игнорировали. «Вам не нужны сметы, если вы работаете по Agile» - говорят они. «Всё будет готово, когда мы всё сделаем. Мы постоянно добавляем коммерческую ценность, поэтому нет необходимости привязываться к срокам».

Мы теряем сам смысл планирования релиза

Мой любимый диалог с заказчиком:

- «Мы провели обследование, разложили весь проект на пользовательские истории и оценили их. В итоге у нас есть 400 историй с оценкой в 865 стори-пойнтов (story points)».

- «865 чего?»

- «865 стори-пойнтов.»

- «А сколько это - 1 стори-пойнт?»

- «Пока что мы не можем вам этого сказать. Должно пройти несколько недель.»

На управленческом и финансовом уровне бизнес не очень-то интересуют стори-пойнты. Их вообще не волнуют пользовательские истории, до тех пор пока они их не увидят в наших планах релизов. Их интересует решение проблемы. Они приходят к нам и спрашивают:

А) сколько стоит решение их конкретной проблемы?

Б) насколько точно мы обозначили эту стоимость?

Итак, какой мы применяем подход? Мы производим некое начальное обследование, которое будет проходить примерно так:

1. Выделим некие Роли
2. Выделим некие потоки процессов
3. Начнём разбивать потоки на пользовательские истории
4. Много и много пользовательских историй
5. Много и много, и много, и много пользовательских историй
6. Проработаем некоторые технические идеи, которые выходят за рамки историй
7. Оценим истории
8. Подытожим все оценки и назовём этот итог оценкой проекта

Та часть, где мы оцениваем истории – это та ещё работёнка (на секундочку – мы ведь оцениваем 400 историй!), поэтому мы срезаем углы. Мы делаем первый проход, применяя размеры футболок (S, M, L), и затем берём типичный образец (звучит подходяще и по-научному) и производим «детальную» оценку. Для этого мы привлекаем несколько людей, рассчитывающих множество звучащих по-серьезному метрик: минимальный размер, предположительно максимальный размер, четкость, изменчивость (да?) и что-то там ещё, и затем это всё перемножаем, чтобы получить – ВААААУУУУУУУ! Обождите минутку… Что мы творим?

Всё, что они хотели знать – это сроки решения и насколько мы отвечаем за реальность обозначенных сроков.

Переосмысление успеха – по-плохому

Составляя комплексный список историй – с или без расчета стори-пойнтов – мы невольно переформатируем проект. Бизнес начал с того, что определил успех проекта как решение его проблемы, но теперь мы переопределили успех как «поставка этого списка пользовательских историй». Тем не менее мы задали рамки проекта, и бизнес поверил в это. Проект начнётся и люди от бизнеса начнут отсчитывать количество выполненных историй из списка, пока вы не дойдёте до конца.

Итак, теперь мы попали в худший из возможных миров (и не Agile, и ни жёстко-спланированный): бизнес ожидает поставку детализированного списка требований (неважно как мы его назовём Бэклог Продукта или Главный Список Историй), а мы только провели половинчатую попытку проработать его, по сравнению с тем большим предварительным анализом, который мы обычно делаем. С этого момента мы начинаем «давать заднюю», постоянно переговариваясь с бизнесом, чтобы управлять границами проекта, когда это наша собственная вина – они даже начинают вдаваться в подробности пользовательских историй. Они видят бэклог историй и в уме проворачивают его на 90 градусов, и рассматривают его как диаграмму Гантта. Счастливые времена!

Возвращаемся к истокам проекта

Есть два наблюдения, о которых нужно сейчас сказать. Первое: бизнес хочет чёткости, а мы ему даём приблизительность. Если вы скажете мне, что это займёт 4.632 месяца, а по факту окажется 8 месяцев – то это хуже, чем бесполезно. Если вы скажете мне, что это займёт «около 6-ти месяцев», а по факту окажется 7 – я всё ещё смогу чувствовать себя победителем. Если возврат инвестиций настолько мал, что превышение срока на один месяц делает предложение не жизнеспособным, то я прежде всего предпочту инвестировать во что-то другое. Вкладывать $60’000, ожидая возврата в $70’000 – по крайней мере рискованно. Я здесь, конечно, упрощаю, потому что реальный RoI может меняться со временем, и его значение может быть особенно чувствительно ко времени.

Во-вторых, мы знаем, что в Agile-проектах требования могут меняться со временем по вполне уважительной причине. Обнадёживает тот факт, что мы обучаемся по мере продвижения вперёд, что значит мы открываем новые потребности заказчика, и решаем, что другие истории потеряли актуальность. Если мы допускаем, что треть требований будут реализованы, как описаны (это обычное дело в свете отчётов Standish Chaos), другая треть будет реализована, но с изменениями, а последняя треть вообще не будет реализована – но заменена другими функциями – тогда это значит, что мы потратили время и усилия на начальном этапе, исследуя детальные, высокоточные данные для целой кипы историй, которые мы никогда не реализуем.

Соединив всё это, нужно признать, что оценка обладает свойством фрактальности. Чем более детально вы будете разбирать требования, тем больше «граней» вы найдёте. Это значит, чем детальнее вы оцениваете, тем скорее итоговая оценка начнёт стремиться к бесконечности, просто из-за ошибок округления и наших факторов страха, на которые мы будем умножать детализированные оценки.

Используйте начальный этап для «целенаправленного исследования»

Так что же мы должны делать на начальном этапе, если не разбивать процессы на атомарные пользовательские истории? Возвращаясь к первоначальным принципам: нам просто нужна грубая прикидка размера проекта и понимание определенности. Доля неопределенности всегда остаётся, поэтому цель начального этапа понять «масштаб трагедии», с которой нам нужно работать.

Когда мы приступаем к начальному этапу – мы ничего не знаем. Мы хотим получить на выходе начального этапа такой объём информации, какой мы реально можем изучить за оговоренные сроки. Это обследование должно развиваться по нескольким направлениям: технические области – такие как технологический стек, потенциальные архитектуры, точки интеграции и внешние сервисы, вопросы по предметной области – такие как: насколько хорошо мы понимаем суть задач и нужно ли дополнительное исследование, чтобы выявить другие задачи, кроме очевидных; человеческие и процессные сложности – особенности производственного процесса, определение ответственных лиц, насколько территориально распределена команда и насколько она компетентна в предметной области проекта. По некоторым из этих направлений детализация нечётко сформулированных требований – это прекрасный способ узнать больше. Но не для всех направлений, и конечно же не за счет других исследовательских действий.

Есть неплохие аргументы от ребят, практикующих методики Канбан и Real Options. Они рекомендуют откладывать декомпозицию наборов «фич» до непосредственно «фич» и пользовательских историй до «часа Ч». Это означает, что к этому самому «часу Ч» вы будете обладать свежайшей информацией, и на вас не будет давить багаж атрофировавшихся данных. Скорее всего вы всё равно захотите потратить пару недель начального этапа для выделения пользовательских историй – чтобы содействовать последовательному развитию процесса и избежать простоев – тем не менее, вы не должны беспокоиться о степени детализации тех нескольких «фич», которые были выбраны для декомпозиции до пользовательских историй.

Опытные члены команды должны будут оценить наборы «фич» с точностью до человеко-недель (или лучше даже пара-недель), не опускаясь до уровня индивидуальных пара-дней. Менее опытные товарищи должны использовать это упражнение как возможность узнать больше.

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

Его цель в первую очередь донести до наших заказчиков и до нас самих «масштаб трагедии» (размер проекта) - если процитировать Прагматичных Программистов: проект больше, чем хлебница, и меньше, чем дом? И во-вторых – представить карту рисков, по которой можно расшифровать эту оценку.


Chief technology officer "Один Сервис.ВЦ" - Денис Олейник