Все о SCRUM. Изучение, разработка, интеграция — страница 43 из 60

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

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

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


Чтобы вычислить производительность, требуется значение скорости команды в прошедших спринтах.

В примере на рисунке 16.3 команда завершает спринт 3. Во время спринта команда завершила 4 элемента [49]. Это соответствует среднему показателю за последние два спринта – плюс текущий спринт.

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

Пример. Команда получила среднее значение 2 завершенные функциональности за спринт. Это скорость команды. В сезоне осталось 5 спринтов, поэтому при производительности, равной 2, команда ожидает к концу завершить 10 функциональностей.

Как и в случае с подсчетом историй, это упрощение возможно только при условии, если у команды хороший опыт в разделении историй.


Сколько нужно предшествующих данных о работе команды?

Как мы уже поняли, планирование основано на производительности команды, которая определяется ее скоростью, измеренной в конце спринта. Чтобы спланировать сезон, необходимо иметь достаточно данных: либо о спринтах в предыдущем сезоне, либо о спринтах в предстоящем – в этом случае придется подождать.

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

Если команда только начала работу над продуктом, она может начать планировать спустя несколько спринтов.

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

Учет сезонных изменений

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

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

Обычно команда Peetic проводит двухнедельные спринты. Она начинает спринт, но участники уходят на майские праздники. Чтобы производительность команды не сильно изменилась, продлили спринт до трех недель.

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

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

16.3.4 Отражение полученных данных в бэклоге

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

Это настолько просто, что автоматическое планирование было одной из первых функциональностей в инструменте iceScrum еще в 2007 году, когда я был Владельцем данного продукта.

16.3.5 Учет неопределенностей

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

Какие пределы можно устанавливать? Я предлагаю после проведения нескольких спринтов взять значение скорости команды в качестве стандартного отклонения.

Пределы, установленные на предстоящий спринт и на сезон, наглядно и понятно показывают, как работает этот процесс.

Есть разные способы показать пределы неопределенности (рисунки 16.6 и 16.7).

Подсчет данных за прошлые спринты позволяет нам выдвинуть следующую гипотезу: мы реализуем от 3 до 5 историй за спринт. У нас есть готовые элементы в стартовом лотке, к ним мы и применяем этот прогноз.

Рисунок 16.6 – План сезона с учетом неопределенностей


Элемент лотка в правом нижнем углу находится в первом ряду, тот, что над ним – во втором, самый верхний – в последнем. Нижняя стрелка, идущая от сезона, составляет нижний предел – минимум того, что команда в состоянии завершить. Верхняя стрелка составляет верхний предел, то есть максимум для команды. Бесполезно перегружать изображение данными о спринтах, которые будут еще совсем не скоро (в данном случае спринты 4 и 5).

Это изображение, включающее неопределенности, позволяет:

✓ убедиться, что все необходимое для сезона включено в нижний предел;

✓ легко и понятно сообщать заинтересованным сторонам о своих прогнозах.


Чем дольше команда работает в текущем сезоне, тем меньше неопределенностей, потому что появляются реальные данные о ее работе.

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

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

16.4 Обязательства в отношении плана сезона

Должна ли команда в начале сезона принимать какие-либо обязательства в отношении результата, как она это делает в начале спринта?

16.4.1 Обязательства в отношении содержания?

Прежде всего, не стоит путать прогнозирование и обязательство. План сезона состоит из прогнозов – возможно, он позволит принять обязательства.

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

Конечно, обещать что-то в отношении задач бессмысленно. Точно так же несерьезно брать на себя обязательства касательно историй: большинство из тех, что будут завершены к концу сезона, в его начале еще не известны.

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

16.4.2 Обязательства в отношении цели?

Итак, никаких обяазательств касательно содержания. А что насчет цели на сезон?

Цель сезона – та же цель спринта, только на более высоком уровне. Она заранее обговорена и принята с началом сезона.

Техника impact mapping, представленная в главе 15, позволяет направить команду в сторону цели сезона. Сама цель указывается в центре карты и может сопровождаться проверяемыми количественными элементами.

Пример. Цель 3-го сезона Peetic – увеличить продажи на 10 % благодаря премиум-подпискам.

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

16.4.3 Контрактные обязательства

Насколько Agility совместима с контрактом с фиксированной ценой? Ответ совсем прост и следует из того, в чем мы только что убедились: без надежных данных о работе команды обязательства в отношении результата бессмысленны.

Не рекомендуются какие-либо обязательства касательно скорости команды, которые, тем не менее, иногда фигурируют в контрактах.

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

Дополнительное условие относится к Владельцу продукта, который должен эффективно выполнять свою роль, а именно: определять минимальные функциональности, приносящие ценность. Можно распределять бюджет по функциональностям, оставаясь в рамках общего объема. Это отражает готовность и открытость к Agility.

16.5 Результаты планирования

16.5.1 Больше прозрачности

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

Но не стоит забывать: это не всегда полезно и при неверном подходе может привести к обратным результатам.

16.5.2 Актуальный план сезона

План сезона состоит из предстоящих спринтов и их ожидаемого содержания в виде историй или, если применимо, соответствующих функций.

Он регулярно обновляется – в отличие от заранее составленного подробного плана, который становится непреложным ориентиром. План развивается с учетом всевозможных изменений.


Изображения плана сезона

Мы рассмотрели план сезона в лотках. Это простое изображение позволяет все видеть на одной схеме без дублирования историй.

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