Як схрестити слона з бегемотом, або Чи можна поєднати User Stories та Use Cases в одному проєкті

З 2000 року я брав участь у понад 100 проєктах і в більшості з них займався документуванням вимог користувачів. У кожному проєкті були свої особливості оформлення вимог, що викликало у мене постійне бажання дізнатися, як писати їх «правильно». Трохи часу і можливостей розібратись у цьому питанні з’явилось лише після того, як я кілька років тому зосередився на роботі бізнес-аналітика.

На мою думку, формат опису вимог впливає більше на процес роботи з ними, а не на зміст. Саме тому мені було цікаво зрозуміти, як їх оформлення позначиться на організації роботи бізнес-аналітика, чи є «правильний» формат і чи можна поєднувати різні підходи.

У статті розповім про свій досвід поєднання форматів сценаріїв використання та історій користувачів в одному проєкті. Матеріал може бути цікавий бізнес-аналітикам, проєктним менеджерам та іншим спеціалістам, чия робота пов’язана з оформленням вимог.

Ілюстрація Марії Рибак

Трохи історії та теорії

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

Далі я ознайомився зі сценаріями використання (Use Cases). На відміну від технічних завдань, сценарії використання є не просто форматом опису вимог, а частиною уніфікованої мови моделювання (Unified Modeling Language). Звичайно, нічого не заважає просто описувати вимоги у форматі сценаріїв використання, але ефективніше буде їх застосовувати разом з UML-діаграмами.

Оформляючи вимоги у вигляді Use Cases, почати варто з діаграми сценаріїв використання (Use Case diagram), яка допоможе виявити основних акторів, верхньорівневий функціонал та який актор яким функціоналом буде користуватись. Далі описати вимоги сценаріями використання, перевіряючи логіку діаграмами активностей (Activity diagram) та станів (State machine). Готові сценарії можна зібрати у специфікацію вимог до системи (SRS).

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

У сценарії використання можна вносити зміни, щоб вони відбивали актуальні вимоги до системи. Системи управління вимогами, такі як Confluence, добре справляються з показуванням історії змін в документі та дозволяють швидко порівняти різні версії вимог. Це значно спрощує процес управління змінами.

От тільки є у сценаріїв використання один недолік — їх складно зрозуміти замовникам без технічного досвіду. Після чергової невдалої спроби погодити сценарії використання із замовником в одному з проєктів я зрозумів, що потрібно розглянути інші формати. Олію у вогонь підливали постійні запитання: «А чи можна описувати вимоги у форматі історій користувачів? Це ж просто та зрозуміло». Відмовлятись від зручного формату опису вимог не хотілось, але й працювати без погоджених вимог теж не можна. Тому я вирішив подивитись у бік історій користувачів (User Stories).

Формат історії користувача приваблює тим, що він написаний зрозумілою для замовника мовою. Тому історії зручні для обговорення, їх простіше погоджувати. Як і сценарії використання, User Stories можна використовувати як окремо, так і разом з іншими Scrum-артефактами. Працюючи за методологією Scrum, варто почати з карти історій (User Story Map), під час роботи з якою можна визначити ролі користувачів та основну функціональність системи для них. Далі розбити функціональність на менші частини та розділити їх на релізи. Основний та альтернативний варіанти роботи окремої функціональності системи можна описати в епіку, доповнивши його BPMN-діаграмою. Далі історіями користувачів описуємо складові функціональності та доповнюємо їх критеріями приймання. Критерії приймання, своєю чергою, стануть основою для тестування та передачі виконаної частини роботи.

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

У сценаріях використання вся потрібна інформація з усіма змінами розташована в одному місці, тому аналізувати їх значно простіше, ніж зміни в історіях користувачів. Але складна процедура погодження із замовниками часто нівелює цю перевагу.

Як я схрещував носорога і слона

Під час аналізу технік у мене виникло питання: чому не спробувати описувати частину вимог у форматі історій користувачів, а частину — сценаріями використання?

Відповідь «це неправильно!» мене не дуже влаштовувала. Тим паче, що де-факто я вже поєднував ці два формати в деяких проєктах, щоправда, обмежено: всі вимоги були описані у форматі сценаріїв використання у Confluence, а в JIRA до них створювались завдання без опису, за допомогою яких ставились задачі програмістам. До одного сценарію використання прив’язувалась історія в JIRA, якщо він був маленьким. Якщо сценарій використання був складним, то в JIRA робилось кілька історій, якими реалізовувались окремі потоки сценарію використання.

Коли у функціональність вносили зміни, сценарій використання коригувався і створювались нові історії, відповідно до яких ці зміни втілювались.

Таким чином, Confluence залишався єдиним місцем для опису вимог, а JIRA застосовувалась для управління роботою команди (див. рис. 1).

