Декомпозиция задач: Как сделать проекты управляемыми и успешными — for Business analyst, Scrum master, Project Managers! 🏆💪💥
Декомпозиция задач — это процесс разбивки сложной задачи или проекта на более мелкие, управляемые и понятные подзадачи. Этот подход позволяет упростить выполнение задачи, сделать её более структурированной и снизить уровень стресса, связанного с её выполнением.
Декомпозицию задач можно осуществлять как на этапе планирования нового спринта, так и в процессе реализации спринта, разбивая требования для дальнейших итераций. Однако второй подход является более предпочтительным. Не стоит привязывать декомпозицию к конкретному спринту, чтобы приходить к его планированию с уже подготовленным бэклогом, разделённым на пользовательские истории .
В такой ситуации, если у нас есть запас декомпозированных требований, это даёт следующие преимущества:
- Во-первых, мы не ограничиваем себя в выборе задач для спринта (можем работать только с теми задачами, которые уже декомпозированы).
- Во-вторых, во время планирования не нужно тратить время на разбивку, и команда может сосредоточиться на формировании спринта с учётом всех приоритетов, обсудить зависимости и детали реализации требований.
- В-третьих, митинг пройдет более продуктивно, и все участники команды будут активно вовлечены. Не забывайте, что митинги должны быть результативными и позитивными, чтобы команда ожидала их с нетерпением, а не воспринимала как скучную рутину.
Два основных подхода к декомпозиции.
Существует два базовых подхода к декомпозиции крупных задач на пользовательские истории — «горизонтальное» и «вертикальное» разбиение:
- При применении так называемой «горизонтальной» декомпозиции, задачи делятся на основе типа выполняемых работ (функций) и используемых компонентов. В данном подходе большая задача разбивается на части, где разработчик получает одну долю обязанностей, тестировщик — другую, а технический писатель — третью, и так далее. Важно отметить, что каждая из этих частей не приводит к завершенному результату самостоятельно; для успешного выпуска готового функционала требуется совместная реализация всех взаимосвязанных задач всеми участниками процесса. Пример горизонтальной декомозиции из саб-тасков в Jira:
- С другой стороны, «вертикальный» подход к декомпозиции акцентирует внимание на выделении более мелких задач, функций и особенностей, так что каждая пользовательская история может быть реализована и завершена независимо от других. В этом случае в процессе разработки могут участвовать различные роли, а также задействоваться несколько модулей и систем, обеспечивая большую гибкость и скорость в реализации функционала. Пример вертикальной декомозиции из саб-тасков:
Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:
• При использовании «вертикального» подхода к декомпозиции каждая задача становится доступной для реализации, тестирования и демонстрации клиентам или пользователям, что делает её понятной и измеримой, в отличие от более абстрактных «технических» задач, которые возникают при «горизонтальной» разбивке.
• В рамках «вертикальной» декомпозиции каждая конечная пользовательская история обладает явной ценностью для бизнеса, что упрощает процесс сравнения и определения приоритетов таких задач.
• Учитывая, что в решении задач, организованных по «вертикальному» принципу, участвуют специалисты с разными ролями, они легче могут выявить потенциальные проблемы, зависимости и риски, которые могут возникнуть в ходе выполнения работы.
Техники декомпозиции требований
Способ 1: Этапное разбиение бизнес-процессов
Этот подход предлагает разделить крупную задачу, связанную с бизнес-процессом, на более мелкие, независимые компоненты и этапы. Для реализации этого метода важно выделить последовательные шаги, которые можно выполнять автономно. Например, если в бэклоге имеется требование по реализации функции онлайн-покупки, то этапы могут включать:
- Вход в личный кабинет
- Просмотр товаров в «корзине»
- Формирование счета
- Отправка счета на почту
- Оплата различными способами: банковская карта, перевод и т.д. Каждый из этих этапов можно оформить как отдельную пользовательскую историю. Таким образом, мы разбиваем обширный бизнес-процесс на составные части, что позволяет определить приоритеты и лучше понять процесс в целом, включая возможные зависимости между этапами.
Способ 2: Разделение на позитивные и негативные сценарии
Каждая функциональность включает в себя основной сценарий использования, который ведет к ожидаемому результату, однако возможны и отклонения, приводящие к негативным последствиям. Этот метод предлагает выделить сценарии, которые могут привести к успешному или неудачному результату. Например, для функции покупки в интернет-магазине:
- Позитивный сценарий: пользователь авторизуется и успешно совершает покупку.
- Негативный сценарий 1: попытка покупки без авторизации.
- Негативный сценарий 2: недостаточно средств на счете для завершения транзакции.
- Негативный сценарий 3: блокировка учетной записи после нескольких неверных попыток ввода пароля.
Такой подход позволяет заранее определить и спланировать обработку возможных ошибок и исключений.
Способ 3: Разбиение по правилам и условиям
В отличие от предыдущего метода, здесь акцент делается не на этапах, а на логических ветках процесса, основанных на различных правилах. Например, для функции покупки можно выделить правила, такие как:
- Минимальная сумма покупки.
- Дополнительные варианты оплаты при превышении определенной суммы.
- Автоматическая отмена заказа через 2 дня без оплаты.
Каждое из этих условий может быть оформлено как отдельная задача, что помогает выявить важные ограничения и упрощает процесс реализации.
Способ 4: Разделение по типам операций
Многим функциональным требованиям соответствуют стандартные операции, такие как создание, чтение, обновление и удаление (CRUD). Например, для управления карточкой товара в интернет-магазине можно выделить:
- Create: добавление нового продукта.
- Read: просмотр описания продукта.
- Update: редактирование информации о продукте.
- Delete: удаление товара из магазина.
Такое разбиение позволяет четко определить необходимые операции и их приоритеты.
Способ 5: Декомпозиция по платформам и ОС
Этот метод заключается в разделении требований в зависимости от платформы или операционной системы. Например, для функции оплаты в интернет-приложении можно выделить задачи для различных устройств:
- Персональные компьютеры
- Планшеты
- Смартфоны
- Разные операционные системы: Windows, iOS, Android.
Такой подход помогает определить приоритетные направления разработки.
Способ 6: Разделение по типам данных и параметрам
Некоторые функции могут обрабатывать различные типы данных или параметры. Например, для функции поиска в интернет-магазине можно выделить:
- Поиск по наименованию товара.
- Поиск по номеру товара.
- Поиск с использованием регулярных выражений.
Эта декомпозиция позволяет четко определить допустимые параметры и легко управлять требованиями.
Способ 7: Разделение по ролям и правам доступа
Разные группы пользователей могут иметь разные права доступа и выполнять различные функции. Например, в интернет-магазине это могут быть:
- Владелец: создание и удаление товаров.
- Администратор: редактирование описаний и работа с клиентами.
- Клиент: просмотр и покупка товаров.
Такое разбиение помогает понять, какие функции необходимы для каждой роли и приоритизировать их реализацию.
Способ 8: Декомпозиция по тестовым сценариям
Этот метод разбивает функциональность на основе тест-кейсов, которые необходимо проверить для проверки успешности работы функций. Например, для функции добавления товара в «корзину» могут быть выделены следующие тестовые сценарии:
- Товар доступен для покупки.
- Товар зарезервирован другим пользователем.
- Товара нет в наличии.
Такой подход позволяет объединить различные техники декомпозиции и формирует ясные задачи для разработки и тестирования.
Каждый из этих методов декомпозиции помогает лучше структурировать требования и способствует более эффективной разработке в Agile-среде.
Преимущества Декомпозиции задач:
- Улучшает понимание: Разделение крупных задач (или историй пользователей) на более мелкие позволяет команде лучше понять, что именно требуется сделать. Мелкие задачи легче осмысливать и обсуждать.
- Лучшая оценка: Команда может более точно оценить время и усилия, необходимые для выполнения мелких задач, что улучшает планирование и управление ресурсами (Гарантирует отличный Митинг Планирования используется числами Фибоначчи или последовательность T-Shirt Sizes ).
- Управляемость: Мелкие задачи легче планировать и контролировать. Команда может более точно оценить временные и трудозатратные ресурсы для выполнения каждой задачи.
- Увеличение прозрачности: Когда задачи разбиты на более мелкие части, становится легче отслеживать прогресс и выявлять проблемы на ранних этапах. Это позволяет команде быстро реагировать на изменения.
- Повышение гибкости: В Scrum часто происходят изменения в требованиях, и декомпозиция задач позволяет команде более гибко реагировать на эти изменения, адаптируя свои планы и приоритеты.
- Улучшение качества: Мелкие задачи позволяют команде сосредоточиться на качестве выполнения каждой отдельной части. Это может привести к более высокому качеству конечного продукта.
- Стимулирование сотрудничества: Декомпозиция задач может содействовать более активному сотрудничеству внутри команды, так как участники могут работать над различными частями одной задачи одновременно.
- Постепенная интеграция: Разделение задач на более мелкие части позволяет команде поэтапно интегрировать и тестировать функциональность, что уменьшает риски и улучшает стабильность.
Я надеюсь, что данная информация вам пригодилась! Если у вас есть вопросы или пожелания, оставляйте комментарии. Буду рад помочь вам с личными советами по IT, бизнес-анализу, Scrum или управлению проектами!
Хорошее и понятное описание декомпозиции задач. Утверждение о том, что декомпозицию стоит проводить в процессе реализации спринта, а не привязывать к конкретному спринту, является важным и практичным
Спасибо за ваш комментарий, он заряжает меня энтузиазмом для написания новых постов!
Спасибо за хорошую статью! Полезно иметь под рукой набор возможных вариантов декомпозиции.
Спасибо за положительный отзыв! Это мотивирует меня продолжать писать и делиться полезной информацией!