пятница, 27 июня 2014 г.

Зачем мы тратим время на оценки?

Эта статья подготовлена для блогов журнала PCWeek.
В современных технологиях разработки программного обеспечения одним из основных камней преткновения является оценка трудоемкости выполнения задач. Ошибка при оценке может достигать нескольких раз. Именно это демонстрирует конус неопределенности, предложенный Барри Бемом в 1981 году (изображение с сайта http://infostart.ru/):


Эта модель описывает водопадный подход к разработке. Гибкие методологии предлагают «есть слона» по частям и оценивать не весь проект, а только несколько ближайших итераций. Да и то, грубо. Наиболее распространенными в Scrum методиками оценки являются покер-планирование и оценка не стене.

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

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

Эти грубые оценки в Scrum применяются для определения  производительности команды в рамках итерации – Velocity. Ну, а выяснив производительность, можно планировать, какое количество спринтов понадобится, чтобы реализовать оставшиеся в Backlog-е требования.

Цель хорошая, а вот стоит ли тратить время на оценку в команде, которая работает длительное время? И мой ответ– нет. Посмотрим на данные команды, которая работает уже несколько лет с незначительным изменением состава.
Привожу данные за 11 спринтов с 20 декабря 2013 года по 18 июня 2014:
Рассмотрим  эти данные в разрезе спринтов.

Последняя строка - это отношение суммарного веса требований к их количеству. Бросается в глаза, что значения очень близки друг к другу. Математическое ожидание для этого отношения составляет 2,59. Дисперсия составляет всего 0,15. Эти данные позволяют сделать вывод, что дальнейшие оценки требований в этой команде не имеют смысла. Можно ставить оценку 2,59 и, в рамках итерации, большие требования, которые были недооценены, будут компенсированы маленькими требованиями, которые переоценили.
Т.е. при производительности команды в 65 единиц в спринт можно брать 25 требований из вершины Backlog-а. Это подтверждается правой частью представленной таблицы, где как раз количество требований на итерацию колеблется в районе 25-ти. В левой части в связи с новым годом и производственной необходимостью размер итерации был меньше и колебался от нескольких дней до двух недель.
Подводя итоги, можно сделать вывод, что на начальном этапе формирования команды оценки нужны, без них нельзя будет определить производительность команды, да и среднюю оценку будет не посчитать. А вот для команд, работающих достаточно длительное время, смысл такой оценки теряется.
 
 

2 комментария:

  1. Пост старый, тем интереснее, Алексей, не изменилось ли у вас мнение? Скрам как вы сами говорили, все же фреймворк. Но Agile не подразумевает "устаканивания". Разве производительность команды определяется исключительно составом команды? А зачем тогда эти ретроспективы и самоорганизация, поиск более эффективных методик и подстраивание под новые внешние вызовы и требования?

    ОтветитьУдалить
    Ответы
    1. Жизнь штука многообразная. Если вам оценки нужны только для приблизительного планирования плана релизов, то смысла в них нет. Строите контрольную карту Шухарта, смотрите какая у вас типовая производительность в штуках требований, на отклонения выходящие за 6 сигм обращаете пристальное внимание, контролируете, чтобы медиана в штуках плавно росла, ну или хотя-бы не сильно падала. Если у вас заказная разработка по фикспрайсу с фикстаймом, то вам придется оценивать и в некоторых случаях оценивать очень серьезно. Вот только как бы вы не оценивали, время от времени вы будете промахиваться. А с определенного момента увеличение времени затраченного на оценку даже не будет приводить к повышению точности этих оценок. Надо будет как нибудь еще к этой теме вернуться :)

      Удалить