Иногда нужно планировать дальше, чем на один спринт вперед. Это типичная ситуация для контрактов с фиксированной стоимостью, когда нам приходится планировать наперед, или же есть риск подписаться под нереальной датой поставки.

Как правило, планирование релиза для нас — это попытка ответить на вопрос: «когда, в самом худшем случае, мы сможем поставить версию 1.0».

Если вы действительно хотите разобраться, как планировать релиз, советую пропустить эту главу и купить книгу Майка Кона «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'ов.

Если у каждой истории оценка будет равна 5 дням (хотя такого и не бывает), тогда эта команда сможет выдавать на-гора примерно по 9 историй за спринт.

Сейчас, когда у нас есть оценки и прогнозируемая производительность, мы можем легко разбить product backlog на спринты:

Каждый спринт состоит из набора историй, количество которых не превышает спрогнозированную производительность 45.

Теперь видно, что, скорее всего, нам потребуется 3 спринта для завершения всей обязательной и желательной функциональности.

3 спринта = 9 календарных недель = 2 календарных месяца. Станет ли это крайним сроком, который мы озвучим клиенту? Это полностью зависит от вида контракта, от того, насколько фиксирован объем работ, и т. д. Обычно мы берём время со значительным запасом, тем самым защищая себя от ошибочных оценок, возможных проблем, неоговоренного функционала и т. д. Значит, в этом случае мы установим срок поставки в 3 месяца, чтобы иметь месяц в резерве.

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

Реальность не подстроится под план, поэтому приходится его корректировать.

По окончании спринта мы смотрим на реальную производительность команды. Если эта производительность существенно отличается от прогнозируемой, мы изменяем прогнозируемую производительность для будущих спринтов и обновляем план релиза. Если это грозит нам срывом срока поставки, product owner может начать переговоры с клиентом или начать искать путь уменьшения объема работ без нарушения контракта. Или, возможно, он и команда смогут увеличить производительность или фокус-фактор путём устранения серьёзных препятствий, которые были обнаружены во время спринта.

Product owner может позвонить клиенту и сказать: «Привет, мы слегка не вписываемся в график, но я полагаю, что мы сможем уложиться в срок, если уберём встроенный Тетрис, разработка которого занимает много времени. Мы можем добавить его в следующем релизе, который будет через три недели после первого релиза».

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