Декомпозиция бэклога

Огромное преимущество Agile перед классическим подходом — возможность не делать все и сразу, а поставлять результат инкрементально, по частям, получая ценную обратную связь и первые выгоды для компании.

Понимание того, как ускорить поставку результата, дает декомпозиция элементов бэклога. Основная задача декомпозиции — из общей идеи выделить самое главное, что должно быть сделано прямо сейчас. А все остальное несколько отложить. Но как выделить главное, когда нужно сделать все и сразу? Ведь клиенты и заказчики всегда просят именно так.

Существует два уровня декомпозиции: уровень самого продукта (обычно используются термины MVP, MLP) и уровень элементов бэклога — требования/функции/задачи (часто используется термин MMF).

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

Декомпозиция продукта

1. Декомпозиция по задачам клиентов

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

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

Основной метод этого паттерна декомпозиции — «рабочие истории» (Job Story), ориентированные на контекст, в котором возникает необходимость в продукте.

2. Выделение минимальной версии продукта

Minimum Viable Product, или MVP — минимальный жизнеспособный продукт (сервис, процесс), обладающий базовыми функциями, способными закрыть задачу первых пользователей.

В состав MVP включают достаточный минимум, который позволит протестировать идею. Цель прототипа — получить обратную связь от производства и пользователей, разработать гипотезы для дальнейшего развития продукта (сервиса, процесса).

3. Выделение основного сценария

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

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

Декомпозиция элементов бэклога (на примере программного продукта)

Итак, мы выделили ключевые функции продукта, теперь нам необходимо декомпозировать каждую из них.

1. По этапам рабочего процесса

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

2. Разделение по ролям

Часто внутри группы «клиенты (пользователи)» можно выделить несколько явно выраженных ролей, каждая из которых взаимодействует со своей частью функционала продукта. Это могут быть зарегистрированные и незарегистрированные пользователи, администратор или редактор и тд.

3. Разделение на позитивные и негативные сценарии

Позитивный сценарий подразумевает, что клиент достиг своей цели при использовании продукта. В нашем примере с такси — успешно вызвал машину и доехал до точки назначения.

Негативные сценарии описывают любые отклонения в развитии событий: пользователь забыл пароль и вынужден восстанавливать его; или клиент решил отменить поездку; или расплатиться наличными вместо карты и тд. Часть негативных сценариев на первом этапе может быть реализована в упрощенном виде или отложена. 

4. Декомпозиция по операциям

Часто PBI включает в себя различные операции: например, управление ассортиментом интернет-магазина. Внутри такой операции «по умолчанию» обычно находится несколько более мелких: добавление нового продукта, удаление тех, что больше нет в ассортименте, редактирование цены и описания товара и тд.

5. Разделение по бизнес-правилам

Продукт обычно предполагает соблюдение общепринятых в конкретной сфере бизнес-правил: отмена бронирования товара, если он не был оплачен в течение определенного времени; поиск билетов по гибким датам; минимальная сумма для доставки товара и тд. Элементы бэклога можно декомпозировать так, чтобы сначала реализовать только часть бизнес-правил.

Достаточная степень декомпозиции

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

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