Користувацькі історії (User Stories)

Історія користувача являє собою невеликий, стислий опис функціональності або якості, необхідних для надання цінності конкретній зацікавленій стороні (specific stakeholder).

Розглянемо спочатку Користувацькі історії (User Stories) 10.48 які описані в Техніках BABOK v3

Опис Користувацьких історій (User Stories) в BABOK v3 (10.48.2)

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

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

Користувацькі історії можуть бути використані

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

Елементи Користувацьких історій (User Stories) в BABOK v3 (10.48.3)

Назва (за бажанням) User Stories (10.48.3.1)

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

Висновок про цінність User Stories (10.48.3.2)

Обов'язкової структури для історій користувачів не існує. Найпопулярніший формат включає три компоненти:

• Хто (who): роль або персона користувача.
• Що (what): необхідна дія, поведінка, властивість або якість.
• Чому (why): вигода або цінність, яку отримує користувач, коли історія реалізується.

Наприклад, "Як <хто>, мені потрібно <що>, щоб <чому>." "As a <who>, I need to <what>, so that <why>

"За умови... Коли... Тоді" ("Given...When...Then") - ще один поширений формат.

Розмова User Stories (10.48.3.3)

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

Критерії прийняття (Acceptance Criteria) User Stories (10.48.3.4)

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

Міркування щодо використання User Stories (10.48.4)

Сильні сторони User Stories (10.48.4.1)

• Легко зрозумілий для зацікавлених сторін.
• Може бути розроблений за допомогою різних методів збору інформації.
• Зосереджується на цінності для зацікавлених сторін.
• Спільне розуміння бізнес-домену покращується завдяки співпраці у визначенні та вивченні історій користувачів.
• Прив'язаний до невеликих, реалістичних і перевірених фрагментів функціональності, що сприяє швидкому наданню послуг і частому зворотному зв'язку з клієнтами.

Обмеження використання User Stories (10.48.4.2)

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

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