Я люблю варіанти використання. Я сказав це і не шкодую.
Варіанти використання (use cases) в останні роки стали менш популярними, оскільки їх переважно замінюють історіями користувача в Agile-проектах. Проте ці два підходи можуть співіснувати та доповнювати один одного.
Переваги варіантів використання
Варіанти використання пропонують низку переваг, яких бракує історіям користувача. У цій статті описуються деякі з численних переваг, які забезпечують варіанти використання, та чому кожен бізнес-аналітик (BA), власник продукту (PO) та команда розробників програмного забезпечення повинні включити їх у свій інструментарій.
Що таке варіант використання?
Це визначення належить винахіднику варіантів використання, Івару Якобсону: «Варіант використання описує всі способи використання системи для досягнення конкретної мети певним користувачем». Це стисле визначення включає три важливі аспекти:
1.Фокусування на цілях, які має на увазі користувач при використанні продукту.
2.Визнання того, що є декілька класів користувачів, кожен із яких може мати різні варіанти використання, які бізнес-аналітик або власник продукту повинні виявити, зрозуміти та врахувати.
3.Вказівка на те, що можуть бути декілька пов’язаних шляхів (сценаріїв), якими користувач може досягти бажаного результату.
Варіанти використання — це потужний інструмент для виявлення вимог, який дозволяє дослідити цінні для користувачів транзакції, які повинні бути забезпечені рішенням. Кожного разу, коли користувач взаємодіє з продуктом, у нього є намір — щось, що він хоче досягти. Коли учасник виявлення каже: «Я хочу [зробити щось]» або «Мені потрібно [зробити щось]», це [зробити щось], швидше за все, є варіантом використання. Назва варіанту використання починається з дієслова та коротко формулює мету користувача для однієї сесії взаємодії: Зареєструватися на курс, Сплатити рахунок кредитної картки, Скасувати підписку.
Різні автори описують варіанти використання по-різному. Є деякі варіації в термінології та способах їх застосування. І це нормально. Головне — це мислення та процес, які супроводжують роботу з варіантами використання, а не конкретний підхід, який команда чи аналітик використовує.
Документування варіантів використання
Опис варіанту використання найкраще представити у формі структурованого тексту. Уніфікована мова моделювання (UML) включає діаграму варіантів використання як спосіб візуалізації зв’язків між різними типами користувачів (часто називають акторами) та їх відповідними варіантами використання. Часто буває корисно доповнювати текстові специфікації варіантів використання візуальними моделями, такими як діаграма послідовностей, діаграма активностей або блок-схема. Діаграми особливо корисні, коли продукт, що розробляється, є складним, ризикованим або життєво важливим, наприклад, у фармацевтичній, оборонній або телекомунікаційній галузях. Але в основі варіант використання завжди описується текстом.
Шаблон для опису варіантів використання надає структуровану форму, яка допомагає бізнес-аналітику записувати як детальний, так і простий опис завдання користувача відповідно до вимог. Якщо вам не потрібна вся інформація з шаблону для повного розуміння конкретного варіанту використання, заповнюйте лише ті розділи, які додають цінність. Рівень деталізації опису варіанту використання може змінюватися від простого до дуже детального («повністю описаного»), залежно від потреби досягти основної мети: чіткого та ефективного спілкування.
Основною частиною варіанту використання є діалог або взаємодія між користувачем і системою (а можливо, й іншими елементами), що веде до досягнення заявленої мети користувача. Цей сценарій успіху має багато назв, найчастіше «основний потік». Пов’язані сценарії, які представляють інші шляхи до досягнення мети, є альтернативними потоками. Винятки — це умови чи події, які можуть завадити досягненню мети користувача.
Шаблон для опису варіанту використання включає місця для інших ключових частин інформації, зокрема передумов, постумов, припущень і відповідних бізнес-правил. Шаблон сприяє дослідженню, нагадуючи вам, яка інформація може бути важливою, і забезпечує постійне місце для учасників проєкту, де вони можуть зберігати та знаходити її.
Центроване на використанні виявлення вимог
Найважливіший урок, який я засвоїв у розробці програмного забезпечення, полягає в тому, щоб орієнтувати на виявлення вимог до використання продукту, а не на сам продукт і його функції. Варіанти використання сприяють акценту на використанні. Спочатку зрозуміймо, що людям потрібно робити із рішенням. З цих знань бізнес-аналітик може визначити, яку функціональність потрібно реалізувати. Питання до користувачів на кшталт «Що вам потрібно зробити з продуктом?» надають більше інформації, ніж запитання «Які ваші вимоги?» або «Які функції має містити продукт?» або (жах!) «Чого ви хочете?».
Орієнтація на сценарії використання збільшує ймовірність виявлення функціональності, яка дозволить користувачам виконати свої завдання, не пропустивши важливу функціональність. Концентрація на сценаріях використання робить менш імовірним, що команда витрачатиме час на розробку функцій, які здавалися хорошою ідеєю, але залишаться невикористаними, оскільки не сприяють виконанню конкретних завдань користувачів.
Люди можуть рецензувати та розуміти варіанти використання, оскільки вони описують сесії взаємодії, які відповідають намірам і діям користувачів. Користувачі можуть знаходити прогалини: «Я не бачу, як я можу зробити це конкретне завдання» або «Як система має обробляти цю менш поширену ситуацію?». Читачі можуть ідентифікувати виняткові умови для конкретних сценаріїв: «Як система має реагувати, якщо це поле відсутнє або є недійсним?» Якщо ви не виявите прогалини у функціональності до реалізації або не передбачите обробку помилкових умов, будьте готові до доопрацювань, коли тестувальник знайде ці недоліки або незадоволені користувачі зіткнуться з такими ситуаціями.
Надання контексту
Люди керують складністю за допомогою організації, ієрархії та абстракції. Маса неструктурованих історій користувача або функціональних вимог позбавлена всіх трьох. Без структури важко для зацікавлених сторін побачити контекст, у якому кожен набір потреб користувачів і відповідна функціональність відповідають загальній меті. Такий брак контексту може призвести до того, що щось буде пропущено або включено щось зайве. Це також ускладнює розробку міцного, добре спроектованого рішення шляхом поступового нарощування завершених частин роботи.
На рис. 1 показано, що варіанти використання знаходяться на вищому рівні абстракції, ніж окремі історії користувача чи функціональні вимоги. Така абстракція дозволяє краще організувати інформацію, ніж коли є просто набір окремих елементів без очевидних зв’язків. Варіант використання може об’єднувати кілька пов’язаних сценаріїв або історій — як тих, що ведуть до успішного результату, так і винятків, які можуть цього не забезпечити, — щоб показати їх зв’язки та зробити їх легшими для управління як єдине ціле.
Сегментація, пріоритезація та історії користувача
Варіанти використання не є самоціллю. Вони є інструментом для розуміння цілей користувачів, що веде до розуміння необхідної функціональності рішення, що у свою чергу дозволяє команді проєктувати, розробляти та перевіряти це рішення. Мета полягає у тому, щоб ідентифікувати ті сценарії, які швидко принесуть найбільшу цінність зацікавленим сторонам.
Якщо ви визначите основний потік подій варіанту використання та винятки, разом із можливими альтернативними потоками та їхніми винятками, ви зможете розділити варіант використання на частини, які команда може реалізовувати незалежно протягом кількох ітерацій розробки відповідно до їхнього пріоритету. Якщо ваша команда звикла розподіляти історії користувача по ітераціях, розбитий на частини варіант використання може слугувати пріоритетним набором пов’язаних історій.
Моделювання сценаріїв варіантів використання за допомогою, наприклад, діаграм активностей, надає ще один спосіб розділення варіантів використання на історії для їхньої реалізації у відповідний момент.
Варіанти використання та тестування
Коли я вперше почав використовувати варіанти використання як бізнес-аналітик, я одразу побачив, як вони природно ведуть до написання тестів. Мені було легко уявити тести, щоб перевірити, чи кожен сценарій успіху працює так, як я очікував, і чи ми відповідно обробляємо кожен визначений виняток. Раннє мислення про тести дозволяє швидше написати критерії прийняття, які сприяють створенню надійного рішення. Структура «Given–When–Then», яка часто використовується для написання критеріїв прийняття на Agile-проєктах, добре підходить для визначення тестів на основі варіантів використання.
Існує ще одна перевага створення тестів на основі варіантів використання. Я виявив, що корисно, коли бізнес-аналітик пише функціональні вимоги з варіанту використання, а тестувальник одночасно пише тестові кейси. Порівняння результатів цих двох взаємодоповнюючих процесів мислення дозволяє виявити помилки: відсутні, помилкові чи непотрібні вимоги; відсутні, неправильні або зайві тести; відсутню інформацію; неоднозначні вимоги; і суперечливі припущення. Дешевше й менш болісно виявити такі проблеми на ранніх етапах, ніж на пізніх.
Корисні, але недостатні
Інформації, наявної у варіанті використання, не завжди достатньо для повної реалізації правильного рішення для певної частини продукту. Наприклад, специфікація варіанту використання не вказує, що система має робити, якщо якісь передумови не виконані. Хтось повинен це визначити. Хтось має визначити всі аспекти функціональності, які розробники повинні реалізувати, щоб дозволити користувачеві повністю виконати взаємодію, включаючи обробку всіх винятків. Бізнес-правила та атрибути якості, пов’язані з варіантом використання, часто ведуть до додаткової функціональності.
Практичний досвід
У мене є деякі емпіричні докази того, що варіанти використання є ефективним інструментом виявлення вимог. Я викладав дводенний курс із розробки програмного забезпечення понад 180 разів. У межах цього курсу ми проводимо одногодинну практичну сесію з виявлення вимог. Я розділяю студентів на чотири команди та пропоную їм виконати завдання на основі проєкту. Вони мають визначити кілька класів користувачів для проєкту, кілька варіантів використання для одного з класів користувачів, а також розглянути один із цих варіантів використання та написати кілька функціональних вимог на його основі. Я спостерігав за виконанням цієї вправи близько 700 команд.
У кожному курсі зазвичай повторюється одна й та сама схема. Одна команда швидко розуміє концепцію варіантів використання та робить вражаючий прогрес за одну годину. Дві команди трохи борються з концепцією, але з невеликим наставництвом стають на правильний шлях і досягають гарних результатів. Четверта команда просто не засвоює концепцію варіантів використання. Їхній аркуш із фліпчарту заповнений стікерами, які містять випадкові шматки інформації: функціональні вимоги, функції, історії, атрибути якості, бізнес-правила, об’єкти даних, обмеження та завдання користувачів. Потім ця команда просто дивиться на свої стікери, не знаючи, що робити далі.
Коли я запитую цю четверту команду, як вони розпочали вправу з виявлення вимог, фасилітатор завжди відповідає: «Я запитав у групи, які у них вимоги, і записав те, що вони сказали». Команди, які розуміють суть варіантів використання, набагато швидше просуваються в аналізі проблеми. Це підтверджується і моїм особистим досвідом у реальних проєктах.
Чому б не використовувати варіанти використання?
Останнім часом кілька розробників програмного забезпечення запитали мене: «Чи можна використовувати варіанти використання в Agile-проєктах?» Зрештою, варіанти використання не є чітко визначеною практикою в Agile-методологіях.
Моя відповідь: «Так, звісно, можна!» Чому це взагалі є питанням для обговорення? Практики програмного забезпечення мають професійну відповідальність використовувати найкращі доступні техніки для виконання своєї роботи. Варіанти використання є перевіреним і потужним інструментом для ефективної розробки вимог. Якщо вони підходять для вашого проєкту — використовуйте їх.
Можливо, варіанти використання зараз не в моді, але я ніколи не чув переконливого пояснення, чому. Аналіз варіантів використання є позачасовою, цінною технікою, яка має бути в арсеналі кожного бізнес-аналітика.
Оригінальна стаття Карла Вігерса – Use Cases: The Business Analyst’s Best Friend, переклад – Іван Вільчавський. Зображення згенероване у ChatGPT.