Home > Blog > Оценка времени в SCRUM: конспект семинара Майка Виздоса

Оценка времени в SCRUM: конспект семинара Майка Виздоса

Опубликовано: 30/10/07

По следам семинара от 17 октября

Как оценить количество времени для решения задачи? Оценка решения в часах будет самой общепринятой — и самой непонятной, а возможно и неверной (когда речь идет о времени человек склонен преувеличивать или преуменьшать)

Более правильно будет оценивать задачи мерой трудоемкости — но это слишком тяжелое понятие для постоянного оперирования. Используемая в SCRUM методика оценки — оценка в безразмерных единицах Story Point (пользовательская история — то есть конкретная маленькая задача пользователя в рамках разрабатываемой системы).

Как и почему работает безразмерная оценка? На семинаре был приведен хороший пример абстрактного оценивания:

Командой оценить в абстрактных «собачьих баллах» (dog points) следующие породы собак:

  • лабрадор
  • такса
  • дог
  • терьер
  • овчарка
  • сенбернар
  • бульдог
  • пудель

(никакой начальной информации о критерии оценки нет, команда вырабатывает этот критерий самостоятельно). Для вновь сформированных команд оказалось достаточно легко договориться о величинах оценки (так, в команде, членом которой был я, мы выбрали в качестве базовой таксу, и оценивали все оставшиеся породы по сравнению с ней. Очень напоминает измерение удава в попугаях и мартышках :) )

Ок, безразмерная оценка действительно работает, но как ее применить в конкретном программном проекте? Как её производить?

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

Для независимой оценки трудоемкости (после выбора эталонного SP) можно применить так называемый Pocker Planning: каждому из членов команды, участвующему в обсуждении выдается набор карт(очек), на которых проставлены конкретные числа — стоимости в SP (стандартный набор : 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 + «?» и «перекур»). Ставится вопрос о трудоемкости задачи, после чего каждый из участников кладет карточку со своей оценкой так, чтобы ее не видели другие. Когда все оценки сделаны — карточки переворачивают. Авторы самых оптимистичных и пессимистичных оценок высказываются, почему выбраны именно такие числа, и возникшие вопросы разрешаются. Раунд с оценкой повторяется — и так до тех пор, пока все члены команды не покажут одно и то же число, или не согласятся с большинством (важно! соглашение должно быть добровольное и сделано на основе полученной информации, а не под давлением).

Для тренировки Майк предложил классический пример для оценки трудоемкости: дан список задач по ремонту кухни, надо оценить каждую из задач. Вольный перевод части списка:

  • перестелить пол
  • заменить столешницу у рабочего стола на гранитную
  • провести встроенный свет
  • перекрасить всю кухню
  • подновить все тумбочки и шкафы (отшкурить, перекрасить и т. п.)

Свежесформированным командам предложили оценить трудоемкость каждой из задач, при необходимости используя игровое планирование (важно! по каждому пункту из списка можно было задавать уточняющие вопросы самому Майку — что значит перестелить пол, сколько лампочек нужно, сколько весит гранитная столешница — и т. д. ).
Интересен результат выполнения задания:

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

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

That's it. What Next?

Please leave your comment so we know what you think about this article. Trackback URL: Оценка времени в SCRUM: конспект семинара Майка Виздоса.