Оригінальна стаття перекладена Софією Зеленською, ревью – Іван Вільчавський.
Класична дилема
User Stories vs Use Cases! Що з цього використовувати? Коли краще використовувати? Який із цих методів кращий? Який із них більше підходить для мого проекту? Що, якщо я виберу один метод замість іншого?
Як бізнес-аналітик, ви, можливо, стикалися з цими питаннями протягом своєї кар’єри. Іноді відповідь дуже чітка, а іноді однозначної відповіді може і не бути. Ви повинні зробити найбільш вдале припущення і рухатися далі. Тому, перш ніж обговорювати відповіді, розгляньмо поняття.
Що таке Use Case?
Use Case (сценарій користування) являє собою вимогу у вигляді взаємодії користувача із системою. Use Case завжди пишеться з урахуванням конкретної мети користувача. Кожен Use Case повинен містити актора і дієслово. Наприклад, “онлайн-покупець” — це актор, а “додати товар у кошик” — дієслово.
Use Case діаграма відображає обсяг усіх функцій рішення. Вона відповідає нотації Unified Modelling Language™ та складається з декількох Use Cases, які разом утворюють загальну систему.
Що таке User Story?
User Story (історія користувача) — це артефакт бізнес-аналізу, який орієнтований на користувача або персону. User Story описує бізнес-потребу у вигляді можливості, яку користувач (або система) хоче отримати для вирішення запиту. У цій User Story також має бути зазначено, навіщо потрібна ця можливість та її переваги. Однак вона не має чіткого визначеного правилами формату.
User Story є частиною беклогу (продукту/проекту). Беклог у свою чергу містить User Story/завдання(вимоги) у лінійному порядку. Його зазвичай пріотеризують від вищого до нижчого, а коли пріоритети однакові — додатково ранжують. Якщо пріоритети визначаються за бізнес-цінністю User Story/завдання (вимоги) у беклозі, він називається керованим. У багатьох проектах User Stories також представлені візуально у вигляді User Story карти, яка є структурованою візуалізацією беклогу. Тобто User Stories переносяться з лінійного беклогу на візуальну робочу дошку.
Кожна з цих концепцій сама по собі є детальною темою. У контексті цієї статті я обмежуся лише ознайомленням із ними на початковому рівні. Тепер розгляньмо відмінності та подібності між User Story та Use Case.
Відмінності між User story та Use case
- Формальний vs неформальний:
Використання Use Case є дещо формальним у своєму представленні. Конструкція має специфічні елементи, такі як первинні та вторинні користувачі, передумова, пост-умова, основні альтернативні та виключні потоки тощо.
User Stories натомість мають неформальний характер та пишуться переважно простою мовою. Бізнес-аналітики забезпечують їх спільне написання. Agile практики передбачають, щоб User Story містить персони, можливості, переваги та Acceptance Criteria.
- Waterfall vs Agile:
Use Cases зазвичай використовуються в проектах, які слідують методології Waterfall. Вони використовуються, коли вимоги є досить чіткими та визначеними, що дозволяє відразу проектувати, розробляти і тестувати. Тоді як User Stories прив’язані до світу Agile продуктів і проектів. Вони найкраще підходять у випадках, коли вимоги більш мінливі, оскільки використовуються для ітеративного визначення вимог.
- Взаємодія користувача та системи vs орієнтація на кінцевого користувача:
Use Cases більше акцентують увагу на акторі та його взаємодії із системами, а також на їх взаємозв’язках і залежностях. Тоді як User Stories орієнтовані на кінцевого користувача і використовуються для узгодження того, що потрібно користувачам і як функція принесе їм найбільшу користь. Користувацький інтерфейс і взаємодія пізніше розробляються з урахуванням цих потреб.
- Високий рівень деталізації vs будь-який іншого рівня:
У випадку User Stories вимоги визначаються ітеративно і мають версії 1,2,3 і т.д., поки не буде досягнута ясність у вимогах. Тоді як для Use Cases такого рівня не існує, бо вони вже знаходяться на найбільш детальному рівні.
- Акцент на трасуванні (відстежуваності) vs акцент на прийнятності та тестуванні:
Use Cases роблять сильний акцент на структурі, а також на відстежуваності від бізнес-вимог до інших Use Cases. У той час як User Stories роблять акцент на тому, як відбуватиметься тестування та що визначатиме прийнятність даної User Story.
Подібності між User Story і Use Case
- Обидва методи представляють собою способи формулювання вимог:
Це може здатися тривіальним, але справа в тому, що обидва ці способи є дуже корисними і перевіреними часом. Кожен із них є чудовим інструментом аналізу та документування вимог для бізнес-аналітика. Не можна сказати, що один із них краще за інший, просто кожен корисніший у тій чи іншій ситуації.
- Обидва методи дозволяють задавати питання і стейкхолдерам, і бізнес-аналітикам
Обидва дозволяють командам задавати питання в певному напрямку і допомагають бізнес-аналітикам рухатися до кращої ясності вимог. Конструкції або шаблонні елементи User Story або Use Case є простими підказками, які дозволяють бізнес-аналітикам ставити конкретні запитання стейкхолдерам.
Запитання або виявлення інформації від зацікавлених осіб та з інших джерел ведуть до отримання додаткових даних, які дають більш глибоке розуміння потреб стейкхолдерів. Таким чином, як Use Case, так і User Story допомагають виявити акторів, потрібні дієслова, кроки, результати і т.д.
- Обидва методи орієнтовані на дію:
User Story і Use Case орієнтовані на дію, оскільки вони описують кроки або активну дію/прагнення, дозволяючи бізнес-аналітикам фіксувати взаємодію користувачів і реакції системи.
- І те, і інше орієнтоване на користувача:
І останнє, але не менш важливе: User Stories можуть здатися більш орієнтованими на користувача. Проте це не зовсім так — і в тому, і в іншому випадку увага приділяється користувачеві, просто в різний спосіб.
ПОРІВНЯЛЬНІ ПРИКЛАДИ
Нижче наведені спрощені приклади однієї і тієї ж вимоги “Бронювання квитків у кіно онлайн” з використанням Use Case і з використанням формату User Story.
Use Case формат
| Use Case Name: | Замовити квиток у кіно онлайн |
| Use Case ID: | UC_001 |
| Business Req Ref: | BR_005 |
| Primary Actor
(первинний актор): |
Покупець |
| Secondary Actor
(вторинний актор): |
Платіжна система |
| Pre-condition
(передумова): |
– |
| Trigger: | Клієнт заходить на платформу бронювання з метою купити квиток у кіно в даному місті |
| Use Case description
(опис): |
Цей Use Case складається з послідовності кроків, які клієнт (кінцевий користувач) виконує для пошуку фільмів, вибору фільму в певному місті та на певний час, а потім переходить до бронювання квитка. В кінці клієнт отримує підтвердження купівлі. |
| Basic flow (основні шляхи): | 1. Покупець заходить на платформу бронювання квитків у кіно і вводить назву міста
a. Система показує поточні та майбутні фільми з їхніми назвами, розкладом та інформацією про кінотеатр 2. Клієнт обирає певний фільм зі списку a. Система показує додаткову інформацію про обраний фільм 3. Покупець переходить до перевірки наявності вільних місць на обраний сеанс a. Система показує схему наявності місць на обраний сеанс для конкретного фільму/у конкретному кінотеатрі у вибраному місті 4. Покупець обирає місця та переходить до бронювання a. Система підтверджує вибір місць і переходить до остаточного бронювання 5. Клієнт вводить платіжну інформацію a. Система з’єднується з платіжною системою і підтверджує транзакцію b. Система надсилає клієнту інформацію про підтвердження бронювання на електронну пошту/зареєстрований телефон |
| Alternate flows
(альтернативні шляхи): |
1. Клієнт вводить неправильну платіжну інформацію
a. Система повідомляє користувача про це і перенаправляє його/її на повторне введення платіжних реквізитів |
| Exception flows
(виключні шляхи): |
|
| UI References
(референси користувацького інтерфейсу): |
UI_Mockup_Ref1
UI_Mockup_Ref2 UI_Mockup_Ref3 |
User Story формат
Назва User Story:
Як покупець, я хочу мати можливість швидко і легко купити квиток на фільм, який відповідає моїм уподобанням.
Опис User Story:
Ця функція передбачає, що користувач обирає конкретне місто, шукає назву фільму, обирає конкретний часовий проміжок, а потім проходить формальності оплати замовлення.
UI скетчі/UI референси:
UI_Mockup_Ref1
UI_Mockup_Ref2
UI_Mockup_Ref3
Acceptance Criteria:
- Користувач переходить на сторінку пошуку фільму
- Користувач обирає місто
- Користувач вводить назву фільму
- Система шукає відповідні фільми та відображає результати
- Користувач обирає конкретний час сеансу та переходить до бронювання
- Користувач вводить кількість гостей та місць
- Користувач вводить платіжну інформацію
- Система перевіряє платіжну інформацію та підтверджує бронювання
- Система надсилає користувачеві електронний лист/SMS з деталями підтвердження бронювання
Примітка:
- Ця User Story потенційно може бути розбита на більш детальні User Story рівня 2,3, і для кожної User Story рівня 2,3 (ми можемо назвати її атомарною User Story) ми можемо написати критерії прийнятності на цьому рівні.
- Зверніть увагу, що наведені вище Use Case та User Story призначені лише для демонстрації відмінностей та подібностей. Реальні вимоги будуть дуже унікальними для продукту/платформи, над якою ви працюєте. Ці вимоги також будуть містити набагато більше деталей.
- Ви можете знайти в інтернеті багато хороших прикладів Use Case та User Story діаграм. Особливо на сайтах інструментів для малювання, таких як Lucidchart.
Заключне слово
Підсумовуючи, існує багато відмінностей між Use Cases та User Stories, але разом з тим і подібностей. Обидві ці техніки можна навіть іноді поєднувати, щоб отримати найкращий результат. Хотілося б навести аналогію з моєї нещодавньої подорожі до Гімалаїв. Обидві ці техніки схожі на дві річки (Ганг і Ямуна), які протікають через Гімалайські хребти, а потім зливаються разом і стають річкою Ганг. Назва не має особливого значення. Після злиття ім’я залишається тої річки, яка є глибшою. Тобто, кожна річка все одно підкреслює спільне існування в природі!
До теми – User Story та Acceptance Criteria: пишемо чіткі та зрозумілі вимоги