Те, як ми працюємо з Epics, Stories and Features, полягає в наступному
На початку циклу проекту ми придумуємо Epics . Це дуже високі, майже орієнтовані на маркетинг, кулі-функції. Те, що ви можете використовувати у резюме, наприклад,
Наш новий веб-сайт дозволить клієнтам переглядати продукти, переглядати наявність та ціни, розміщувати замовлення та бачити їхню минулу історію замовлень
Це призводить до таких епосів, як
- Переглянути каталог товарів
- Переглянути доступність
- Перегляд цін
- Зробити замовлення
- Переглянути історію замовлень
Вони записуються як розповіді користувачів (наприклад, як замовник, я хочу переглянути каталог товарів, щоб я міг прийняти обгрунтоване рішення про покупку), але служити лише початком для десяти для того, що буде реально розроблено та випущено.
Потім ці епоси розбиваються на Історії користувачів . Це фактичні подорожі користувача від кінцевого до кінця, дуже обмежені за обсягом і визначені таким чином, що їх можна оцінювати та планувати незалежно, а також розробляти , тестувати та випускати за один цикл випуску.
Історія користувача - одиниця доставки. Це історія користувача, яка є повною чи незавершеною, виходить у прямому ефірі чи не виходить у прямому ефірі.
Епічний додаток може спричинити велику кількість історій користувачів, не всі вони будуть розроблені або випущені одночасно.
Наприклад, епічний перегляд продуктового каталогу може зламатись
- Навігація по Ієрархії категорій
- Пошук за ключовим словом
- Фільтр за ознаками товару (наприклад, ціновий діапазон, марка, колір, розмір тощо)
Знову ж таки, кожен із них буде записаний у форматі, наприклад, як замовник, я хочу орієнтуватися на ієрархію категорій, щоб я міг переглядати продукти та переходити до продукту, найбільш відповідного для моїх потреб.
Як правило, для більшості наших проектів ми маємо десятки епосів і сотні історій.
Тепер, проходячи життєвий цикл історії, ми позначаємо ці історії за допомогою Feature s. Наприклад, усі історії перегляду, пошуку та запасів та цін будуть позначені тегами, скажімо, "продукту-каталогу". Історії замовлення на місця, пов’язані з оплатою кредитною карткою, можуть бути позначені міткою "кредитна картка", а ті, що стосуються оплати через PayPal, позначаються міткою "paypal".
Ці етикетки служать для групування історій, які належать разом, не тому, що вони різні типи, що виконують одну й ту саму діяльність (наприклад, всі розповіді про місце на замовлення), а тому, що вони повинні бути видані разом.
Наприклад, історія "розміщення замовлення оплатою кредитною карткою" належить до тієї ж епопеї, що й історія "замовлення оплати через PayPal", але їх не потрібно видавати разом.
Тоді як історія "розміщення замовлення оплатою кредитною карткою", історія "обробка повернення повернення на кредитну карту" та історія "що дозволяють клієнтам управляти збереженими кредитними картками на своєму рахунку", схоже, належать одне одному . Усі вони були би позначені ярликом функції "кредитна картка". тобто всі вони належали б до функції "Кредитна картка". Не дуже корисно звільнити можливість робити замовлення, оплачуючи кредитною карткою, якщо неможливо обробити повернення повернення на PayPal або якщо неможливо керувати збереженими кредитними картками на вашому рахунку
Примітка : як загальне правило, тобто. Це, зрештою, ділове рішення. Якщо час на ринок важливий, може бути законна причина жити з одним, а не з іншим.
Таким чином, Epics служать для розбиття на (пов'язані, але окремі) історії, які можна розробити самостійно, тоді як Особливості служать для групування історій, які слід випустити разом.
Можна сказати, що Epics розкладається на Історії користувачів, а Історії користувачів складаються у Особливості. Історії, що належать до функції, зазвичай надходять у епіках. Таким чином, епоси та риси є ортогональними, не в строгій ієрархії.
У нашому способі роботи, коли Епіки розбиті на історії, вони втрачають своє призначення. Ми не оцінюємо і не плануємо Epics. Ми не відстежуємо прогрес у програмі Epics. Ми не випускаємо Epics. Ми оцінюємо, плануємо та відстежуємо Історії користувачів. І ми випускаємо Особливості.
