Все статьи
Есть слона по частям или декомпозиция задач и сервисов
Дата: 07.03.2024
«Декомпозиция» – с этим словом сталкивается каждый участник продуктовой команды. Для кого-то оно святое, у кого-то вызывает отвращение. В статье наглядно рассмотрены жизненные примеры и рекомендации по применению.
Большинство менеджеров продуктов при планировании работ и приоретизации бэклога сталкиваются с потребностью декомпозиции задач. То есть команде разработки проговаривается новая фича и после оценки становится понятно, что в итерацию она не влезет.
Есть случаи, когда команды разработки (особенно на этапе аналитики) просят взять эту большую задачу из бэклога всю на себя на несколько итераций.
С точки зрения эффективности это не совсем правильный подход, так как по результатам итерации, а в некоторых случаях может доходить до нескольких итераций, мы не получим новую ценность продукта.
Вместе с тем, команды разработки зачастую упираются, выступая против проведения декомпозиции. Аргументами могут служить:
- пустая трата времени;
- сложность последующей интеграции,
- мнимые зависимости модулей и прочее.
Такие настрои менеджеру продуктов стоит пресекать и настаивать на совместном проведении разбора и декомпозиции задачи.
Жизненный пример: одна из команд разработки (аналитик, 2 DEV, 2 SDET, Frontend) захотела взять большую задачу полностью на себя. Декомпозицию не проводили, аргументом было то, что лучше вести полный цикл разработки в одной команде и бессмысленно дробить на мелкие куски, так как больше потом переделывать для интеграции. Команда оценила задачу в 3 итерации, для заинтересованных лиц такой срок был приемлем. Каков был результат: задача была готова по истечении аж 5 итераций! + еще были «фиксы» при установке в «прод». Только процесс аналитики занял 1,5 итерации, хотя на этапе оценки сроки казались более оптимистичными.
Когда ещё декомпозиция помогает командам:
- контроль и планирование разработки;
- прогнозируемое время поставки;
- гибкость разработки при появлении новых вводных от заказчиков;
- более глубокое понимание задачи всеми членами команды, в т.ч. нахождение краевых и вырожденных случаев в процессе декомпозиции.
Ниже будут рассмотрены различные подходы к декомпозиции. Нельзя сказать какой из них лучше или хуже, так как все они имеют право на жизнь и опираются на практический опыт автора.
Декомпозиция на основе функциональности
Один из наиболее распространенных методов. Анализируется конечная функциональность. Задача разбивается на этапы.
Например: нужно на сайте найти операцию и изменить её параметры в UI интерфейсе. С точки зрения продукта будут задействованы: фронт (доработка формы поиска, параметризации операции, сохранения/подтверждения изменений), бэк (обработчик параметров операции).
Пример декомпозиции:
- на первом этапе делаем поиск на фронте и обработчик Excel-файла с операциями в ручном режиме;
- на втором этапе дополняем фронт и автоматизируем изменение операции в UI интерфейсе.
В некоторых случаях, когда действие со стороны пользователя выполняется в несколько этапов, можно использовать инструмент User Story Mapping (USM), который наглядно опишет действия пользователя для декомпозиции.
В Miro есть готовый шаблон USM для построения. Чем полезен USM:
- глубокое понимание поведения клиента при взаимодействии с продуктом;
- фокусировка на ценности продукта;
- заготовка пулла задач для бэклога.
Декомпозиция на основе микросервисов
Один из современных подходов к архитектуре предполагает построение приложений на основе микросервисов.
При таком подходе, если в задаче задействовано сразу несколько модулей, то можно разбить помодульно на команды (и вести разработку параллельно) или на спринты (если предполагается выполнение всей задачи одной командой). При таком подходе конечная бизнес-функциональность может не быть готова по результатам проделанного спринта, но завершенные модули можно автономно тестировать и готовить к релизам.
Декомпозиция на основе производительности
Данный раздел относится больше к техническим и SRE аспектам продукта. Допустим, что разрабатываемый продукт будет иметь уровень Mission/Business critical в целевом варианте эксплуатации, но на текущий момент идут процессы тестирования/интеграции/масштабирования с иными системами и уровень продукта заведомо занижен: Business Operational.
При данном подходе реализовывать сразу систему отказоустойчивости active-active может быть не целесообразно и как промежуточный, более быстрый и дешевый вариант станет система active-passive.
При данном подходе декомпозиции следует руководствоваться целевыми показателями производительности/отказоустойчивости и пониманием текущих потребностей бизнеса.
Иными словами, возможно, не целесообразно сразу разворачивать высоконагруженное хранилище данных, когда реальная бизнес-потребность в нём наступит только через несколько лет.
А что, если у нас Kanban?
В данном случае имеем стандартные этапы разработки:
При этом допускается, когда одна команда делает несколько задач со сдвигом по фазе разработки.
Пример:
При таком подходе в отгрузку каждую итерацию поставляется новая функциональность. Данный подход позволяет также делить этапы разработки между разными командами разработки.
Итог
Давать универсальную рекомендацию по выбору метода декомпозиции задач из бэклога не целесообразно. Всё индивидуально зависит от состава команды, текущей задачи и продукта в целом.
Другие статьи по теме
