Борис Вольфсон: Гибкое управление проектами и продуктами

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

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).

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

Практика анализа персон пришла в управление продуктами из практик User Experience (опыт использования). Она заключается в описании пользователя создаваемого продукта как реального персонажа с конкретными ценностями и целями.

Таблица 3.1.

Бизнес-модель в виде Lean Canvas

После выявления персон нужно перейти к определению функционала, который необходимо реализовать для персон. Для этого используется Story Mapping (стори маппинг) – способ визуализации и планирования функционала.

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

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

• дополнительных возможностей;

• безопасности;

• удобства использования;

• производительности.

Чем ниже мы опускаемся по подзадачам, тем меньше у них важность.

Визуализация журнала пожеланий продукта с помощью Story Mapping

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