Сучасні Agile-команди можуть описувати вимоги до програмного забезпечення за допомогою історії користувача та сценарію використання. User Story vs Use Case: яка різниця між цими підходами, чи можна обійтися без одного з вищенаведених артефактів?
Use Case
У програмній та системній інженерії фраза Use Case має два значення:
- Сценарій використання програмного забезпечення – часто використовується у множині, щоб вказати на ситуації, у яких частина програмного забезпечення може бути корисною.
- Потенційний сценарій, в якому система отримує зовнішній запит (наприклад, введення користувача) і відповідає на нього.
Use Case є структурованим, регламентованим і передбачає як мінімум двох учасників процесу: систему, яку ми плануємо розробляти, і користувача цієї системи.
Сценарії використання, як правило, об’ємні та ґрунтовні, адже описуючи їх, ви описуєте канву системи – те, як вона буде взаємодіяти з користувачем або іншою системою, реагувати на кожну дію.
Дуже зручно, що в Use Case можна:
- описати найрізноманітніший досвід користувача, зокрема альтернативний шлях;
- показати передумови для того, щоб цей сценарій використання був коректний;
- відобразити результати Use Case;
- вказати помилки, або exceptional use cases – все те, що заважає досягненню мети сценарію використання.
Основна задача при написанні Use Case – надати максимально повну інформацію про сценарій.
Use Case обов’язково має містити в собі таку інформацію:
- Хто використовує систему?
- Що користувач хоче зробити?
- Яка мета користувача?
- Які кроки виконує користувач для виконання конкретної задачі?
- Як система має реагувати на конкретну дію?
В Use Case не потрібно писати:
- Особливості реалізації, тобто технічні деталі.
- Відомості про інтерфейси користувача або екрани.
Зверніть увагу: якщо від вас вимагають будь-якої прив’язки до графічних елементів, це вже не класичний Use Case.
Бізнес і користувач можуть мати різні цілі. Задля їх задоволення ми маємо Business Case та Use Case. У Business Case відбувається фокусування на цінностях, перевагах та припущеннях, які ми маємо перевірити за допомогою Use Cases. У випадку зі сценаріями використання ми говоримо про перевірену інформацію, вимоги, процес – все те, що передбачає вимірюваний досяжний результат.
Як писати класичний Use Case
Перш за все, кожен Use Case повинен мати унікальний номер. Мають бути:
- основні актори;
- вторинні (або допоміжні) актори;
- передумови;
- результати виконання;
- основний сценарій, тобто основні дії, які потрібно виконати;
- розгалуження: додаткові сценарії використання, доповнення або те, що виключається зі стандартного сценарію успіху;
- спеціальні вимоги – те, що має бути додатково доступне або зроблене, щоб цей Use Case стався;
- відкриті питання – те, що дозволяє сигналізувати, що ми не до кінця можемо щось реалізувати або ми вже зустрічаємось з проблемами.
Бізнес-аналітик повинен розуміти, навіщо він пише сценарій використання, і робити це якісно, адже все написане буде реалізовано командою. Перед написанням Use Case потрібно уточнити у команди та клієнта, чи влаштовує їх такий формат роботи, чи їм потрібно щось інше.
Переваги сценаріїв використання
- Це хороший спосіб комунікації між членами команди. Ми чітко формулюємо вимоги та формуємо площину для дискусії.
- UC заохочують спільну згоду щодо системних вимог.
- Вони надають можливість не відходячи від основного сценарію прописати альтернативи та виключення. Тобто ми одразу закриваємо всю специфіку реалізації.
- Use Cases дозволяють подивитися, що знаходиться за їх межами.
- Сценарії використання допомагають в трансформації ручних процесів в автоматичні.
Останній пункт довго викликав багато дискусій з приводу того, як може написання Use Cases допомогти автоматизації тестування. Насправді відповідь на це запитання доволі проста: одними зі споживачів таких сценаріїв є QA-інженери, а саме автоматизатори. Причина в тому, що існують певні правила трансформації ручних Use Cases в автоматичний сценарій виконання. Це означає значну економію часу і, як наслідок, бюджету.
Вигоди використання Use Cases для розробників:
- Команда розуміє бізнес-процеси.
- Розробники розуміють поведінкові шаблони та контекст, щоб надалі створити на основі Use Cases вимоги нижчого рівня.
- Відбувається пріоритезація робіт залежно від цінності, актуальності та мети виконання.
Переваги для тестувальника:
- Use Cases допомагають виявити невідповідності між вимогами й готовим програмним продуктом.
- UC доводять, що програмне забезпечення працює коректно.
Недоліки Use Case
- Сценарії використання не є об’єктно орієнтованими. Вони орієнтовані на користувача. Для суто технічних і глибоко технологічних проєктів писати їх недоцільно – ви тільки марно витратите час та кошти.
- Відсутні правила та формальні вимоги до того, як використовувати Use Cases, хто може їх розширювати, хто є акторами. Це доволі гнучка структура.
- Не всі системи мають акторів, тобто не всі системи мають можливість ідентифікувати користувача як такого. У результаті ми отримуємо конфлікт, адже нам необхідно показати взаємодію двох систем за допомогою підходу, який орієнтований на користувача.
- Use Cases засновані на підході Waterfall – вони виникли саме в цій методиці розробки.
Узагальнюючи, можна сказати, що сценарії використання до цього часу не втратили своєї актуальності лише завдяки тому, що переваг в них значно більше, ніж недоліків.
User Story
У розробці програмного забезпечення та управлінні продуктами історія користувача – це неформальний опис функцій програмної системи природною мовою. Вони написані з точки зору кінцевого користувача чи користувача системи та можуть бути записані на індексних картках, листівках або в цифровому вигляді в програмному забезпеченні для керування проєктами. Залежно від проєкту, історії користувачів можуть бути написані різними зацікавленими сторонами: замовником, користувачем, менеджером або командою розробників.
Зазвичай у підході Agile User Story – це менша частина епіку. Вони містять в собі три функції:
- роль (<role>);
- мета (<goal>);
- цінність (<benefit>).
У класичному вигляді історія користувача не має передумов та результатів. Ми пишемо про те, як має працювати система для того, щоб задовольнити потреби користувача. Розглянемо приклад такої User Story:
As a <role>
I want <goal>
so that <benefit>
Переваги використання User Story
- Чітка гранулярна артикуляція – описується конкретна вимога користувача. Ми говоримо про те, що конкретний користувач хоче саме в цей момент і для чого.
- Краща взаємодія всіх учасників процесу. Адже ми говоримо, з одного боку, з позиції користувача, з другого – з позиції бізнесу, а з третього – мова йде про потенційну реалізацію.
- Можливість зменшувати ризики проєкту в контексті:
- нечіткості визначення, адже є обмеження критеріями приймання (acceptance criteria);
- гнучкості, адже переробити одну маленьку User Story значно простіше, ніж переписати великий Use Case.
- User Story – це вибір Agile-команд. Це максимальна гнучкість і повноцінна реакція на те, що ми отримаємо в результаті.
Недоліки User Story
- Слабкий фокус на нефункціональних вимогах, тому з ними досить важко працювати.
- Складність реалізації у великих проєктах. Це відбувається тому, що складні проєкти починають вимагати ієрархії й меж того, що ми маємо реалізувати.
- Ризик не закрити вимогу при використанні неповної, недоконаної історії користувача.
User Story vs Use Case: що використовувати?
Багато сучасних команд надають перевагу історіям користувача, тоді як сценарії використання застосовують переважно в контексті бізнес-кейсів, коли потрібно описати великі масштаби та задати межі системи.
User Story концентрується на результатах та перевагах того, що вона описує, а Use Case – на тому, як буде функціонувати система, як вона буде взаємодіяти з кінцевим користувачем. Рішення, що саме використовувати, залишається за вами й залежить від особливостей конкретного проєкту та продукту.
Більше про User Story чи Use Casе ви можете дізнатися на курсі Business Analysis Intensive Online, а відпрацювати на практиці побудову Use Case ви можете на курсі UML: Unified Modeling Language.