19 / 94
Scrum и XP: заметки с передовой
19
Распорядок встречи по планированию спринта
Наличие хотя бы примерного расписания значительно увеличит ваши шансы закончить планирование
спринта в отведённое для этого время.
Например, наше расписание выглядит так:
Планирование спринта
: с 13:00 до 17:00 (после каждого часа перерыв на 10 минут)
•
13:00 – 13:30.
Product owner разъясняет цель спринта и рассказывает про бизнес-процессы из
product backlog’а. Обсуждается время и место проведения демо.
•
13:30 – 15:00
. Команда проводит оценку времени, которое потребуется на разработку бизнес-
процессов и, при необходимости дробит их на более мелкие. В некоторых случаях product owner
может изменить приоритет их исполнения. Выясняем все интересующие нас вопросы. Для
наиболее важных заполняем поле «Как продемонстрировать».
•
15:00 – 16:00.
Команда определяет набор user story, которые войдут в следующий спринт. Чтобы
проверить насколько это реально, вычисляем производительность команды.
•
16:00 – 17:00.
Договариваемся о времени и месте проведения ежедневного Scrum’а (если они
изменились по сравнению с прошлым спринтом). После чего приступаем к разбиению user story на
задачи.
Наличие расписания ни в коем случае не подразумевает наличия жестких ограничений. В зависимости от
того, как проходит встреча, ScrumMaster может увеличить, или уменьшить продолжительность каждого этапа.
Определяем длину спринта.
О на из основ ых задач планирования спринта – это определение даты демо. А это значит, что вам
придётся определиться с длиной спринта.
Какая же длина оптимальна?
Короткие спринты – удобны. Они позволяют компании быть максимально “гибкой”, а значит готовой
часто корректировать свои планы. Короткий спринт = короткий цикл обратной связи = частые релизы =
быстрые отзывы от клиентов = меньше времени тратится на работу в неправильном направлении = быстрое
обучение, совершенствование и т.д.
Но с другой стороны длинные спринты тоже хороши. У команды остаётся больше времени, чтобы набрать
темп, больше пространства для манёвров, чтобы решить возникшие проблемы, а также больше времени для
достижения цели спринта, а у вас меньше накладных расходов, таких как планирование спринта, демо и т.д.
В основном короткие спринты больше нравятся product owner’у, а длинные – разработчикам. Поэтому
длина спринта – это всегда компромисс. Мы долго экспериментировали и выбрали нашу любимую длину:
3 недели. Большинство наших команд (но не все) используют трёхнедельный спринт. Достаточно короткий,
чтобы предоставить адекватную корпоративную “гибкость”, но в тоже время достаточно длинный, для того
чтобы команда смогла достигнуть максимальной производительности и успеть решить все вопросы, которые
возникнут по ходу спринта.
Мы пришли к важному выводу:
экспериментировать
с длиной спринта
нужно
на начальном этапе. Не
тратьте слишком много времени на
анализ
, просто выберите подходящую длину и используйте её на
протяжении одного или двух спринтов, после чего можете выбрать новую.
Однако
, как только вы найдёте подходящею длину, надолго
зафиксируйте её
. После нескольких месяцев
экспериментов нам подошла длина в 3 недели, поэтому теперь мы следуем этому правилу и используем
трёхнедельные спринты. Иногда спринт будет казаться слишком длинным, иногда – слишком коротким. Но
сохранение фиксированной длины спринта позволяет выработать корпоративный ритм, в котором все
чувствуют себя достаточно комфортно. К тому же исчезнут споры, насчёт даты релиза, так как все знают, что
как ни крути, а выпуск новой версии продукта каждые 3 недели.