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

➠ если это не приносит результатов, всем предлагается вспомнить лучшие практики из опыта (наставник);

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

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

➠ Обсуждение проблем, повлекших незавершенность элементов бэклога. Для каждого незавершенного элемента бэклога в спринте выявляются проблемы, которые помешали завершению, и определяются решения этих проблем. Это позволяет острее сфокусироваться на предсказуемости прогнозов и минимизировать разговоры о малозначимых абстрактных проблемах.

➠ Голосование за проблемы позволяет вскрыть то, что волнует большинство. Организовать это можно инструментально, например, при помощи чат-бота, который собирает во время спринта в чате команды темы с хештегом #наретро и позволяет голосовать. Такой подход позволяет сэкономить время ретро и сфокусироваться на наиболее важных проблемах.

➠ Регулярная смена шаблонов ретроспектив. Существуют десятки, если не сотни разных шаблонов проведения ретроспектив. Их регулярная смена вносит разнообразие и позволяет привнести новые лучшие практики в сам процесс ретроспективы.

3.2.3.10. Прояснение бэклога

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

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

Сессии прояснения бэклога позволяют минимизировать неопределенность перед планированием и планировать максимально эффективно.

Руководство по Scrum не регламентирует, какими должны быть элементы продуктового бэклога (product backlog items, или PBI), но без сомнений можно сказать, что самый популярный тип – это пользовательская история. Вторым по популярности можно считать Spike, появившийся впервые в экстремальном программировании. Впоследствии популярный фреймворк масштабирования Agile, SAFe (Scaled Agile Framework), внес Spike в состав более широкого класса сущностей – энейблеров. Они бывают нескольких размерностей – от энейблер-эпик (enabler epic) до энейблер-истории (enabler story). Так как далее в нашем контексте мы будем обсуждать размеренность уровня истории, то для краткости будем использовать термин «энейблер» в отношении «энейблер-история».

Типы элементов продуктового бэклога представлены в табл. 3.5.

Табл. 3.5. Элементы продуктового бэклога

Энейблеры – значительно более редкий элемент продуктового бэклога, поэтому часто можно услышать термин «история». Применяется для всех элементов продуктового бэклога. (Подробнее об энейблерах см. в п. 3.2.4.1.)

За спринт должно быть проведено столько сессий прояснения, чтобы во время планирования хватило на один спринт.

Рекомендуется делать небольшой запас и прояснять бэклог на 2–3 спринта вперед, но не больше, так как часть проясненных историй могут утратить актуальность.

Табл. 3.6. Пример продуктового бэклога и горизонты планирования и декомпозиции

На планировании спринта нужно быстро оценить, сколько элементов бэклога может войти в спринт. Для этого каждая история оценивается в условных единицах – сторипоинтах (англ, story points – баллы истории). Зная объем сторипоинтов, закрытых в прошлых спринтах, можно предположить, сколько сторипоинтов будет завершено в планируемом спринте.

В табл. 3.6 приведен пример бэклога. Команда быстро может набрать истории в спринт, ориентируясь на прошлые показатели. Остается запас оцененных историй на 1–2 спринта, благодаря чему команда может планировать спринты самостоятельно, в исключительной ситуации, когда владелец продукта не смог участвовать. Также запас позволяет варьировать скоуп[47] спринта, и лучше его заполнять. В табл. 3.6 владелец продукта понизил приоритет одной из историй во время планирования для более эффективного заполнения объема спринта.

Для эффективной подготовки элементов к планированию, по аналогии с определением завершенности (DoD), вводят понятие определение готовности (Definition of Ready, DoR).

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