Команде следует установить фиксированную дату окончания сезона и придерживаться ее, используя идею временного интервала, как в спринте.
Для сезона важно заранее планировать бюджет, в связи с чем Владелец продукта должен принимать решения:
✓ о приоритетных элементах в доработке;
✓ о чистке историй, которые, в конечном итоге, не несут большой ценности.
План сезона позволяет принимать решения о будущем продукта вместе с заинтересованными сторонами. Обзор спринта – наиболее подходящий момент, чтобы представить этот план, обсудить его и принять необходимые решения.
16.2 Основы планирования
Agile-планирование переворачивает традиционный треугольник содержание-стоимость-время [47], при этом:
✓ дата, стоимость и качество определены заранее и не подлежат обсуждению;
✓ содержание (scope) может корректироваться.
Рисунок 16.2 – Перевернутый треугольник
Планирование сезона основано на этом принципе и нацелено на увеличении ценности продукта путем выбора функциональностей.
Скорость команды (velocity) – это объем той части бэклога, что команда завершает за один спринт.
Производительность команды (capacity) – это запланированный объем того, что команда может завершить за один спринт.
Эти два понятия, которые часто путают между собой, помогут нам при планировании. Измерение скорости команды кажется простым, но иногда – это пустая трата времени команды, в особенности из-за продолжительного оценивания.
Планировать – значит добавить измерение времени в бэклог. В Scrum время разделяют на спринты и сезоны, которые остается лишь визуализировать в бэклоге, чтобы получить план.
Мы примем несколько гипотез и убедимся, что такой способ работы может быть действительно простым и в то же время эффективным. Гипотезы следующие:
✓ сезоны длятся по 3 месяца и включают 6 спринтов по 2 недели,
✓ ввод в эксплуатацию конечными пользователями проводится в конце каждого сезона,
✓ команда уже завершила один сезон и измерила свою скорость – это 4,
✓ команда практикует сессии доработки и умеет разбивать работу на маленькие истории,
✓ команда рассчитала, что epic примерно в два раза больше обычной истории.
Рисунок 16.3 – План сезона в соответствии с примером
В нашем примере команда сейчас на этапе спринта 2. Она берет набор историй в соответствии со своей скоростью – это прогноз на спринт 3. Таким же образом она планирует следующие спринты вплоть до конца сезона.
Этот простой подход основан на разделении, измерении и подсчете и не требует сложных, детальных оценок.
Результат планирования отражается непосредственно в бэклоге через паттерн лотков.
Специального собрания, посвященного планированию сезона, нет. Большинство необходимых для этого действий происходит во время доработки: разделение на части, упорядочение, оценка, чистка. Другие проводятся во время обзора спринта: измерение скорости команды, представление плана заинтересованным сторонам.
Касаемо составления первого плана. В главе о прелюдии мы узнали, что не разумно это делать без данных о предыдущей работе команды. Будет лучше подождать несколько спринтов.
Менеджеры, привыкшие до Scrum самостоятельно составлять планы, могут начать планировать без участия команды. Вообще, при традиционном управлении планы составляются одним или несколькими экспертами, снабженными цифрами и диаграммами.
В Scrum все иначе. Оценка проводится при участии всей команды, как и вытекающее из этого планирование.
Владелец продукта отвечает за консолидацию плана, его обновление каждый спринт и представление на обзоре.
16.3 Процесс планирования
Планирование сезона состоит из:
✓ Определения объема работы на сезон.
✓ Вычисления средней скорости команды на основе имеющихся данных – достаточно разделить количество завершенной работы за период (например, сезон) на количество пройденных спринтов.
✓ Вычисления производительности. Самое простое – взять в качестве производительности среднюю скорость команды. Это все равно что прогнозировать погоду: не сильно рискуешь ошибиться, если ориентируешься на погоду накануне.
✓ Отражения полученных данных в бэклоге. Двигаясь от наиболее приоритетной готовой истории к наименее приоритетной в лотке доработки и применяя вычисленную производительность команды, нужно определить содержание каждого спринта.
✓ Внесения неопределенностей. Все прогнозы имеют элемент неопределенности. Но это не мешает принимать решения.
• Истории или функциональности?
Планирование обычно практикуется по отношению к историям и при использовании рабочего бэклога.
Результат планирования может показать, что истории в доработке не могут быть реализованы за текущий сезон. Если команда использует ледяной лоток, содержание сезона постоянно корректируется в зависимости от перемещения истории между этими двумя лотками.
Однако план, основанный на историях, может быть не очень информативным для заинтересованных сторон.
Рисунок 16.4 – Корректируемое содержание сезона
Можно, наоборот, планировать на основе функциональностей. Такой план будет для них более понятным. Достаточно четких прогнозов, чтобы определить необходимые точки синхронизации для подготовки к вводу в эксплуатацию.
• Считать или оценивать?
Можно просто считать истории или функциональности, иногда этого достаточно. Но для точности следует учитывать разницу между элементами и оценивать размер каждого из них.
Покер планирования
Покер планирования [48] стал очень популярен среди Scrum-команд. Это техника групповой оценки с использованием карточек. Она сочетает в себе экспертную оценку и оценку по аналогии.
Каждый участник получает колоду карт с указанием определенного числа для оценки истории.
Обычно используется около десяти чисел, взятых из последовательности Фибоначчи: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Я советую остановиться на 13 – это дает шкалу из шести значений, которых более чем достаточно.
Чтобы начать сеанс, нужно сперва выбрать историю для оценки.
Желательно подобрать историю среднего размера и присвоить ей значение от 3 до 5.
Процесс покера планирования
– Владелец продукта представляет историю.
– Участники команды задают вопросы, чтобы лучше ее понять, коротко ее обсуждают.
– Все участники одновременно переворачивают выбранную ими карту для оценки истории.
– Каждый объясняет свой выбор. Первыми высказываются те, кто дал самую высокую и самую низкую оценку.
– С учетом сказанного опять вытягивают карты, чтобы принять окончательное решение по поводу данной истории. Потом команда переходит к следующей истории.
Как правило, Владелец продукта не голосует, это остается за исполнителями. Однако если он чувствует, что готов дать адекватную оценку – он может принять участие, как и эксперты, которые помогут команде в реализации историй.
Уроки, извлеченные из многих сессий покера планирования, которые я провел: это легко с точки зрения организации. Достаточно двух раундов голосования. Рефлексия проводится после первого голосования – это весело. В дополнение к аспекту оценки: покер планирования является отличной возможностью для разговора между командой и Владельцем продукта.
Рисунок 16.5 – Заядлые игроки в покер планирования
Оценка сходства
Первый сеанс покера планирования может занять аж полдня. Его возможно ускорить при помощи оценки сходства.
Оценка сходства проводится при помощи Post-it® для всех историй поочередно. Для каждого возможного значения создается отдельная строка.
Уже оцененные истории отлично видно, что упрощает дальнейшее оценивание и ускоряет время покера планирования. Бывает, команда впоследствии корректирует оценку, сравнивая ее с другими в этой таблице.
Оценка сходства проводится в тишине. Конечно, общению в команде это не способствует – но так процесс пойдет быстрее.
Размер футболки
При покере планирования используется около десяти значений из последовательности Фибоначчи. Это действительно много, и давать такой огромный выбор зачастую бессмысленно.
Вот почему мы рекомендуем ограничить количество значений.
Есть еще более простая техника, использующая размеры футболок. Достаточно трех размеров: S, M, L. Такой способ дает возможность не прибегать к числовым значениям, что делает процесс оценивания простым и честным.
После коллективной оценки уже можно соотнести каждый размер с определенным числовым значением для последующего расчета скорости команды.
Подсчет
Простая техника, которую мы использовали во введении – это подсчет. Сначала нужно определить: представленный элемент – это epic или история? Затем просто посчитать истории. Гипотеза один epic равняется двум историям позволяет быстро получить объем работы, которую необходимо выполнить.
Есть несколько способов, как измерить среднюю скорость команды за один спринт.
✓