Чтобы представить требования к реализации продукта на оптимальном уровне детализации и выровнить эти требования с желаемыми результатами проводят так называемую декомпозицию историй.
В результате декомпозиции историй требования приобретают структуру, повышение детальности которой приводит к для определению различных элементов требований. Начиная с широкого системного контекста и углубляясь на несколько уровней детальнее, удается в конечном итоге определить детальные критерии приемки для отдельных историй.
Работать с большими историями тяжело и они не достаточно понятны. Наиболее распространенный подход к декомпозиции истории формулируют как "сначала ширина, затем глубина. Так декомпозиция сначала описывает высокоуровневое представление о том, какие бизнес-цели должны быть достигнуты, затем представление высокого уровня разлагается на более мелкие компоненты, которые обеспечивают прирост потребительской ценности (иногда называемые минимальными рыночными функциями), и мелкие компоненты разлагаются на истории, и истории разрабатываются на более мелкие приращения с критериями принятия.
Декомпозиция истории происходит постепенно. В инициативах с гибким подходом к реализации первоначальные аналитические мероприятия определяют цели, минимальные функции и большинство крупных историй.
Декомпозиция может быть и не эффективной и заставить тратить на себя много усилий. Это происходит из-за того, что сами истории с течением времени развиваются и претерпечают изменения. И поддерживать детальные требования становится сложной операционной задачей. Поэтому важно следить за нагрузкой, требующей поддержания настоящего уровня детализации.
Из чего состоит декомпозиция историй?
Цели решения
Цели решения - это самый высокий уровень бизнес-требований. Они представляют собой движущие силы для осуществления инициативы и формируют обоснование, на основе которого оцениваются все детализированные потребности уровня.
Минимальная рыночная функциональность / компонент
Минимальные рыночная функциональность - это логические группы функциональных возможностей, которые поставляемое решение должно обеспечивать, чтобы его стоило выпускать. Часто эти группы формируют темы для одного релиза и служат для обеспечения общей картины разрабатываемого продукта.
История
История представляет собой историю пользователей, историю заданий, прецедент использования или требование, которое должно быть реализовано в поставляемом решении.
Критерии приемки
Условия удовлетворения или критерии, необходимые для проверки истории пользователя могут быть записаны в виде списка элементов, спецификаций или пользовательских приемо-сдаточных тестов (или их комбинации). Детальные требования представлены и подтверждены в критериях приемки.
Сильные и слабые стороны метода
+ Помогает избежать распространенной проблемы затеряться в деталях пользовательских историй и потерять общий контекст видения.
+ Важно, чтобы члены команды помнили о целях и задачах проекта и могли отслеживать реализованные или запрошенные функциональные возможности вплоть до основных бизнес-целей.
+ Разбиение продукта на минимальные функциональности и их группы помогает в планировании на уровне релиза, обеспечивает наглядность разработки решения и помогает координировать такие активности, как управление организационными изменениями и обучение пользователей.
- Распространенный анти-паттерн этой методики - является соблазном рассматривать декомпозицию истории как способ прийти к детальным требованиям заранее. Обеспечение постоянного акцента на "точно-достаточно" и "точно-вовремя" означает знание того, когда следует прекратить разложение.
- Декомпозиция истории не должна выполняться на основе процесса, архитектуры или процедуры. Скорее, декомпозиция должна быть сделана на основе оцененных клиентом особенностей.