USE CASE для початківців

Отже, кілька слів, що таке Use Case і що таке User Story, бо хтось, можливо, забув чи не знає. Use Case описує взаємодію користувача із системою, перелік сценаріїв, певним чином згрупованих. Якщо подивитися на цю схему, то ми маємо «пряму» лінію — так званий Primary Scenario, який веде нас від поточного стану до бажаного, і є різні альтернативні сценарії. Деякі з них ведуть у нікуди — це «exceptional flows», а деякі теж доводять користувача до результату, але іншим шляхом.

Учора колеги з Райффайзен Банку Аваль розповідали, що є типовий шаблон Use Case: можемо його не використовувати, вигадувати власні правила, але принцип залишається. Ключові компоненти: Actor, що він хоче і навіщо йому це потрібно, яку цінність він отримає. Тут акцент на тому, яку користь отримає клієнт завдяки певному функціоналу чи певним характеристикам системи.

Якщо ви читали книгу Коберна, то знаєте приблизно ось такий шаблон. Це шаблон Use Case, де є Actor, для чого це йому, основний сценарій, альтернативні сценарії, результати, розділ «додаткові вимоги». Зараз не зупинятимемося детально; суть та, що всі ці частини розкладені доволі структуровано й можуть мати кілька форм форматів опису.

Тепер глянемо на User Story. Коли ми говоримо «юзер сторі», перше, що спадає на думку, — це різнокольорові стікери на дошці з мінімумом тексту. Мовляв, «усе обговоримо на словах». Хтось каже: «Супер, але ж тоді незрозуміло, що саме потрібно робити?» Проте насправді в User Story теж є свій набір атрибутів. По-перше, це назва, яка дає зрозуміти, про що йдеться. Найголовніше — формулювання «Як <роль> я хочу <чогось>, щоб <отримати цінність>». Багато хто вважає, що на цьому юзер сторі закінчується, бо воно вже говорить про цінність. Але тут бракує деталей — де вона починається й де закінчується?

Щоби дати більше контексту, ми додаємо «Acceptance Criteria» (критерії приймання), які деталізують історію й уточнюють, що саме треба зробити, щоб історія з погляду бізнесу вважалася завершеною. Популярний формат — Gherkin або Behavior-Driven Development, із трьома кроками: Given (передумова), When (тригер, дія користувача чи системи), Then (результат). Умовно кажучи: «Була мавпочка з бананом і заплющеними очима, потім вона їх розплющила (крок When), потім з’їла банан (крок Then)».

Критерії приймання можуть виглядати так: «Незареєстрований користувач заходить на сайт, коли він ініціює реєстрацію за номером телефону — система показує форму для заповнення, де той має ввести певні дані. Якщо все введено коректно, система зберігає запис і надсилає листа на пошту» і т. ін. У кожному з розділів (Given–When–Then) може бути кілька умов.

Отже, маємо короткий екскурс у Use Case і User Story. Тепер — у чому схожість і відмінності.

Схожість

1. І там, і там зазначається роль (Role/Actor). У Use Case це той, хто буде безпосереднім користувачем системи. У User Story це може бути і користувач, і хтось інший, хто отримує цінність.

2. І там, і там ми описуємо мету (Goal). У Use Case є розділ «Purpose» чи «Goal», у User Story — «щоб отримати цінність».

3. Сценарії кроків. У Use Case є «основний» і «альтернативні» сценарії, у User Story — кроки (Given–When–Then) у межах критеріїв приймання. Якщо це довгий ланцюжок у Use Case, то в User Story ми зазвичай розглядаємо один крок за критерій приймання, а якщо кроків більше, то додаємо нові критерії. У підсумку, якщо всі критерії «склеїти», вийде схожий наскрізний сценарій.

4. Тригер у Use Case (що саме запускає сценарій) відповідає секції Given–When, і результат (Then) у User Story.

Отже, ключові елементи однакові, просто акценти різні.

Відмінності

1. У User Story ми від самого початку концентруємося на тому, яку бізнес-цінність має отримати замовник чи користувач. У Use Case ми більшою мірою зосереджуємося на поведінці системи, тобто на сценарії взаємодії.

2. Use Case завжди описує всі можливі варіанти розвитку подій, включно з альтернативними й винятковими сценаріями. User Story за замовчуванням передбачає, що щось «і так зрозуміло» і можна не документувати зайвого. Якщо команда зріла, вона сама знає, що треба. Якщо ж ні, тоді доводиться все ретельно прописувати — але це вже від команди залежить.

