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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Артефакты

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

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

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

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

Глава 3. Управление продуктом

Владельцу продукта 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 (стори маппинг) – способ визуализации и планирования функционала.

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

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

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

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

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

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

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

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

Журнал пожеланий продукта

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

 Уникальный числовой идентификатор истории – обычно совпадает с идентификатором истории пользователя из трекера, которым пользуется команда. Этот идентификатор позволяет точно сказать, о какой истории пользователя в данный момент идет речь.

 Название истории пользователя – короткое (примерно до десяти слов) описание функционала с точки зрения пользователя, сформулированное в виде тройки «роль – действие – цель», например: «Пользователь вводит логин и пароль, чтобы авторизоваться на сайте».

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

 Оценка – числовая относительная оценка истории пользователя по специальной шкале.

Указанные поля удобно размещать на стикере, который прикрепляется на доску. Например, историю пользователя для авторизации на сайте с оценкой 10 очков (Story Points), важностью 200 и номером в трекере 1453 можно представить на стикере так.

История пользователя для авторизации на сайте

Эти четыре поля являются фактически обязательными, но часто используются и дополнительные поля, которые, например, заносятся в трекер.

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

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

♦ пользователь вводит логин root и пароль pass и переходит на страницу личного профиля на сайте;

♦ пользователь вводит логин root и пароль wrongpass и получает сообщение Введен неправильный логин или пароль.

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

Размер журнала пожеланий и стратегическое планирование

Для сохранения управляемости необходимо поддерживать минимальный размер журнала пожеланий, но для стратегического планирования, скажем на несколько кварталов вперед, необходимо иметь достаточно длинный журнал пожеланий. Используя нотацию «грозовых туч» Э. Голдратт, это противоречие можно изобразить следующим образом.

Противоречие между тактическим и стратегическим планированием

Какой бы размер журнала пожеланий мы ни выбрали, все равно не получится разрешить конфликт – нужно прорывное решение. Оно достаточно просто и лежит на поверхности: использовать метод набегающий волны. В рамках Scrum такой подход означает, что мы разбиваем очень подробно истории пользователей на несколько ближайших спринтов, а остальные истории пользователей храним в виде больших фрагментов функциональности, подробно не описывая их. Такие большие истории пользователей, которые в дальнейшем будут разбиты на маленькие, называются эпиками (epic).

Более важные элементы журнала пожеланий определены точнее

Как видите, чем позднее планируется реализация того или иного функционала, тем более крупные фрагменты функционала берутся. Отмечу, что это также согласуется полностью с принципами KISS (Keep it simple, stupid – «Не усложняй, тупица») и YAGNI (You аin’t gonna need it – «Вам это не понадобится»).

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

• рефакторинг модуля;

• оптимизация производительности;

• исправления сложного дефекта;

• настройка инфраструктуры.

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