Вступление
В последнее время часто натыкался на вопрос, как стоит декомпозировать задачи в бэклоге: то ли создавать одну задачу для всех компонентов (BE, Web, mobile), то ли создавать по задаче для каждого компонента.
Давайте разберемся, какой же подход будет наиболее правильным и оптимальным.
1 способ декомпозиции: Одна задача для всех компонентов
Один из способов декомпозиции бэклога является создание задачи, которая описывает функциональность целиком, охватывая требования ко всем компонентам (BE, web, mobile, и т.д).
Стоит отметить, однако, что данный подход требует от бизнес аналитика уверенных навыков в декомпозиции, т.к. каждая часть или этап реализации feature (далее - фича) должна нести ценность пользователю и в тоже время быть независимой от остальных задач.
Пример декомпозиции задачи
В качестве примера можно привести функциональность просмотра отчета. Применяя данный подход к декомпозиции у нас может получится примерно следующий набор задач:
Вызов отчета - в рамках этой задачи мы сделаем функциональность запроса данных за определенный период времени и отображения этих данных пользователю. На самом деле, эту часть можно было разбить на еще более мелкие кусочки: к примеру, сначала мы бы показывали в отчете данные “А”, затем мы бы добавили данные “Б” и т.д. Все зависит от приоритетов и сложности получения этих данных.
Следом мы добавим, к примеру, логику предоставления доступа к этим отчетам, т.е. будем разрешать определенным пользователям просматривать отчет, а другим - нет.
Затем мы можем добавить валидацию выбора периода времени: например, чтобы нельзя было выбрать слишком старые даты, или наоборот, будущие.
И напоследок оставим всевозможные обработки ошибок, подсказки, дополнительную навигацию и т.д. То есть то, что улучшит взаимодействие пользователя с системой.
По итогу, с каждой выполненной задачей пользователь получает доступ к данным, может их просматривать и с ними работать. Т.е. получает определенную ценность от разработанной функциональности.
Помимо предложенного выше, существует множество вариантов декомпозиции задач: декомпозиция по шагам рабочего процента, декомпозиция по типам данных, по типам операции с данными (CRUD) и т.д. и т.п.
Останавливаться на каждом из них не вижу смысла, т.к. это тема отдельной статьи, коих уже и так немало на просторах интернета.
Плюсы
Из плюсов следует отметить, что при данном подходе пользовательская история соответствует критериям акронима INVEST, а именно покрывает следующие части:
I - independent - история становится независимой от реализации сопутствующего компонента. Тем самым мы можем сказать, что нам не нужно ждать, к примеру, пока API часть будет готова, чтобы начать реализацию UI.
V - valuable - требования, описанные в истории, определенно несут ценность и охватывают все компоненты, которые могут ту самую ценность донести до пользователя.
Так же, используя этот подход, становится проще измерять прогресс разработки беклога продукта, ведь статус конкретной фичи становится очевидным: если соответствующая задача выполнена - значит фича готова, иначе - нет.
И конечно же, time-to-market при таком подходе будет меньше. Причина проста: задачи получаются небольшого объема, следовательно, быстрее разрабатываются и попадают к пользователю.
Минусы
Из немногочисленных минусов могу отметить, что в контексте итерационной разработки не всегда удобно работать с задачами, в которых нагрузка на компоненты ложится в отношении 70/30 и более, т.е. когда одни разработчики получают гораздо больше работы, чем другие.
Пример минуса декомпозиции
Имплементация функциональности экспорта данных в файл (csv, xls), где большая часть работы ложится на серверную часть, нежели на пользовательский интерфейс.
Как результат - в бэклоге итерации (спринта) мы можем столкнуться с перегруженностью одной из команд и недогруженностью другой.
2 способ: Декомпозиция по архитектурным слоям
Одним из альтернативных подходов к декомпозиции задач хочу рассмотреть способ, при котором создается отдельная задача для каждого из компонентов или архитектурных слоев.
Пример декомпозиции
Разберем функциональность просмотра отчетности. В этом случае нам нужно меньше заморачиваться по поводу детальной и правильной декомпозиции, и мы можем разбить разработку всего на 2 основные части:
Имплементация серверной части - где мы разработаем запрос на получение данных, систему разрешений на просмотр и валидацию на выбор периода времени.
Имплементация пользовательского интерфейса - в рамках же этой задачи мы будем обрабатывать полученные данные с сервера и отображать их пользователю.
При данном подходе пользователь получает доступ к новой функциональности только по завершению работ по задаче №2, что может быть не всегда приемлемо в контексте гибкой разработки.
Плюсы
Плюс этого подхода - это удобство в планировании загрузки команды. Более того, становится проще вести аналитику по производительности каждой команды (Front-end/Back-end/mobile), т.к. у нас появляются данные о количестве закрытых задач каждой командой.
Помимо этого, из плюсов можно отметить некоторую “определенность” в работе: при декомпозиции на "сервер" и "клиент", разработчикам UI это позволит начинать работу с готовой документацией, должным образом протестированным АПИ и т.д. Иными словами, с должной степенью “предсказуемости”.
Минусы
Очевидным минусом, в отличии от предыдущего варианта, будет, конечно же, зависимость задач от других. Иначе говоря, UI команда не может начать работу, пока не будет готова серверная часть функциональности.
Кроме того, реализация функциональности на сервере не будет нести никакой ценности пользователю, и до полной готовности фичи нам нужно будет ждать пока будет готова интерфейсная часть, что в свою очередь увеличивает time-to-market продукта. А это, как известно, один из главных показателей “здоровья” продукта.
Так где же правда? Итоги:
Исходя из вышесказанного, можно сделать вывод, что истина, как обычно, где-то “посередине”. Применение каждого из типов декомпозиции имеет место на существование. Не люблю эту заезженную фразу, но тем не менее: “Все зависит от контекста”.
В контексте гибкой разработки определенно имеет смысл остановится на подходе при создании одной задачи для всех компонентов, ведь как уже было отмечено ранее, в таком случае нам нужно как можно быстрее доставить новый кусочек рабочего продукта пользователю. Но данный подход, как уже упоминалось ранее, требует уверенного навыка декомпозиции. Так как при неправильной разбивке задач процесс разработки можно сделать, наоборот, только длиннее и затратнее.
В контексте каскадной разработки же, могут подойти оба метода декомпозиции, так как при таком подходе нет необходимости быстрой доставки “готовой” функциональности. Иными словами, как бы мы систему не декомпозировали, она не уйдет к конечному пользователю пока не закончатся все фазы разработки, тестирования, развертывания и т.д. Более того, готовая серверная часть продукта даст разработчикам пользовательского интерфейса больше “определенности”.
Это было мое видение относительно подхода к декомпозиции задач. Буду рад ответить на ваши вопросы, если таковые имеются.
Расписание тренингов от Art of Business Analysis Новости и статьи по бизнес-анализу - https://t.me/artofba
Я работал на проектах с вертикальной деклмпозицией и горизонтальной. Так вот вертикальная требует доп артифакты, в которых команда узнает что надо делать на бекенде. Все равно есть зависимости, которых не видно в бэклог.
Выбор декомпозиции лучше делать по составу проекта, специализации разработчиков, длине спринта, наличия артифактов (может предыдущие команды делали).
Я бы поспорил с выводами. Правильно декомпозировать задачи надо и в первом и во втором случае. Только во втором случае аналитик берет на себя задачи тех Лида (который должен был бы помочь декомпозировать задачи по компонентам, помочь договориться о контрактах и т.д.). Почему тайм ту маркет будет разный? В первом случае работы по компонентам разделяются на подзадачи. Но сохраняется Стори как единица доставки ценности.