3. User Story зазвичай легше зрозуміти бізнес-стейкхолдерам, адже вона «про їхню біль і цінність». Use Case складніше, бо він детально описує різні варіанти і може мати об’єктно-орієнтовані моделі, наслідування тощо.

4. Управління змінами. Навіть у гнучких методологіях зміни — це норма. Проте змін буває два типи: або це додатковий функціонал, або треба змінити вже наявний.

   • У User Story ми просто заводимо нову історію: «Поміняти перевірку з попередження на жорстку», не чіпаючи стару.

   • У Use Case доводиться змінювати вже наявний опис одного сценарію, додавати альтернативи тощо. Якщо змін кілька, документ починає «розростатися» і ускладнюється відстеження версій та пріоритетів.

Іще один важливий момент — для чого взагалі пишемо вимоги. Зазвичай, щоб:

1. Поставити завдання розробникам. Із цим і User Story, і Use Case дають собі раду.

2. Визначити тестові сценарії. Тут User Story виграє завдяки критеріям приймання, бо тестувальник одразу може перевести їх у тест-кейси. Якщо на вході маємо Use Case, доведеться «нарізати» його на окремі сценарії для тестування.

3. Швидко описати зміни до функціоналу. Знову ж таки, User Story тут зручніше: «Ось блок, який треба замінити».

4. Забезпечити підтримку застосунку — коли за пів року чи рік прийде дефект/запит, і треба буде зрозуміти, як воно «м мало працювати». Для цього Use Case з його «повною картиною» системи підходить краще.

Коли краще підходять User Stories:

1. Потрібно швидко завантажити команду роботою, а ресурсів бракує (наприклад, немає часу на докладний аналіз).

2. Система вже працює, документації немає чи незрозуміло, наскільки вона актуальна, а час дуже обмежений.

3. Потрібно запустити нову підсистему, знову ж таки, без часу на великий аналіз, і ми можемо обійтися юзер сторі.

Мінуси User Stories:

• Немає цілісної картини, команда втрачає розуміння, «куди ми глобально рухаємося». Є інструменти на кшталт Story Mapping (епіки, теми), які частково вирішують це, але все одно, якщо зануритися саме в одну історію — великої картини не видно.

• Стає складніше керувати великою кількістю невеликих артефактів (багато історій, що залежать одна від одної).

• Із часом виникає чимало змін, і є ризик заплутатися у взаємозалежностях між історіями.

Плюси User Stories:

• Бізнесу простіше ухвалити кожну невелику історію, легше погодити специфікацію, ніж величезний документ.

• Змінами керувати простіше, бо ми або пишемо нову історію, або змінюємо ту, що прямо зараз у розробці.

• Чудово підходить для інкрементної розробки: ми беремо стільки історій, скільки вміщається у спринт, і не ламаємо собі голову, як розділити великий Use Case.

Коли краще підходять Use Cases:

1. Коли потрібно мати повний опис усієї системи. (Я шість років працював у компанії, яка робила системи електронного уряду. Там було правило: «Не задокументовано — не реалізується»). Із цим усе зрозуміло, легше підтримувати таку систему, якщо є вичерпний опис.

2. Якщо систему підтримують довго і зміни можуть бути «на зміни»: тобто щось одне змінили, потім іще щось, і треба швидко зрозуміти, який актуальний результат. Якщо ж це User Stories — потрібно відшукати всі історії, що стосуються цього функціоналу, і «склеїти» їх, щоби зрозуміти поточний стан. У Use Case ми дивимося в один документ.

3. Коли на початку проєкту є достатньо бізнес-аналітичних ресурсів, щоб одразу описати Use Cases, і замовник прагне все формалізувати (наприклад, фіксована ціна, фіксований час, проєкт для держструктур). Також коли чітко окреслені межі системи (діаграма або перелік Use Cases).

Мінуси Use Cases:

• Складно керувати змінами. Якщо з кожною порцією змін доводиться оновлювати один «великий документ», це може бути важко.

• Потенційно великі витрати на підтримку актуальності документа.

• Якщо замовнику не дуже потрібна детальна документація, це може виявитися надмірно витратним.

Плюси Use Cases:

• Якщо розробник чи тестувальник приходить із питанням «Як у нас працює цей модуль?», ви даєте їм документ. Усе є в одному місці, якщо людина готова читати.

