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

Структура ретроспективы. Обычно ретроспектива занимает от 30 минут до четырех часов и ее продолжительность зависит от таких факторов, как:

• длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;

• размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;

• наличие проблем: со временем команда решает проблемы, и ретроспективы сокращаются по времени.

В процентном соотношении принято выделять такую структуру.

Структура ретроспективы

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

1. Что было сделано хорошо?

2. Что можно улучшить?

3. Какие улучшения будем делать?

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

Для максимальной открытости и прозрачности обсуждения необходимо использовать основное правило ретроспективы, которое можно озвучивать вначале: «Вне зависимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал все, чтобы добиться успеха».

Если у команды отсутствуют серьезные проблемы, желательно следующие темы обсудить на ретроспективе:

• скорость команды и ее изменение по сравнению с предыдущими спринтами;

• нереализованные истории пользователей и причины опоздания;

• дефекты и их причины;

• качество процессов (нарушения, отступления).

К паттернам можно отнести анализ сделанных улучшений за несколько прошлых спринтов. Такая «ретроспектива ретроспектив» может проводиться раз в четыре спринта и позволяет контролировать уровень сделанных улучшений.

В Scrum определены три артефакта.

• Журнал пожеланий продукта (Product Backlog) – фактически приоритезированный список требований. Обычно он состоит из бизнес-требований, которые приносят конкретную бизнес-пользу и называются элементами журнала пожеланий.

• Журнал пожеланий спринта (Sprint Backlog) – часть журнала пожеланий продукта с самой высокой важностью и суммарной оценкой, не превышающей скорости команды, отобранная для спринта.

• Инкремент продукта – новая функциональность продукта, созданная во время спринта.

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

Наиболее подробно построение бизнес-моделей описано в работе Александра Остервальдера (Alexander Osterwalder) и Ива Пинье (Yves Pigneur) «Построение бизнес-моделей. Настольная книга стратега и новатора» (Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers). Бизнес-модели «Канвас» представляют собой способ визуализации бизнес-моделей, и их можно адаптировать к проектам по разработке ПО (табл. 3.1).

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