User Story і Use Case: чим відрізняються і що писати

На грумінгу команда читає історію: «Як покупець, я хочу оплатити замовлення карткою, щоб отримати товар». Усі кивають, оцінка — п’ять балів, історія йде в спринт. Через два тижні тестувальник питає, що робити, якщо банк списав гроші, а магазин відповіді не дочекався. Відповіді немає ні в історії, ні в кого в голові.

User story і use case відповідають на різні питання. Історія говорить, кому й навіщо потрібна можливість, і залишається короткою: одна фраза плюс критерії приймання, які роблять її перевірюваною. Сценарій описує, як система поводиться крок за кроком, включно з усіма гілками, де щось іде не за планом. Вибір між ними вирішує не методологія команди, а кількість розвилок у задачі: чим їх більше і чим дорожча помилка в гілці, тим потрібніший сценарій.

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

Два записи — два різних питання

Формат історії «Як <роль>, я хочу <можливість>, щоб <цінність>» придумала у 2001 році команда лондонської компанії Connextra. Причина була практична: історії писали продажі та маркетинг, записували потрібну функцію, а розробникам потім доводилося шукати автора, щоб зрозуміти, для кого вона і навіщо. Шаблон змусив записувати «хто» і «навіщо» одразу.

Історія навмисно неповна. Вона — привід для розмови, а не специфікація. Перевірюваною її роблять критерії приймання: умови, за якими команда та замовник домовляються, що історію зроблено. Без них історія залишається побажанням.

Use case старший. Івар Якобсон представив його на конференції OOPSLA у 1987 році, а широко він поширився після книги 1992 року «Object-Oriented Software Engineering: A Use Case Driven Approach». Сценарій описує актора, його мету та кроки взаємодії із системою. Алістер Коберн у книзі «Writing Effective Use Cases» розділив його на основний успішний сценарій і розширення — гілки, де щось пішло інакше, — і радив перебирати ці гілки вичерпно.

Обидва записи можуть містити вимоги різного рівня — від бізнес-мети до поведінки екрана; як їх розрізняти, розібрано в статті чим бізнес-вимоги відрізняються від функціональних. І ще одна часта плутанина: діаграма варіантів використання в UML — не те саме, що текстовий use case. На діаграмі видно акторів і цілі, але не кроки; де вона стоїть серед інших нотацій, — у статті BPMN і UML: чим відрізняються.

А як сформулювати одну функціональну вимогу, щоб її зрозуміли однаково, — у статті функціональні вимоги: як писати, приклад і шаблон.

Одне завдання: оплата замовлення карткою

Інтернет-магазин, покупець оформив замовлення й платить карткою через зовнішній платіжний шлюз. Завдання виглядає простим, але розвилок у ньому багато. Картку можуть відхилити. Банк може запросити підтвердження, а покупець — його не пройти. Шлюз може не відповісти взагалі. А може відповісти пізніше, ніж магазин перестав чекати, — і тоді гроші списані, а замовлення висить неоплаченим.

Запишемо це завдання двічі.

Запис перший: історія з критеріями приймання

Історія. Як покупець, я хочу оплатити замовлення карткою, щоб отримати товар і не оформлювати замовлення заново, якщо оплата не пройшла з першого разу.

Друга половина фрази з’явилася не одразу. Її дало питання «навіщо»: покупець хоче не просто заплатити, а не втратити зібраний кошик. Це змінює поведінку системи в разі відмови.

Критерії приймання:

1. Дано: замовлення оформлено, картка дійсна. Коли покупець підтверджує оплату, тоді замовлення отримує статус «Оплачено», а покупець бачить номер замовлення.
2. Дано: банк відхилив картку. Коли покупець повертається до замовлення, тоді кошик і дані доставки збережено, і можна повторити оплату іншою карткою.
3. Дано: банк запросив підтвердження. Коли покупець його не пройшов, тоді гроші не списані, замовлення залишається неоплаченим і доступним для повторної оплати.

Історія коротка, її легко оцінити й обговорити з власником продукту. Цінність — не втратити замовлення — видно в першому рядку.

Запис другий: сценарій з альтернативними потоками

Сценарій: Оплатити замовлення карткою. Актор: покупець. Мета: замовлення оплачено.

Основний потік:

1. Покупець вибирає оплату карткою.
2. Система передає суму й номер замовлення платіжному шлюзу.
3. Покупець вводить дані картки на сторінці шлюзу.
4. Шлюз підтверджує оплату.
5. Система змінює статус замовлення на «Оплачено» і показує покупцеві номер замовлення.

Альтернативні потоки:

• 4а. Картку відхилено. Система показує причину відмови, замовлення залишається неоплаченим, покупець може вибрати іншу картку.
• 4б. Підтвердження не пройдено. Система не змінює статус замовлення й пропонує повторити оплату.
• 4в. Шлюз не відповів за відведений час. Система не скасовує замовлення, а позначає його «Очікує підтвердження оплати» й повторно запитує в шлюзу статус платежу.
• 4г. Шлюз підтвердив оплату після тайм-ауту. Система за повідомленням шлюзу переводить замовлення в «Оплачено». Якщо замовлення на цей момент уже скасовано — система запускає повернення грошей.
• 4д. Повідомлення про оплату надійшло двічі. Система обробляє його один раз і не створює другий платіж.

Що втратив кожен запис

Історія втратила гілки 4в, 4г і 4д. Це саме ті, де гроші й статус замовлення розходяться: покупець заплатив, а магазин цього не знає. Їх не видно з фрази «хочу оплатити замовлення карткою», і вони не спадають на думку на грумінгу. Спливають вони на тестуванні або в проді — у вигляді листа від покупця, у якого списали гроші двічі або не віддали замовлення.

Критерії приймання можна дописати, і хороша команда їх допише. Але формат історії не змушує шукати гілки. Він змушує відповісти «навіщо», а перебір відмов залишає на розсуд того, хто пише.

Сценарій втратив «навіщо». У ньому є кроки й відмови, але немає рядка, з якого випливає, що кошик потрібно зберегти. Без питання про цінність у гілці 4а легко написати «замовлення скасовується» — формально коректно, а покупець збирає кошик заново й іде. Сценарій відповідає, як система поводиться, але не перевіряє, чи потрібна користувачеві саме така поведінка.

Історія захищає від того, щоб побудувати не те. Сценарій — від того, щоб побудувати те, але з дірою в гілці, де зникають гроші.

Що писати у своєму завданні

Почніть із підрахунку розвилок. Один шлях, дві-три очевидні перевірки — історія з критеріями приймання закриває завдання повністю, сценарій буде бюрократією. Багато гілок, і кожна веде до різного стану грошей, даних або зобов’язань перед клієнтом — потрібен сценарій хоча б для цієї частини.

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

Команда працює за Scrum — це не заборона на сценарії. Команда пише ТЗ — не заборона на історії. Форму запису обирають під завдання, а не під процес.

Як це звучить на співбесіді

У нашому банку питань із реальних співбесід ця тема трапляється 26 разів, і 16 із цих питань розмічені як junior. Це більше половини: різницю між історією та сценарієм запитують на вході в професію.

Слабка відповідь — переказ визначень: «user story — коротка, з Agile, use case — довгий і докладний». Правильно, але це переказ підручника, а не розуміння. Сильна відповідь показує, що ви бачите, що втрачає кожен запис. Історія тримає цінність, але пропускає гілки. Сценарій перебирає гілки, але не питає «навіщо». Далі — як ви обираєте: за кількістю розвилок і ціною помилки в них. Якщо є приклад із практики, де гілка спливла пізно, — це найкращий аргумент.