Рисунок 1. Структура вимог в Confluence та їхній зв’язок із задачами в JIRA

У цій методиці вимоги описано у форматі сценаріїв використання, а історії користувачів застосовувались як задачі для команди.

З часом ідея використати User Stories для опису вимог мені видавалась все більш привабливою. Їхній формат добре підходить для опису вимог зацікавлених осіб. Я розраховував, що завдяки більш зрозумілому формату їх буде легше погоджувати із замовниками. Водночас функціональні вимоги, наповнені технічними деталями, можна описувати у форматі сценаріїв використання.

Для мене стало певним відкриттям те, що BABOK Guide не заперечує щодо використання User Stories та Use Cases в одному проєкті. Крім того, в BABOK історії користувачів подаються як техніка, яка зручна для запису саме вимог зацікавлених осіб через свій зрозумілий формат. Тобто нічого не заважає для опису різних видів вимог використовувати різний формат, оскільки вимоги можуть мати різні атрибути та структуру.

Схема, коли вимоги зацікавлених осіб оформляються у вигляді історій користувачів, а функціональні вимоги до них описуються сценаріями використання, створює певні переваги:

  • вимоги зацікавлених осіб, оформлені у вигляді історій користувачів, описуються зрозумілою мовою для замовників і їх стає простіше погодити;
  • історії користувачів описують функціональність без технічних деталей, що зменшує їхню кількість і прискорює погодження. Дизайни та додаткові деталі погоджуються окремо за потреби;
  • критерії приймання, написані до кожної історії, дають змогу деталізувати функціональність і водночас сформувати список питань для приймального тестування;
  • опис функціональних вимог за допомогою сценаріїв використання допомагає зібрати всю логіку окремої функціональності в одному місці. В них описуються технічні деталі, які були не цікаві замовнику, але потрібні розробникам і тестувальникам;
  • кожен сценарій використання, своєю чергою, розбивається на кілька завдань у JIRA, які не мають опису і використовуються для планування та контролю роботи команди.

Таким чином виходить мікс, коли спочатку ми описуємо вимоги зацікавлених осіб у форматі історій користувачів, потім їх деталізуємо до функціональних вимог у вигляді сценаріїв використання, які дробимо на задачі з типом «Історія» в JIRA для планування роботи команди (див. рис. 2).

Рисунок 2. Опис різних видів вимог в Confluence та деталізація на задачі в JIRA

Я спробував цю модель в одному з проєктів і отримав такі результати:

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

Висновок

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

Наостанок хочу подякувати своїм колегам з компанії Yalantis Катерині Віжан
та Ользі Погорілій за допомогу під час написання статті.

👍НравитсяПонравилось28
В избранноеВ избранном18
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дополнительно:
• статья с диаграммами и реальными примерами, описывающая от Visual Paradigm
circle.visual-paradigm.com/...​teps-wizards/use-case-2.0
(нацелена на пример использования их софта, но прекрасно описывает вариант декомпозиции UC->US)
• ссылка на шаблон UC от Seilevel, которым пользуюсь: seilevel.com/download/9765

а можна якийсь реальний приклад юзейр кейсів і сторіс ?

Реальні показати не зможу, можливо буду готувати якісь тестові матеріали — скину.

Дякую за огляд. То з замовниками ви працюєте лише на рівні User Stories у Jira? Що саме вони отримують на погодження?

Так, в тому проєкті замовники погоджували тільки верхньорівневі історії користувачів та дизайни

Судя по рис. 1 и 2, «скрещевание» последовательно идет на разных уровнях детализации. По идее, так и должно быть, поскольку Use Case — это уровень требований пользователя, а User Story — уровень функциональных требований (по Вигерсу). Или в вашем случае уровни требований как-то по другому рассматривались?

На сколько помню Вигерса, как UC так и US относятся к уровню пользовательских требований.

Саме так — спеціально перечитав класика ВА :) Історії та сценарії використання у нього описують однаковий рівень вимог.

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

і що сказали розробники про такий спосіб описання вимог?

вони продовжили працювати з сценаріями використання, тому для них нічого не змінилось

пічаль. то яка була ціль всього двіжу?

спростити роботу з замовниками

То есть, разработчикам вы юзер стори не предоставляете? И им из юз кейса ясны все технические детали? А как же тогда тест сценарии? Тоже по юз кейсам?

так, тест кейси теж робляться по сценаріях використання. А UAT — по критеріях приймання юзер сторі

дуже нагадує І.Якобсена use case 2.0. мені здається, занадто складна структура та передокументування. тримати в такому сетапі актуальність вимог складнувато. хоча, можливо того вимагав проект автора

Насправді кількість роботи не змінилась, просто різні типи вимог почали документуватись в різних форматах.

Подписаться на комментарии