У світі Agile основним елементом вимог прийнято вважати історії користувачів (user stories, побажання). У класичному Скрам, (такому, про який говорять його творці), не знайти ні специфікацій. ні опису варіантів використання (use cases), ні, тим більше, документів з лякаючим словом ТЗ.
Вся робота по проекту побудована навколо невеликих за розміром, зрозумілих кожному учаснику проекту побажань, які легко оцінюються, легко обговорюються з замовником і які можна реалізувати в рамках короткої ітерації тривалістю один-два тижні.
Доброю практикою є додавання до кожної історії набору приймальних критеріїв, за якими буде оцінюватися правильної реалізації історії. Наприклад, приймальні критерії можуть бути:
- "Можна задати новий тег або вибрати існуючий зі списку"
- "На повідомлення може бути задано декілька тегів"
- "Теги повідомлень утворюють хмару тегів"
- "Хмара тегів є на будь-якій сторінці блогу".
У більшості проектних команд (по крайней мере, в Росії), приймальні критерії до історій не пишуть - замість цього перераховані вище деталі історії записуються в її опис.
Все це добре відомі речі, з історіями користувачів ми всі працюємо далеко не перший рік.
Але існує ще один термін, набагато менш поширений у нас - Epic (епік). Що ж це таке, навіщо воно і чим відрізняється від історій користувачів?
Справа в тому, що починаючи формувати історії користувачів, тобто збирати вимоги до проекту. ми зазвичай рухаємося від більш загального до більш приватного - спочатку визначаємося з концепцією проекту, виділити основні персони (користувачі системи), формуємо перелік основних фіч, і далі ці фічі деталізуємо на окремі побажання.
В даному прикладі активність в системі якраз і є Epic - тобто по суті, це просто велика історія користувача, відмінною особливістю якої є наявність явної цінності для користувача (персони).
Давайте подивимося на відмінності в наведених прикладах історії користувача і епіка:
Mike Cohn, найбільш впливовий в Agile спільноті гуру історій користувачів, пропонує описувати епіки за тим же шаблоном, що і історії користувачів, як в наведеному вище прикладі.
Насправді, звичайно, і персона, і епік, і історія користувача - це всього навсього інструменти, якими ви можете користуватися для управління вимогами в своїх проектах. І то, як саме ви їх застосовуєте, залежить, в першу чергу, від вашого розуміння "як це робити правильно".
Використовуючи Devprom в своїх проектах, ми записуємо Активності в системі (epic) в якості Функцій, в прив'язці до яких створюються Побажання (історії користувачів). При цьому Персони - це просто теги ( "Блоггер Іванов"), за якими легко можна отримати зріз всієї необхідної цієї персони функціональності.