Борис Вольфсон - Гибкое управление проектами и продуктами

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

Очень важно помнить, что оценка должна быть именно консенсусной, а не оценкой большинства. Сюда же можно отнести и давление со стороны более авторитетных членов команды.

Для относительной оценки необходимо выбрать эталонную историю пользователей. Она должна быть:

• простой и понятной для команды;

• типичной для данного проекта;

• небольшого размера.

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

Эту историю пользователя команда принимает за 1 «пункт». Тогда история пользователя, которая будет в два раза меньше эталонной, будет иметь размер 1/2 «пункта», а история пользователя, которая в пять раз больше эталонной, будет иметь размер 5 «пунктов». Таким образом, «пункт» – это относительная безразмерная единица измерения.

Для оценки используется дискретная логарифмическая шкала:

Причем оценки в 40 и 100 «пунктов» за пользовательскую историю применяются для эпиков и считаются неточными. Такая шкала относит к одному размеру истории пользователя в 20 и 21 «пункт», но к разным – задачи в 2 и 3 «пункта».

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

Шкала размеров историй пользователей

Получается, что с каждой новой оцененной историей пользователей у нас появляются новые «эталоны» для сравнения.

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

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

Карты выкладывают рубашкой вверх

После этого все карты одновременно переворачиваются.

Карты одновременно переворачиваются

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

Скрам-мастер должен следить за временем, в течение которого длится обсуждение истории пользователей. По истечении времени происходит второй раунд и дальнейшее обсуждение.

Обычно разброс оценок снижается с каждым последующим раундом и сходится к консенсусной оценке.

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

Обсуждение начинается с участников с минимальной и максимальной оценкой

Второй раунд

Консенсусная оценка

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

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

Скорость команды за последние восемь спринтов

На схеме, изображенной ниже, в спринт отбираются истории пользователей A, B, C, D и F.

Отбор элементов журнала пожеланий продукта в журнал пожеланий спринта

Для мониторинга прогресса в Scrum используется специальный график – диаграмма сгорания (Burndown Diagram). По горизонтальной оси на таком графике откладываются дни спринта, а по вертикальной – количество оставшихся «пунктов» и/или закрытых историй пользователей. Дополнительно строится идеальная диаграмма сгорания, которая показывает запланированный ход работ.

Диаграмма сгорания показывает, что спринт завершился в соответствии с планом

В дальнейшем анализ будем проводить по количеству оставшихся «пунктов», но все сказанное может распространяться и на истории пользователя.

Анализ производится путем сравнения реального графика с идеальным:

• если реальный график выше идеального, значит, команда отстает от плана;

• если реальный график ниже идеального – команда опережает план.

Анализ диаграммы сгорания во время спринта.Для единообразия анализ будем проводить на пятый день спринта, хотя на практике диаграмму сгорания можно использовать с третьего дня для выработки корректирующих действий.

Рассмотрим самую стандартную ситуацию – с отставанием от графика.

Отставание от плана

Команда должна на очередном скрам-митинге обсудить, почему очки за пользовательскую историю сгорают так медленно, и выработать контрмеры. Самые распространенные причины следующие: