+7 (499) 638-64-11
Попробовать
Постановка и автоматизация процессов разработки ПО

Декомпозиция на истории - Story Decomposition

Усилиями членов IIBA и экспертами сообщества Agile был разработан черновик The Agile Extension of the BABOK, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.

 

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

 

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

Story Decomposition

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

 

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

Описание

Наиболее распространенный подход Agile к декомпозиции на истории может быть описан как «ширина-перед-глубиной» (breadth-before-depth). Он заключается в том, чтобы начать с высокоуровневой картины бизнес-цели, которая должна быть достигнута, затем разложить ее на более мелкие компоненты, которые обеспечат приращение значимой функциональности (Minimally Marketable Feature, или MMF), разделить компоненты на пользовательские истории, а в конечном итоге разработать пользовательские истории с критериями приемки. История пользователя, которая является слишком большой или сложна для проработки, оценки или поставки (выпуска) иногда называется эпосом (Epic). При использовании эпоса, последний разлагается на более мелкие истории.

 

Различные команды применяют этот метод по-разному. Например, некоторые команды используют модель линейно, как показано на диаграмме выше, в то время как другие команды адаптируют эти методы для работы в своей среде. Например, как только команда разработала MMF, она может использовать прецеденты (use cases), а не истории (user story). Ролью аналитика здесь является фокусировка внимания на динамическом взаимодействии, упрощении и коммуникации, что необходимо для разработки и поставки продукта.

 

В следующей таблице описываются различные уровни декомпозиции на истории.

УровеньОписание

Цели системы

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

MMF/Компонент

MMF расшифровывается как Minimally Marketable Feature. Это - логические группы функциональности и возможностей поставляемого продукта, необходимые для определения цены (позиционирования на рынке). Часто они должны формировать «темы» для отдельного релиза и служат для передачи общего замысла для продукта на стадии разработки.

Эпос (Epic)

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

История пользователя (User Story)

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

Критерии приемки (Acceptance critera)

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

Особенности использования

Декомпозиция на истории осуществляется постепенно. Одним из наиболее существенных различий между проектами Agile и водопадными проектами (Waterfall) является определение детальных требований. В проектах Agile, первые шагом анализа будет определение цели, MMF, и большинства эпосов. Начальный набор пользовательских историй (возможно, для первого релиза продукта) будет выполнен в самом начале проекта. Существует четкое понимание, что эти истории, вероятно, изменятся, и что понимание командой требований будет развиваться с течением времени. Таким образом, декомпозиция на самом низком уровне детализации, вероятно, будет нецелесообразна на ранних этапах проекта.

Преимущества

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

Недостатки

  • Общей анти-моделью является соблазн рассматривать декомпозицию на истории пользователей как способ возвращения к заранее детализированным требованиям. Обеспечение постоянного акцента на достаточности и своевременности позволяет определить предел декомпозиции.

Еще интересные статьи на эту тему: