Руководство по Agile · Agile-практики
Пользовательские истории: как их писать, с шаблонами и примерами
Пользовательская история — это краткое описание на простом языке того, что нужно пользователю, написанное с его точки зрения. Она фиксирует, кто чего хочет и зачем, и служит поводом для обсуждения деталей, а не полной спецификацией.
Главное
- Пользовательская история говорит, кому что-то нужно, что именно и зачем.
- Критерии приёмки делают каждую историю тестируемой; критерии готовности (Definition of Done) применяются ко всем историям.
- Проверяйте качество по INVEST и разделяйте истории, которые не помещаются в спринт.
- Истории — отправная точка для обсуждения, а не полная спецификация.
Шаблон пользовательской истории
Самый распространённый формат: Как [тип пользователя], я хочу [достичь цели] чтобы [получить выгоду].
- Кто: конкретный пользователь или роль, а не «система».
- Что: цель или возможность, которая нужна пользователю, а не техническое решение.
- Зачем: выгода, которая помогает команде найти самый простой способ её реализовать.
Многие команды описывают историю через три C: карточке (краткая письменная история), обсуждение (conversation) (обсуждение, в ходе которого уточняются детали) и подтверждение (confirmation) (критерии приёмки, показывающие, что работа выполнена).
Критерии приёмки
Критерии приёмки — это условия, которым должна соответствовать история, чтобы быть принятой. Они делают историю тестируемой и уменьшают недопонимание. Два распространённых стиля:
- Чек-лист: «В записи указаны время и место занятия»; «Участник получает письмо с подтверждением».
- Given-When-Then (Дано — Когда — Тогда): «Дано: на занятии есть свободные места; когда участник нажимает „Записаться“, тогда место бронируется, а число свободных мест уменьшается на одно».
Чек-лист INVEST
| Буква | Значение | Вопрос для проверки |
|---|---|---|
| I | Независимая (Independent) | Можно ли её реализовать, не дожидаясь другой истории? |
| N | Обсуждаемая (Negotiable) | Открыты ли детали для обсуждения, а не зафиксированы жёстко? |
| V | Ценная (Valuable) | Приносит ли она ценность пользователю или бизнесу? |
| E | Оцениваемая (Estimable) | Понимает ли её команда достаточно хорошо, чтобы оценить? |
| S | Небольшая (Small) | Можно ли её завершить за один спринт? |
| T | Тестируемая (Testable) | Есть ли чёткие критерии приёмки? |
Как написать пользовательскую историю: пошагово
- Определите пользователя и его цель, в идеале на основе исследований или реальной обратной связи.
- Запишите историю по шаблону в одном-двух предложениях.
- Добавьте от трёх до шести критериев приёмки.
- Обсудите её с командой во время уточнение бэклога и скорректируйте её.
- Проверьте её по INVEST; если она слишком большая, разделите.
- Оцените её, например, с помощью стори-поинты.
- Упорядочьте её в бэклог продукта по ценности, рискам и зависимостям.
Примеры: слабые и улучшенные
| Слабая история | Улучшенная история |
|---|---|
| Как пользователь, я хочу таблицу в базе данных для бронирований. | Как участник клуба, я хочу записаться на занятие, чтобы моё место было забронировано. |
| Как система, я хочу отправлять электронные письма. | Как участник клуба, я хочу получать письмо с подтверждением записи, чтобы у меня была информация о занятии. |
| Как пользователь, я хочу, чтобы сайт был быстрым. | Как пользователь мобильного устройства, я хочу, чтобы расписание загружалось менее чем за две секунды, чтобы записываться на ходу. |
| Как администратор, я хочу модуль отчётов с 15 отчётами. | Как менеджер фитнес-клуба, я хочу видеть еженедельную посещаемость каждого занятия, чтобы корректировать расписание. |
Полный пример: Как участник клуба, я хочу записаться в лист ожидания, когда занятие заполнено, чтобы получить место, если кто-то отменит запись. Критерии приёмки: кнопка «Встать в лист ожидания» появляется только когда занятие заполнено; участник видит свою позицию; когда место освобождается, первому в очереди оно предлагается по email, и у него есть два часа, чтобы принять его.
Типичные ошибки
- Технические задачи, замаскированные под истории.
- Истории настолько большие, что растягиваются на несколько спринтов; считайте их эпика и разделяйте их.
- Нет части «чтобы», из-за чего скрывается реальная потребность.
- Отношение к истории как к контракту, а не как к поводу для обсуждения.
- Отсутствующие или расплывчатые критерии приёмки, которые приводят к переделкам.
- Запись каждой истории по шаблону, даже когда простое предложение было бы понятнее.
Бесплатные шаблоны по этой теме
Частые вопросы
Что такое пользовательская история в Agile?
Краткое описание потребности пользователя, написанное с его точки зрения, которое команда превращает в работающую функциональность.
Каков формат пользовательской истории?
Как [тип пользователя], я хочу [цель], чтобы [выгода].
Кто пишет пользовательские истории?
Писать их может любой, но обычно владелец продукта отвечает за то, чтобы они были понятны и упорядочены в бэклоге.
Входят ли пользовательские истории в Scrum?
Нет. Руководство по Scrum говорит об элементах бэклога продукта; пользовательские истории — популярный способ их записи.
Что такое критерии приёмки в пользовательских историях?
Конкретные проверяемые условия, которым должна соответствовать история, чтобы быть принятой; часто записываются в виде чек-листа или в формате Given-When-Then.
Насколько маленькой должна быть пользовательская история?
Достаточно небольшой, чтобы завершить её за один спринт, а в идеале — за несколько дней.
Что означает INVEST для пользовательских историй?
Independent (независимая), Negotiable (обсуждаемая), Valuable (ценная), Estimable (оцениваемая), Small (небольшая) и Testable (тестируемая).
В чём разница между пользовательской историей и требованием?
Традиционное требование подробно определяет, что должна делать система; пользовательская история описывает потребность и предлагает обсудить детали. См. требования к проекту.
В чём разница между пользовательской историей и эпиком?
Так называемый эпик — это большой объём работы, состоящий из многих историй; история помещается в один спринт.
Как оценивать пользовательские истории?
Большинство команд используют относительную оценку, например стори-поинты или размеры футболок, согласуя её всей командой.
Можно ли использовать пользовательские истории вне разработки ПО?
Да. Маркетинговые и другие команды пишут истории вроде «Как потенциальный клиент, я хочу сравнение тарифов, чтобы выбрать план»; см. Agile-маркетинг.