Декомпозиція історій (Story Decomposition)

Декомпозиція історії (Story Decomposition) використовується для представлення вимог до рішення на відповідному рівні деталізації та узгодження з бажаними результатами.

Декомпозиція історій (Story Decomposition) одна з методик Agile Extension to the BABOK® Guide v2

Опис Декомпозиції історій (Story Decomposition) в Agile Extension v2 (7.18.2)

Декомпозиція історій (Story Decomposition) забезпечує структуру для визначення різних елементів вимог на поступово менших рівнях деталізації, починаючи з широкого контексту системи і заглиблюючись на кілька рівнів, щоб врешті-решт визначити детальні критерії прийнятності для окремих історій.

Будь-яка історія, яка є занадто великою або недостатньо зрозумілою, щоб її можна було розробити, оцінити або представити як історію, готова до декомпозиції. Найпоширеніший гнучкий підхід до декомпозиції історії можна описати як "спочатку вшир, а потім вглиб" “breadth-before-depth”:

• Спочатку декомпозиція описує загальне бачення того, яких бізнес-цілей необхідно досягти,
• високорівневе бачення декомпозується на менші компоненти, які забезпечують приріст споживчої цінності (іноді їх називають мінімальними ринковими характеристиками (minimal marketable features) або MMFs), і
• ці менші компоненти декомпозуються в історії, а історії розробляються на менші кроки з критеріями прийнятності (див. 7.19. Розробка історії (Story Elaboration)).

Декомпозиція історії (Story Decomposition) здійснюється поступово. У гнучких ініціативах на початковому етапі аналізу визначаються цілі, MMF і більшість великих історій. Початкова декомпозиція історій завершується поступово.

Існує неявне розуміння того, що ці історії, ймовірно, будуть змінюватися і що розуміння вимог буде розвиватися з часом. Тому декомпозиція до найнижчого рівня деталізації, ймовірно, буде марнотратною діяльністю на початку ініціативи.

Декомпозиція історії (Story Decomposition) застосовується по-різному залежно від контексту. Наприклад, деякі фахівці з бізнес-аналізу дотримуються лінійної моделі, показаної на схемі вище, тоді як інші використовують методи, які найкраще працюють у їхньому середовищі.

Після того, як MMF або функціональні групи розроблені, замість історій можна використовувати кейси використання. Фахівці з бізнес-аналізу зосереджуються на динамічній співпраці, фасилітації та комунікації, щоб отримати схвалення мінімально необхідних деталей для розробки та впровадження рішення.

Елементи Декомпозиції історій (Story Decomposition) в Agile Extension v2 (7.18.3)

Цілі рішення (Solution Goals)

Цілі рішення (Solution Goals) - це найвищий рівень бізнес-вимог. Вони представляють бізнес-рушійні сили для реалізації ініціативи та формують обґрунтування, на основі якого оцінюються всі потреби детального рівня.

MMF/Компонент

Мінімальні ринкові функції (Minimal marketable features - MMF) - це логічні групи функціональності та можливостей, які повинно надавати рішення, щоб його варто було випускати. Часто вони формують теми для окремого релізу і слугують для створення загальної картини контексту продукту, що розробляється.

Історія (Story)

Являє собою історію користувача, історію роботи, кейс використання або вимогу, яку необхідно реалізувати в наданому рішенні.

Критерії прийнятності (Acceptance Criteria)

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

Міркування щодо використання Декомпозиції історій (Story Decomposition) в Agile Extension v2 (7.18.4)

Сильні сторони Декомпозиції історій (Story Decomposition)

• Допомагає уникнути поширеної проблеми - загубитися в деталях користувацьких історій і втратити контекст загальної картини.
• Важливо, щоб члени команди пам'ятали про цілі та завдання проекту і могли відстежувати реалізовану або запитувану функціональність назад до рушійних бізнес-цілей.
• Розбиття продукту на MMF та епіки допомагає планувати реліз, забезпечує видимість розробки рішення та допомагає координувати зовнішні програмні заходи, такі як управління організаційними змінами та навчання користувачів.

Обмеження Декомпозиції історій (Story Decomposition)

• Поширеною антипаттерном є спокуса розглядати декомпозицію історії як спосіб повернення до детальних вимог наперед. Забезпечення постійного акценту на "достатньо" і "вчасно" означає, що потрібно знати, коли зупинити декомпозицію.
• Декомпозиція історії (Story Decomposition) не повинна базуватися на процесі (крок 1, 2 і 3 в потоці), архітектурі (створити базу даних, створити сервер, створити інтерфейс) або процедурі (спроектувати, побудувати, протестувати). Скоріше, декомпозицію слід проводити на основі особливостей, важливих для клієнта.

Якщо стаття була для вас корисна підпишіться на розсилку або на мій телеграм канал.