Scrum и XP: заметки с передовой

Если вы действительно хотите разобраться, как планировать релиз, советую пропустить эту главу и купить книгу Майка Кона «Agile Estimating and Planning». Эх, прочитать бы мне эту книгу раньше… (она попалась мне уже после того, как мы на собственном опыте поняли, что к чему…). Мой способ планирования простой, как угол дома, но может послужить вам хорошей отправной точкой.

Определяем свою приёмочную шкалу

В дополнении к обычному product backlog, product owner определяет приёмочную шкалу, которая представляет собой ни что иное, как простое разбиение всех историй product backlog’а на группы в зависимости от их уровня важности в контексте контрактных обязательств.

Вот пример диапазонов из нашей приёмочной шкалы:

• Все элементы с важностью >= 100 обязаны быть включены в версию 1.0, иначе нас оштрафуют по полной программе.

• Все элементы с важность 50-99 должны быть включены в версию 1.0, но в случае чего мы можем выкатить эту функциональность в следующем дополнительном релизе.

• Элементы с важностью 25-49 необходимы, но могут быть сделаны в последующем релизе версии

• 1.1.

• Важность элементов < 25 весьма спорна, так как возможно, что они вообще никогда не пригодятся.

Вот пример product backlog’а, раскрашенного в соответствии с вышеописанными правилами:

Красные = обязательно должны быть добавлены в версию 1.0 (банан - груша)

Жёлтые = желательно включить в версию 1.0 (изюм - лук)

Зелёные = могут быть добавлены позже (грейпфрут - персик)

Итак, если к крайнему сроку мы закончим всё: от банана до лука, то нам бояться нечего. Если время будет нас поджимать, то мы ещё успеем выкрутиться, убрав изюм, арахис, пончик и лук. Всё, что ниже лука - бонус.

Оцениваем наиболее важные истории

Чтобы спланировать релиз, product owner’а нужны оценки, как минимум оценки всех включенных в контракт историй. Как и в случае планирования спринта, это - коллективный труд команды и Product owner’а. Команда планирует, а product owner объясняет и отвечает на вопросы.

Оценка считается ценной, если впоследствии она оказалась близкой к реальности. Менее полезной, если отклонение составило, скажем, 30%. И абсолютно бесполезной, если она не имеет ничего общего с реально потраченным временем.

А вот что я думаю о зависимости ценности оценки от того, кто и как долго её делает.

Резюмируя вышесказанное:

1. Пусть команда проведёт оценку.

2. Не давайте им тратить на это много времени.

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

Обычно product owner собирает всю команду, делает вводный обзор и сообщает, что целью этого совещания является оценка двадцати (например) наиболее значимых историй из product backlog’а. Он проходится по каждой истории и позволяет команде приступить к процессу оценки. Product owner остаётся с командой, чтобы, в случае необходимости, отвечать на вопросы и прояснить объём работ историй. Так же, как и при планировании спринта, колонка «как продемонстрировать» - отличное средство, чтобы избежать недопонимания.

Совещание должно быть строго ограниченным по времени - команды склонны тратить очень много времени на оценку всего нескольких историй.

Если product owner захочет потратить больше времени на оценку, он просто назначит другое совещание позже. Команда должна убедиться в том, что product owner осознаёт, что проведение подобных совещаний отразится на их текущем спринте. То есть, что он понимает, что за все (и за оценку в том числе) нужно платить.

Ниже приведен пример результатов оценки (в story point’а):

Прогнозируем производительность

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

Это значит, что для начала мы должны определить наш фокус-фактор (см. стр. 23 «Как команда принимает решение о том, какие истории включать в спринт?»)

По большому счёту, фокус-фактор показывает: «насколько эффективно команда использует своё время для работы над выбранными историями». Это значение никогда не достигнет 100%, так как команда всегда тратит время на незапланированные задачи, помощь другим командам, переключение между задачами, проверку электронной почты, ремонт своих поломанных компьютеров, политические дебаты на кухне и т.д.

Предположим, что фокус-фактор нашей команды равен 50% (это достаточно низкое значение, у моей команды значение колеблется в районе 70%). Допустим также, что длина нашего спринта будет 3 недели (15 дней), а размер команды - 6 человек.

Таким образом, каждый спринт - это 90 человеко-дней, однако, в лучшем случае мы можем надеяться только на 45 человеко-дней (так как наш фокус-фактор составляет всего 50%).

Следовательно, прогнозируемая производительность составит 45 story point'ов.