Декомпозиция задач: Как сделать проекты управляемыми и успешными — 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 или управлению проектами!