• Легше робити аналіз впливу змін, особливо якщо Use Case має «простежування» (traceability) і пов’язаний із бізнес-правилами та нефункціональними вимогами.

• Легше керувати межами проєкту, коли у вас детально описані всі сценарії.

Кожен зараз може подумати: «А в нас не так». Це нормально; усе залежить від контексту. Я описую свої кейси, з якими стикався. У вас можуть бути відмінності.

Підсумовуючи:

• User Story чудові для швидкого керування беклогом, постановки завдань і планування.

• Use Case — добра база для розробки, коли треба знати повну картину та розуміти, що має вийти в результаті.

Чи можна ці дві техніки поєднувати? Так, можна. Я мав декілька проєктів, де ми це робили.

Варіант 1. User Story — для постановки завдань розробникам. Коли все реалізоване вже трохи «устаканилося», ми «вливаємо» підсумки реалізації в Confluence у вигляді Use Cases або просто великого системного опису. Перевага — ми отримуємо і гнучкість юзер сторі, і цілісну картину з Use Case. Недолік — «подвійна робота», бо ми двічі описуємо те саме.

Варіант 2. User Story — для постановки задач, а Use Case ми використовуємо тільки на високому рівні (на рівні епіків), аби показати наскрізні сценарії. Тобто Use Case тут фактично забезпечує «кістяк», на який нанизуються історії користувача. Недолік — це вже не зовсім «класичні» Use Cases, бо ми приділяємо увагу лише основному сценарію, мінімізуючи опис решти.

Є і проміжний варіант, так званий «Use Case 2.0» від Івара Якобсона. Його ідея в тому, що Use Case з’являється на початку й описує всі можливі варіанти, але коли робимо інкрементальну чи гнучку розробку, «розрізаємо» ці сценарії на «слайси» — фактично User Stories — і реалізуємо поступово. Це допомагає мати повну картину і водночас планувати ітерації. Але буває ризик «передокументувати» зайве: ви можете описати частину сценаріїв, до яких ніколи так і не дійдете, і ці вкладення часу підуть у нікуди.

Отже, якщо узагальнити:

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

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

Дякую за увагу! Готовий відповісти на ваші запитання.

(Далі в оригіналі йшли питання-відповіді й розмова із залом про трасування, прототипи, прийомки, зміну вимог «на льоту» тощо. Нижче — скорочений зміст цих Q&A.)

Питання: Як ви ведете трасування, якщо є Use Cases і до них прив’язані User Stories? Відповідь: Трасування робили або у Jira, або робили посилання з документу (Use Case) на ті чи інші історії, які його реалізують. Іноді на рівні епіка, якщо йдеться про великий Use Case.

Питання: Чи варто взагалі поєднувати ці дві техніки? Відповідь: Це залежить від контексту. Якщо треба велика формальна документація й замовник готовий платити, то Use Cases. Якщо проєкт короткий (3–6 місяців) і після релізу продукт «віддаємо» замовнику, можна обмежитися User Stories. Якщо треба й швидкість, і системність, можна спробувати комбінацію чи Use Case 2.0.

Питання про бізнес-правила та валідацію даних: Часто бізнес-правила виносять в окрему таблицю (Business Rules), а в критеріях приймання просто посилаються на них: «Система перевіряє за таблицею правил. Якщо дані відповідають правилам, зберігає запис».

Питання про Gherkin і автоматизоване тестування: Зазвичай аналітики пишуть критерії приймання у форматі Given–When–Then, але це не обов’язково прямо використовується для автотестів — можуть бути й інші підходи.

Питання про зміни, коли історія вже «в спринті»: Якщо зміни великі, ми створюємо нову історію. Якщо це дрібне коригування, іноді просто оновлюємо поточну, якщо команда до цього відкрита.

Питання про non-functional вимоги (продуктивність, відновлення після збоїв тощо): Це зазвичай іде в окремий розділ чи список нефункціональних вимог. Use Cases і User Stories описують поведінку, а нефункціональні вимоги — це інша площина специфікації, хоч і прив’язана до сценаріїв.

Питання про розміри команд і масштаб проєктів: На великих проєктах (50–150 людей) може бути 15 аналітиків і 14 підсистем, по 15–20 Use Cases у кожній, і це розтягується на кілька років. На менших чи короткотривалих проєктах може вистачити й коротких описів.