Менеджмент цифрового продукта. От идеи до идеала

➠ Каждый день разработчики и Scrum-мастер собираются на ежедневном Scrum, актуализируют статус готовности элементов спринт бэклога и планируют день.

➠ Несколько раз за спринт Scrum-команда встречается для прояснения бэклога, чтобы добавить новые элементы, провести декомпозицию, приоритизацию и оценку.

➠ В конце спринта Scrum-команда собирается для обзора. Владелец продукта инспектирует инкремент продукта и определяет готовность, согласно определению завершенности.

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

Затем все повторяется.

Рис. 3.14. Scrum: схема процесса

3.2.3.2. Лучшие практики организации расписания событий Scrum

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

➠ Начинать спринт с планирования. Это помогает избежать дней простоя после окончания спринта, когда команде нечем заняться.

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

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

➠ Проводить обзор, ретроспективу и планирование в середине недели. Крайние дни – понедельник и пятница – часто добавляются к выходным из-за праздников и отпусков. Люди уезжают в эти дни для удаленной работы при гибридном графике, а также статистически чаще берут в эти дни отгулы и болеют. Следовательно, середина недели может оказаться наиболее стабильным временем, когда большинство участников команды в сборе.

3.2.3.3. Планирование спринта

Идеально, если команда входит в планирование спринта с полностью проясненной верхушкой продуктового бэклога – набором приоритетных элементов, которые команда оценила ранее на прояснении бэклога. В этом случае планирование проходит очень быстро. Но бывают случаи, когда новые элементы влетают в последний день спринта. В этом случае на планирование закладывают больше времени (до двух часов на неделю спринта, согласно руководству по Scrum), чтобы прояснить бэклог.

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

Тема 1. Почему этот спринт важен?

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

Тема 2. Что будет сделано во время спринта?

Команда идет по списку элементов продуктового бэклога, начиная с самых приоритетных, а разработчики, действуя как одна роль, определяют, что может быть взято в спринт. Если в бэклоге появились новые неприязненные элементы, то команда занимается прояснением. Разработчики ориентируются на емкость предыдущих спринтов и учитывают изменения определения завершенности, внесенные на ретроспективе. (Подробнее об измерении емкости спринта см. в п. 3.2.3.10.)

Тема 3. Как это будет сделано?

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

3.2.3.4. Лучшие практики планирования

➠ Не менять длину спринта. У команды вырабатывается определенный ритм и определенные внутренние ритуалы. Фиксированная длина спринта позволяет эффективно оценивать его объем и собирать статистику.

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

➠ Учитывать отпуска и болезни. Это влияет на то, какие истории и в каком объеме могут быть взяты в спринт.

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

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