Як написати історії користувачів (з прикладами і критеріями приймання)

Історія користувача — це короткий опис функції з точки зору користувача: «Як [тип користувача], я хочу [мета], щоб [причина]». Під нею ви пишете критерії приймання — кілька конкретних умов, які мають виконуватися, щоб історія вважалася завершеною. Кожна історія має бути достатньо малою, щоб її можна було побудувати й перевірити за один раз, а критерії слід писати так, щоб їх міг перевірити будь-хто.

Історії користувачів стали популярними в командах, які працюють за Agile, але вони так само корисні, коли ви будуєте самостійно з AI-конструктором застосунків. Добра історія — це добрий промпт.

Формат

Історія користувача має три частини:

Як [хто], я хочу [що], щоб [навіщо].

• Хто — конкретний тип користувача: новий відвідувач, платний учасник, адміністраторка клініки, адмін. Не «користувач».
• Що — дія, яку людина хоче виконати, її словами. Не те, як влаштований екран.
• Навіщо — результат, який для неї важливий. Це частина, яку люди пропускають, і саме вона не дає будувати не те.

Приклад:

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

«Навіщо» розповідає дві речі, яких не каже «що»: це має працювати на телефоні, і тут задіяні лист очікування та правила штрафів.

Критерії приймання

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

Поширений спосіб їх записувати — Дано / Коли / Тоді:

• Дано — початкова ситуація
• Коли — користувач щось робить
• Тоді — такий результат

Для історії про запис у спортзал:

1. Дано, що в мене є запис більш ніж за 12 годин, коли я натискаю Скасувати і підтверджую, тоді запис видаляється і я бачу «Запис скасовано».
2. Дано, що я скасовую запис і на заняття є лист очікування, коли скасування збережено, тоді перша людина з листа отримує місце і лист на email.
3. Дано, що запис менш ніж за 12 годин, коли я натискаю Скасувати, тоді я бачу, що застосовується штраф за скасування в останній момент, ще до підтвердження.
4. Дано, що мій екран завширшки з телефон, тоді кнопка Скасувати видна без горизонтального прокручування.

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

Крок за кроком: як написати добру історію

Крок 1: Почніть з реального користувача і реальної проблеми

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

Крок 2: Напишіть історію в один рядок

Заповніть шаблон. Якщо ви не можете написати переконливе «щоб», запитайте себе, чи ця функція взагалі потрібна.

Крок 3: Додайте від трьох до шести критеріїв приймання

Спершу охопіть основний успішний сценарій, потім важливі варіанти: іншу роль, порожній стан, обмеження, помилку. Якщо пишете більше шести, історія, ймовірно, занадто велика.

Крок 4: Зафіксуйте, що поза межами

Один рядок заощадить багато листування: «Поза межами: повернення коштів за платні заняття; адміни, які скасовують записи за учасників». Це не дасть історії рости, поки ви її будуєте.

Крок 5: Перевірте за INVEST

INVEST — поширений чеклист для добрих історій. Історія має бути:

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

Добрі й погані приклади

Як розбити занадто велику історію

Великі історії — це місце, де проєкти зупиняються. Поширені способи розбиття:

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

Кожна частина все одно має бути тим, чим користувач може скористатися і що помітить.

Історії користувачів як промпти

Історія користувача з критеріями приймання дуже близька до доброго промпту для AI-конструктора застосунків. Вона дає AI хто, що, навіщо і визначення готовності. Надсилайте одну історію в повідомленні:

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

1. Скасування є в кожному записі на сторінці Мої записи, з кроком підтвердження.
2. Скасування більш ніж за 12 годин до заняття просто видаляє запис.
3. Менш ніж за 12 годин показуй «Застосовується штраф за скасування в останній момент — $5» перед підтвердженням і зберігай штраф у записі.
4. Якщо на заняття є лист очікування, перша людина отримує місце і лист на email.
5. Працює на екрані завширшки з телефон. Поза межами: повернення коштів, скасування записів персоналом за учасників. Побудуй це, потім перевір кожен критерій у попередньому перегляді і скажи, які пройшли.

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

Ось моя ідея застосунку: [два-три речення]. Напиши історії користувачів для першої версії, згрупувавши їх за типом користувача, кожна з 3–5 критеріями Дано/Коли/Тоді. Позначте, які з них потрібні для запуску, а які можуть почекати.

Завжди читайте й редагуйте результат. AI не знає ваших користувачів, а ви знаєте.

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

Де історії користувачів поєднуються з іншими документами

• Документ вимог до продукту описує весь продукт: проблему, користувачів, обсяг. Історії користувачів — це докладні частини всередині нього. Див. як написати PRD з AI.
• Звіт про баг описує щось зламане відносно історії, яка вже була побудована. Див. як написати хороший звіт про баг.
• MVP — це найменший набір історій, який дає головну цінність. Див. що таке MVP.

Поширені помилки

• «Як користувач…» Занадто розпливчасто. Назвіть реальний тип користувача.
• Пропуск «щоб». Без причини не можна зважувати компроміси.
• Опис рішення замість потреби. «Я хочу випадаючий список» фіксує дизайн, ще до того як хтось про нього подумав.
• Критерії, які не можна перевірити. «Легко», «швидко» і «інтуїтивно» — це побажання, а не критерії.
• Історії, які насправді є епіками. «Керувати своїм акаунтом» — це десять історій.
• Писати всі історії наперед. Опишіть детально наступні кілька; решту тримайте одним рядком, доки не дійдете до них.

Історії в Mythex

У Mythex режим Plan — добре місце, щоб перетворити ідею на історії: агент обговорює підхід, перш ніж щось редагувати. Коли історія готова, перейдіть до Build і вставте її, по одній історії в повідомленні. Після кожної /test може пройтися попереднім переглядом і перевірити сценарій, а будь-яку відповідь можна відкотити через Повернутися до цієї точки, якщо щось пішло не так. Див. ефективні промпти у документації і наш посібник про написання промптів для AI-конструкторів застосунків.

Чеклист історії користувача

• Називає конкретний тип користувача
• Описує потребу, а не дизайн
• Містить справжнє «щоб» з причиною
• Має від трьох до шести перевірюваних критеріїв приймання
• Охоплює принаймні один граничний випадок або помилку
• Зазначає, що поза межами
• Достатньо мала, щоб побудувати і перевірити за один раз
• Критерії перевірені після побудови, один за одним

Запитання