З 2000 року я (Олександр Москалюк, Senior Business Analyst в Yalantis) брав участь у понад 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).
У цій методиці вимоги описано у форматі сценаріїв використання, а історії користувачів застосовувались як задачі для команди.
З часом ідея використати User Stories для опису вимог мені видавалась все більш привабливою. Їхній формат добре підходить для опису вимог зацікавлених осіб. Я розраховував, що завдяки більш зрозумілому формату їх буде легше погоджувати із замовниками. Водночас функціональні вимоги, наповнені технічними деталями, можна описувати у форматі сценаріїв використання.
Для мене стало певним відкриттям те, що BABOK Guide не заперечує щодо використання User Stories та Use Cases в одному проєкті. Крім того, в BABOK історії користувачів подаються як техніка, яка зручна для запису саме вимог зацікавлених осіб через свій зрозумілий формат. Тобто нічого не заважає для опису різних видів вимог використовувати різний формат, оскільки вимоги можуть мати різні атрибути та структуру.
Схема, коли вимоги зацікавлених осіб оформляються у вигляді історій користувачів, а функціональні вимоги до них описуються сценаріями використання, створює певні переваги:
- вимоги зацікавлених осіб, оформлені у вигляді історій користувачів, описуються зрозумілою мовою для замовників і їх стає простіше погодити;
- історії користувачів описують функціональність без технічних деталей, що зменшує їхню кількість і прискорює погодження. Дизайни та додаткові деталі погоджуються окремо за потреби;
- критерії приймання, написані до кожної історії, дають змогу деталізувати функціональність і водночас сформувати список питань для приймального тестування;
- опис функціональних вимог за допомогою сценаріїв використання допомагає зібрати всю логіку окремої функціональності в одному місці. В них описуються технічні деталі, які були не цікаві замовнику, але потрібні розробникам і тестувальникам;
- кожен сценарій використання, своєю чергою, розбивається на кілька завдань у JIRA, які не мають опису і використовуються для планування та контролю роботи команди.
Таким чином виходить мікс, коли спочатку ми описуємо вимоги зацікавлених осіб у форматі історій користувачів, потім їх деталізуємо до функціональних вимог у вигляді сценаріїв використання, які дробимо на задачі з типом «Історія» в JIRA для планування роботи команди (див. рис. 2).
Я спробував цю модель в одному з проєктів і отримав такі результати:
- Вимоги стали зрозумілішими для замовників, що спростило та прискорило процедуру їх погодження.
- В процесі погодження вимог одразу узгоджували із замовниками критерії приймання, які пізніше використовувались для тестування готового рішення.
- Функціональні вимоги описувались у форматі сценаріїв використання в зручному для розробників вигляді з усією додатковою інформацією.
- Confluence залишився «джерелом правди», в ньому можна було завжди знайти актуальну версію вимог і переглянути історію змін.
Висновок
Цей досвід ще раз переконав мене, що можна поєднувати різні техніки роботи та різні методики, головне, щоб таке поєднання було зрозумілим та зручним усім учасникам проєкту. Також я дійшов висновку, що не існує «правильної» техніки опису вимог. Є формат, який найкраще підходить для конкретного проєкту, саме він є «правильним» для нього.
Наостанок хочу подякувати своїм колегам з компанії Yalantis Катерині Віжан та Ользі Погорілій за допомогу під час написання статті.
Стаття вперше опублікована 16 серпня 2021 на DOU