Історії користувача, сценарії використання, історії завдань та описи вимог — це чотири способи зафіксувати, що має робити програмне забезпечення. Їх часто подають як суперників, але вони відповідають на різні запитання на різних рівнях деталізації. Історія користувача ставить запитання, хто хоче чого і чому. Сценарій використання описує взаємодію крок за кроком, включаючи можливі помилки. Історія завдання починається зі ситуації, в якій опинився користувач. Вимога визначає правило, яке система повинна виконувати.
Цей гід порівнює чотири підходи, показує одну й ту саму функцію, описану кожен раз, і пояснює, коли що використовувати. Для основних принципів написання історій дивіться наш гід у розділі як писати user stories.
Швидке порівняння
| User story | Сценарій використання | Історія завдання | Опис вимоги | |
|---|---|---|---|---|
| Формат | Як [користувач], я хочу [дія], щоб [вигода] | Актор, ціль, попередні умови, основний сценарій успіху, розширення, кінцеві умови | Коли [ситуація], я хочу [мотивація], щоб я міг [очікуваний результат] | Система повинна [поведінка або обмеження] |
| Орієнтація на | Тип користувача та його ціль | Взаємодію між актором і системою | Ситуацію та мотивацію, а не персону | Поведінку або якість системи |
| Довжина | Одне речення плюс критерії прийняття | Від половини сторінки до кількох сторінок | Одне речення | Одне речення на вимогу, багато в документі |
| Походження | Екстремальне програмування; формат від Connextra (2001) | Івар Якобсон (кінець 1980-х); стиль, орієнтований на цілі, від Алістера Кокберна (2000) | Пол Адамс в Intercom; розроблений Аланом Клементом (2013) | Традиційна інженерія вимог (сьогодні ISO/IEC/IEEE 29148) |
| Найкраще для | Гнучкі беклоги та планування спринтів | Складні процеси, інтеграції, регульована або контрактна робота | Дослідження та дизайн, особливо для різноманітних користувачів у однаковій ситуації | Нефункціональні вимоги, відповідність стандартам, контракти з фіксованим обсягом робіт |
| Слабке місце | Демонстрація всього процесу та граничних випадків | Швидкість; складно залишатися в актуальності при швидких ітераціях | Планування та оцінка обсягу робіт самостійно | Пояснення причин; легко складати переліки, які неможливо перевірити |
Історії користувача
Історія користувача — це короткий опис можливості, поданий з точки зору людини, яка її потребує. Звичний формат, «Як [тип користувача], я хочу [дія], щоб [вигода]», з’явився в команді Connextra у 2001 році та поширився завдяки книзі Майка Коуна User Stories Applied. Історії розвивалися в екстремальному програмуванні, де вони навмисно були короткими: Рон Джеффрі описував кожну історію як картку, розмову та підтвердження (3 Cs). Картка не є специфікацією; саме під час розмови узгоджуються деталі, а критерії прийняття їх підтверджують.
Переваги: історії достатньо малі, щоб їх можна було оцінити та завершити в межах спринту, вони легко читаються нетехнічними стейкхолдерами та тримають фокус на цінності («щоб»). Майк Кон викладає аргументи на їхню користь у Переваги історій користувача для вимог.
Обмеження: беклог окремих історій не показує, як вони поєднуються в єдиний процес, а формат сприяє пропуску випадків помилок. Команди вирішують першу проблему за допомогою карти історій користувача а другу — за допомогою якісно написаних критеріїв прийняття (див. наші шаблон історії користувача).
Випадки використання
Випадок використання описує, як актор (людина або інша система) використовує систему для досягнення мети, у вигляді послідовності кроків, разом із шляхами, якими ця послідовність може розгалужуватися або зазнавати збоїв. Івар Якобсон запровадив випадки використання наприкінці 1980-х, а книга Елістера Кокберна Writing Effective Use Cases (2000) закріпила орієнтований на мету стиль простого тексту, який більшість команд використовує сьогодні (сайт Кокберна).
Повний випадок використання зазвичай включає:
- Основний актор: хто ініціює взаємодію.
- Мета та область: чого хоче актор і яку систему описано.
- Попередні умови: що вже має бути істинним.
- Тригер: що запускає випадок використання.
- Основний сценарій успіху: пронумеровані кроки, коли все відбувається без збоїв.
- Розширення: альтернативні та шляхи збоїв, кожен прив’язаний до кроку, де відбувається розгалуження.
- Постумови або гарантії: що є істинним наприкінці, у разі успіху та збою.
Переваги: розділ розширення змушує думати про те, що може піти не так, а повний процес видно в одному місці, що є цінним для інтеграцій, платежів та будь-яких аудитованих систем. Обмеження: на написання та оновлення випадків використання потрібно більше часу, і зазвичай один випадок використання занадто великий, щоб реалізувати його в межах одного спринту.
Випадки використання адаптувалися до гнучкої роботи. У Use-Case 2.0Якобсон та колеги розбили кожен випадок використання на «зрізи», кожен з яких достатньо малий для планування та тестування, що виконує майже ту саму роль, що й історії користувача.
Історії завдань (jobs to be done)
Історія завдання замінює персону ситуацією: «Коли [ситуація], я хочу [мотивація], щоб [очікуваний результат]». Ця ідея вперше згадувалася Полом Едамсом у блозі Intercom та розвивалася Аланом Клементом, який пояснив її у гостьовій публікації в Intercom 2013 року, Використання історій завдань для проєктування функцій. Вона застосовує підхід jobs-to-be-done, пов’язаний із Клейтоном Крістенсеном, до проєктування функцій.
Аргумент на користь історій завдань полягає в тому, що «Як зайнятий батько» містить припущення, які команда не може перевірити, тоді як ситуація («Коли я збираюся виходити з дому і згадую, що забув замовити продукти») пояснює терміновість, обмеження та те, як для користувача відчувається стан «виконано». Дві дуже різні персони в однаковій ситуації часто потребують одного й того самого.
Переваги: історії завдань добре працюють на етапах дослідження та дизайну, тримають команду в фокусі на контексті та породжують кращі запитання для інтерв’ю з клієнтами. Обмеження: вони мало говорять про те, хто має право робити що, що важливо для прав доступу та ролей, і більшість команд все одно перетворюють їх на історії користувача або завдання для планування.
Формулювання вимог
Традиційний формат — це пронумероване твердження: «Система має блокувати обліковий запис після п’яти невдалих спроб входу». Специфікації вимог досі є нормою в регульованих галузях, державних тендерах та контрактах з фіксованою ціною, а чинним міжнародним стандартом для їх написання є ISO/IEC/IEEE 29148.
Гнучкі команди також використовують формулювання вимог, переважно для нефункціональних вимог (продуктивність, безпека, доступність, зручність використання), які стосуються багатьох історій. Їх часто записують один раз, у визначенні готовності або на короткій сторінці з атрибутами якості, замість того щоб повторювати їх у кожній історії.
Одна й та сама функція, описана трьома способами
Функція: у застосунку для спільних витрат мешканців однієї квартири людина щось купує і ділить вартість з іншими.
Як історія користувача
Як мешканець, який оплатив спільну покупку, я хочу поділити вартість з тими, для кого вона була призначена, щоб у балансі кожного відображалося, скільки вони мені винні.
- Я можу вибрати, які учасники групи ділять вартість; за замовчуванням я включений.
- За замовчуванням поділ рівний; я можу перейти до точних сум або відсотків.
- Застосунок не збереже поділ, частини якого не складають загальної суми, і вкаже, на скільки він не збігається.
- Баланс кожної особи оновлюється одразу після збереження витрати, і їм надсилається сповіщення.
Як випадок використання
Випадок використання: Поділ витрат. Основний актор: Платник. Попередня умова: платник увійшов у систему і належить до групи, що має принаймні одного іншого учасника. Тригер: платник обирає «Додати витрату».
- Платник вводить суму, опис і дату.
- Система показує учасників групи, з платником, обраним за замовчуванням.
- Платник обирає учасників, які ділять вартість.
- Система пропонує рівний поділ і показує кожну частку.
- Платник підтверджує.
- Система зберігає витрату, оновлює всі баланси та сповіщає обраних учасників.
- 4а. Платник переходить до точних сум або відсотків: система перераховує значення під час введення кожного.
- 5а. Частки не складають загальної суми: система блокує збереження та показує різницю.
- 6а. Пристрій офлайн: система зберігає витрату локально, позначає її як очікувану та синхронізує після повернення в мережу.
- Постумова при успіху: витрата записана один раз, і кожен баланс її відображає. При невдачі: жодних змін у балансах.
Як історія завдання
Коли я щойно оплатив щось на касі, частина чого призначена для моїх співмешканців, я хочу записати це, поки не забув суму, щоб отримати гроші назад, не доводиться нікого переслідувати.
Як формулювання вимог
- REQ-1: Система має дозволити учаснику групи записати витрату з сумою, описом, датою та платником.
- REQ-2: Система має дозволити платнику поділити витрату рівно, за точними сумами або за відсотками.
- REQ-3: Система має відхилити поділ, частини якого не дорівнюють загальній сумі.
- REQ-4: Система має оновити всі зачеплені баланси протягом двох секунд після збереження.
Подивіться, що виявила кожна версія. Історія користувача найлегша для оцінки та планування. Випадок використання єдиний, що підняв питання про роботу офлайн та визначив, що має бути істинним, якщо збереження не вдасться. Історія завдання виявила реальне обмеження, а саме швидкість на касі; вона підказує, що перший екран має запитувати лише суму, про що не підказала б жодна інша версія. Вимоги додали вимірюваний цільовий показник продуктивності, який історія залишила невисловленим.
Яку з них варто використовувати?
| Ситуація | Почніть з | Чому |
|---|---|---|
| Раннє дослідження, інтерв’ю, визначення того, що будувати | Історії завдань | Вони тримають команду в контексті користувача та допомагають ставити кращі запитання під час інтерв’ю |
| Гнучкий беклог продукту, планування спринтів | Історії користувача з критеріями приймання | Малі, оцінювані та зрозумілі всім |
| Складний процес, інтеграція, рух коштів | Випадок використання, а потім розбити його на історії | Розширення виявляють шляхи збою, перш ніж вони стануть помилками |
| Регульований продукт, публічний тендер, договір з фіксованою ціною | Формулювання вимог, часто пов’язані з сценаріями використання | Аудитори та договори потребують пронумерованих, перевірених тверджень |
| Цілі щодо продуктивності, безпеки та доступності | Формулювання вимог або визначення критеріїв завершеності | Вони застосовуються до багатьох історій, а не до однієї |
| MVP з невеликою командою | Карта історій користувача, з одним сценарієм використання для найризикованішого потоку | Достатня структура для швидкого визначення обсягу та побудови |
Чи можна їх поєднувати?
Так, і більшість досвідчених команд це роблять. Працездатна послідовність виглядає так:
- Використовуйте історії завдань під час досліджень, щоб зафіксувати ситуації та мотивації реальних користувачів.
- Розташуйте отримані можливості на карті історій у вигляді історій користувача та оберіть перший зріз релізу.
- Для одного-двох потоків, де поразка коштує дорого (платежі, реєстрація, синхронізація даних), напишіть легкий сценарій використання, щоб знайти розширення, а потім перетворіть кожне розширення на окрему історію або критерій приймання.
- Зафіксуйте поперечні вимоги (продуктивність, безпека, доступність, відповідність стандартам) один раз, у вигляді пронумерованих тверджень або у визначенні критеріїв завершеності.
Загальне правило: пишіть стільки, скільки команді потрібно, щоб безпечно побудувати правильну річ. Команді з трьох осіб для MVP не потрібен документ вимог, а інтеграція з банком не повинна спиратися на одне речення.
Часті помилки
- Написання сценаріїв використання як скриптів інтерфейсу («користувач натискає синю кнопку»), що прив’язує вимогу до дизайну, який змінюватиметься.
- Написання історій користувача без «щоб», що лишає команду не в змозі запропонувати простіше рішення.
- Сприйняття історії завдання за персонажа («Коли я — зайнята мама...»); ситуація має бути моментом, а не ідентичністю.
- Копіювання довгого списку вимог у беклог як однієї історії на рядок, що породжує історії без користувача та без цінності.
- Використання різних форматів у одному беклозі без домовленості про те, який із них є джерелом істини.
Часті запитання
Яка основна відмінність між історією користувача та сценарієм використання?
Історія користувача — це опис одним реченням того, хто хоче певну можливість і чому, що використовується для планування та пріоритизації робіт. Сценарій використання — це покроковий опис взаємодії між актором і системою, включаючи альтернативні та аварійні шляхи. Історії менші та менш детальні; сценарії використання показують увесь потік.
Чи є історія користувача вимогою?
Це легкий спосіб зафіксувати вимогу, але не повна специфікація. Деталі містяться в розмові та критеріях приймання. Неналічні вимоги, такі як продуктивність і безпека, часто фіксуються окремо.
Чи сценарії використання все ще використовуються в agile-командах?
Так, переважно для складних або високоризикованих потоків. Use-Case 2.0, розроблений Іваром Якобсоном та колегами, розбиває сценарії використання на зрізи, які можна планувати як історії користувача, тому обидва формати можуть існувати в одному беклозі.
Яка відмінність між історією завдання та історією користувача?
Історія користувача починається з типу користувача («Як...»). Історія завдання починається з ситуації («Коли...») та фокусується на мотивації та очікуваному результаті. Історії завдань походять із підходу jobs-to-be-done та найкраще підходять для досліджень та дизайну.
Чи може один сценарій використання перетворитися на кілька історій користувача?
Так. Основний сценарій успіху часто стає однією-двома історіями, а кожне важливе розширення — окремою історією або критерієм приймання. Це надійний спосіб розбити велику функцію, не втрачаючи граничних випадків.
Яка відмінність між сценарієм використання та тестовим випадком?
Сценарій використання описує, як система повинна поводитися, щоб досягти мети актора. Тестовий випадок перевіряє один конкретний шлях через цю поведінку з конкретними вхідними даними та очікуваними результатами. Один сценарій використання зазвичай породжує кілька тестових випадків.
Не впевнені, скільки специфікації потрібна вашому продукту? Ми допомагаємо засновникам перетворити ідеї на беклог з визначеним обсягом, а потім реалізувати його за коротких спринтів. Дивіться наші щомісячні плани розробки.