Про декомпозицию неделимых задач

В вашей работе встречаются задачи, которые занимают несколько спринтов просто потому, что выглядят неделимыми? Я знаю, что с ними делать. Особенно, если это касается разработки.

Многие статьи про декомпозицию описывают горизонтальный (по типам работ) и вертикальный (по пользовательскому функционалу) способ разделения задач.

И хотя предпочтение отдаётся второму варианту (из-за возможности быстрее получить обратную связь от заказчика и т.д.), ряд проблем остаётся «за скобками»:

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

Содержание:

Предположим, что некую исходную задачу команда декомпозировала на три:

С одной стороны, в каждой новой версии пользователь получает приращение функционала.

Однако, предположим, что первая же задача «не помещается» в спринт: оценка задачи сильно превышает возможности команды на одну итерацию.

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

При таком подходе задача берётся в работу в исходном виде, с пониманием того, что она «переедет» в следующий спринт (один или несколько).

При этом команда может и не использовать классический waterfall в своей работе, но, с вашего позволения, я буду использовать именно этот термин, подчёркивая далёкость от итеративно-инкрементальной разработки.

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

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

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

Ну а для команд, работающих по Scrum, такой подход сильно усложняет проведение регулярного Обзора спринта (Sprint Review) из-за отсутствия промежуточных результатов.

Возможный backlog при Непрозрачном водопаде выглядит так:

Этот подход предполагает более детальный предварительный анализ этапов реализации задачи.

Чтобы иметь возможность контролировать прогресс работы над задачей, этапы раскладываются на будущие итерации/спринты (с учётом скорости команды).

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

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

Если команда работает по Scrum, на Обзоре спринта возможно подведение промежуточных итогов, однако без демонстрации завершённого функционала.

Собственно, в этом и заключается главный риск использования данного и предыдущего подхода (как и любой водопадной модели): точно ли команда сделала именно то, чего хотел заказчик? (даже если это полностью соответствует ТЗ)

Возможный backlog при Прозрачном водопаде:

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

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

Cпойлер: решить эту задачу поможет использование «заглушек».

На первом этапе разработки реализуется (полностью или частично) функционал, связанный со взаимодействием с пользователем (например, получение запроса и возврат результата), а весь прочий функционал - эмулируется (имитируется).

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

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

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

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

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

С другой стороны, такой подход позволяет проводить часть аналитики во время работы над задачей (не нужно заранее описывать интерфейс всех функций, как при классическом водопаде) и может сильно (точнее: ОЧЕНЬ сильно) облегчить работу тестировщикам.

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

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

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

По сути, при разработке «снизу вверх» с использованием заглушек, происходит перераспределение сложности между тестированием и разработкой (более подробно про это - в видео по ссылке), когда повышение сложности на этапах аналитики и разработки снижает сложность на этапе тестирования.

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

Возможный backlog при итеративно-инкрементальном подходе:

Дополнительная аналитика и тестирование происходят в рамках каждой из приведённых выше задач.

*Пользователь же в данном примере увидит изменение функционала только после реализации второй и последней задачи. Однако, в плане возможных переделок это сильно безопаснее, чем при водопадных подходах.

Отдельного внимания заслуживают "чёрные ящики" - задачи, понимание сути которых приходит только во время работы над оными:

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

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

Самым простым и действенным советом в данной ситуации будет «отрезание» от Чёрного ящика небольших понятных задач. Другими словами - выделение первых шагов решения исходной задачи.

Важно: для «отрезаемых» задач должны быть понятны критерии завершения и способы реализации (именно это будет отличать их от исходного «Чёрного ящика»):

Во-первых, это позволяет оценить задачи (тем самым делая работу и нагрузку команды более предсказуемой).

Во-вторых, реализация этих задач даёт понимание о выделении из Чёрного ящика следующих этапов работы = следующих небольших и понятных задач.

В конечном итоге Чёрный ящик перестаёт быть таковым. Завершение работы над оставшейся частью становится, как говорится, «делом техники».

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

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

Всё вышеперечисленное выливается в риск непопадания обозначенных сроков и возможных переделок.

Однако, даже "неделимая" на первый взгляд задача может быть декомпозирована с сохранением возможности сбора обратной связи от пользователей или заказчиков.

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

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

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

P.S. А еще Диаграмму последовательности можно использовать для описания связей между командами. Подробнее - в этом видео.