Первый и, возможно, самый главный этап работы с Product Backlog в Agile заключается в декомпозиции задач, разбиении разноплановых требований на атомарные, понятные пользовательские истории (User Stories). Чем качественнее разбиты требования, тем понятнее их смысл и способы реализации, а также тем точнее можно запланировать время работы над ними. Чем задачи, тем выше шансы достичь целей спринта, тем более прогнозируемые составы релизов.

Как же провести декомпозицию требований в Product Backlog? Рассмотрим 8 техник, которые помогут эффективно выполнить разбивку требований на User Stories. В работе по Agile большим плюсом будет одновременное применение нескольких вариантов декомпозиции, поэтому важно представлять спектр возможных методов.

Зачем и в какой момент следует проводить декомпозицию требований?

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

• Если в рамках итерации (спринта) мы работаем над несколькими большими и сложными задачами, то, во-первых, такие задачи будет сложно оценить с высокой точностью, во-вторых, недооценка даже одной из них может сильно повлиять на достижение целей спринта. Ведь не выпустить 1 из 2 запланированных фич, это сразу -50% полезного результата. 
• Мелкие и атомарные задачи напротив имеют не такое серьезное влияние на цели спринта, так как их больше планируется на спринт (а значит каждая имеет меньший вклад) и их оценка будет гораздо точнее.

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

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

 

Два основных подхода к декомпозиции.

Существует две концепции, два базовых подхода к декомпозиции крупных задач на пользовательские истории – «горизонтальное» и «вертикальное» разбиение:

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

Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:

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

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

 

Техники декомпозиции требований в Agile

Метод 1: Разбиение по этапам\фазам бизнес процесса.

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

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

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

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

 

Метод 2: Разбиение по позитивным и негативным сценариям.

Фактически каждая функциональность имеет правильный\прямой сценарий использования, который приводит к ожидаемому\позитивному результату. Однако, когда пользователь работает с тем или иным функционалом могут произойти отклонения от правильного процесса: переданы не те данные, выполнены не все обязательные условия, нет необходимых прав доступа и т.п. Такие отклонения от прямого сценария работы приведут к негативным результатам (действие не выполнится, функция отработает некорректно и т.п.).

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

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

В качестве примера декомпозиции требований на позитивные\негативные сценарии снова рассмотрим функцию покупки в интернет магазине:

• Позитивный сценарий: пользователь заходит в свою учетную запись на сайте и совершает покупку оплачивая ее по карте. Или в формате пользовательской истории: «как клиент я могу войти в свою учетную запись, чтобы совершить покупку по карте».
• Негативный сценарий 1: клиент пробует совершить покупку без авторизации.
• Негативный сценарий 2: пользователь пробует совершить покупку, но у него на счету не хватает средств и оплата не проходит.
• Негативный сценарий n: клиент пробует совершить покупку, но его учетная запись заблокируется из-за неправильного ввода пароля.

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

 

Метод 3: Разбиение по правилам\условиям бизнес процесса.

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

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

Данный метод разбиения требований позволяет:

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

 

Метод 4: Разбиение по видам операций.

Существует ряд относительно стандартных операций, которые часто встречаются в различных функциях. Эти операции можно отнести к разряду набора действий «по умолчанию»: создать, читать, обновить или удалить. Сокращенно метод называется CRUD – от слов Create, Read, Update, Delete. Операции CRUD очень распространены в случаях, когда функциональность включает управление объектами, такими как продукты, заказы, пользователи, файлы и т.д.

На примере все того же интернет магазина можно сделать такую декомпозицию функциональности по работе с карточкой продукта:

• Create - создание нового продукта в интернет магазине
• Read - просмотр описания продукта
• Update - редактирование\обновление описания продукта
• Delete - удаление продукта из магазина

Декомпозируя функциональность таким образом достаточно легко ответить на следующие вопросы:

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

 

Метод 5: Декомпозиция по типам платформы/ОС.

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

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

• Для разных платформ: персональные компьютеры, планшеты, смартфоны.
• Для разных ОС: Windows, iOS, Android.
• Для работы в различных браузерах.

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

 

Метод 6: Разбиение по типам данных и параметрам.

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

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

• Поиск с использованием текста (наименование товара)
• Поиск с использованием числовых значений (номер товара)
• Поиск с использованием регулярных выражений

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

 

Метод 7: Разбиение по ролям\правам доступа.

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

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

• Владелец интернет магазина:
  • Создание\удаление продукта в интернет магазине.
  • Просмотр и редактирование описания продукта.
• Администратор интернет магазина:
  • Просмотр и редактирование описания продукта.
  • Отработка запросов\комментариев клиентов. 
• Клиент\покупатель:
  • Просмотр описания продукта.
  • Резерв\покупка товаров в интернет магазине.

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

 

Метод 8: Декомпозиция по сценариям тестирования\тест-кейсам.

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

Рассмотрим пример функциональности – клиент выбирает товар в интернет магазине и откладывает его в «корзину» для совершения покупки. В рамках этой функциональности могут быть выделены следующие тестовые сценарии (ниже только пример части возможных тест-кейсов):

• Товар есть в наличии и он доступен покупки.
• Товар есть в наличии, но он уже зарезервирован другим покупателем
• Товара нет в наличии

Какие преимущества дает использование данного метода декомпозиции:

• Эта стратегия фактически объединяет многие техники декомпозиции, которые были рассмотрены ранее. В процессе формирования списка тест-кейсов мы автоматически проанализируем:
  • Условия и правила бизнес процесса
  • Позитивные и негативные сценарии использования функционала
  • Форматы данных и параметров.
• Анализируя тестовый сценарий легко понять насколько он распространен и вероятен в условия реального использования продукта, что позволяет выставить соответствующие приоритеты.
• При таком способе разбиения мы сразу получаем и описание для задачи\пользовательской истории и сценарий, по которому можно проверить успешность ее реализации.

Смотрите также:

Agile: 7 техник оценки задач

Agile: методы приоритезации задач