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

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

Ключевые паттерны декомпозиции бэклога продукта, сервиса или процесса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Интересно узнать подробнее?

Приходите на один из наших тренингов, где вы в деталях разберете эту тему и сможете задать тренеру свои вопросы.

Вопросы и ответы по теме

Как правильно декомпозировать бэклог в Agile-проектах?

В Agile декомпозиция бэклога происходит на нескольких уровнях. Сначала разбиваем проект на эпики, затем на user story, и наконец на конкретные задачи для спринтов. Каждая user story должна следовать принципу INVEST и быть достаточно малой для выполнения в один спринт. Это позволяет команде быстрее доставлять ценность и получать обратную связь от пользователей.

Какие методы декомпозиции задач используются в Agile?

В Agile применяются различные паттерны декомпозиции: разбиение по бизнес-процессам, по пользовательским ролям, по этапам работы с данными (CRUD). При работе со Scrum важно, чтобы каждая декомпозированная задача была независимой и могла быть завершена в рамках одного спринта. Популярны также методы декомпозиции через user story mapping и impact mapping.

Как создать MVP продукта через правильную декомпозицию?

Создание MVP начинается с декомпозиции продукта на минимальные работающие функции (MMF). Важно определить scope MVP, выделив ключевые user story, которые решают главную проблему пользователя. В Agile-подходе рекомендуется использовать технику story mapping для визуализации и приоритизации функций MVP. Это помогает сфокусироваться на создании минимального, но ценного для пользователей продукта.

Как разбить большой проект на спринты в Agile?

Разбиение проекта на спринты начинается с декомпозиции бэклога на user story подходящего размера. В Scrum каждый спринт должен создавать работающий инкремент продукта. Используйте технику декомпозиции требований, чтобы каждая задача в спринте была выполнима за 1-2 дня. Важно соблюдать баланс между техническими задачами и бизнес-ценностью при планировании спринтов.

Как приоритизировать задачи в бэклоге после декомпозиции?

В Agile приоритизация задач основывается на бизнес-ценности и рисках. После декомпозиции бэклога используйте методы MoSCoW, WSJF или Impact Mapping для определения приоритетов. Важно учитывать зависимости между user story и техническими ограничениями. В Scrum приоритизация происходит совместно с Product Owner на основе целей спринта и релиза.

Как определить правильный scope MVP через декомпозицию?

Определение scope MVP требует тщательной декомпозиции требований. Начните с создания user story map, выделите core функционал, который решает ключевую проблему пользователей. В Agile важно ограничить scope MVP до минимально необходимого набора функций, которые можно реализовать и протестировать в 2-3 спринта. Используйте методы приоритизации для выбора самых важных user story.

Еще публикации по Agile в Управление продуктами

Модель приоритизации бэклога WSJF
Публикация Управление продуктами

Модель приоритизации бэклога WSJF

Как упорядочить бэклог и определить, какие элементы следует выполнить в первую очередь? Обратимся к математике и рассмотрим простой инструмент Weighted Shortest Job First.

Почему мы мыслим короткими циклами, но не хотим переходить на Scrum
Публикация Управление продуктами

Почему мы мыслим короткими циклами, но не хотим переходить на Scrum

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

Что должен уметь Владелец продукта
Публикация Управление продуктами

Что должен уметь Владелец продукта

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

Ближайшее обучение по Agile и Scrum

С 2015 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!