User story, критерии приёмки и use case
Формат user story
Как <роль>, я хочу <действие или возможность>, чтобы <ценность>.Пример: Как покупатель, я хочу сохранить товар в избранное, чтобы вернуться к нему позже и не искать заново.
Все три части обязательны. Без «чтобы» непонятно, зачем это делать и как выбрать лучшее решение. Роль должна быть конкретной («покупатель», «кладовщик»), а не «пользователь» или «система».
INVEST
| Буква | Свойство | Что значит |
|---|---|---|
| I | Independent — независимая | Можно сделать и выпустить отдельно от других историй |
| N | Negotiable — обсуждаемая | Это повод для разговора, а не контракт; детали уточняются с командой |
| V | Valuable — ценная | Даёт пользу пользователю или бизнесу. «Создать таблицу в БД» — не история |
| E | Estimable — оцениваемая | Команда может оценить трудозатраты. Если не может — не хватает знаний, нужен spike |
| S | Small — небольшая | Помещается в один спринт; большая история — это эпик, её надо разбить |
| T | Testable — тестируемая | Есть критерии приёмки, по которым можно однозначно проверить готовность |
Ещё одна модель — 3C: Card (короткая запись), Conversation (обсуждение деталей), Confirmation (критерии приёмки).
Как разбивать большие истории
- По шагам процесса: поиск → карточка товара → корзина → оплата.
- По вариантам бизнес-правил: оплата картой, потом СБП, потом в рассрочку.
- По типам данных или ролей: сначала для физлиц, затем для юрлиц.
- Простой вариант, затем сложный: сначала поиск по названию, потом фильтры и подсказки.
- Счастливый путь, затем обработка ошибок.
Критерии приёмки: Given / When / Then
История: Как покупатель, я хочу применить промокод в корзине, чтобы получить скидку.
Сценарий 1. Действующий промокод
Дано: в корзине товары на 3000 ₽, промокод SALE10 активен (скидка 10%)
Когда: покупатель вводит SALE10 и нажимает «Применить»
Тогда: сумма заказа становится 2700 ₽, показано «Скидка 300 ₽»
Сценарий 2. Промокод истёк (негативный)
Дано: промокод SALE10 действовал до 01.11
Когда: покупатель вводит его 05.11
Тогда: показано «Срок действия промокода истёк», сумма не меняется
Сценарий 3. Не выполнено условие минимальной суммы (негативный)
Дано: промокод BIG500 действует при заказе от 5000 ₽, в корзине — на 3000 ₽
Когда: покупатель вводит BIG500
Тогда: показано «Промокод действует для заказов от 5000 ₽»
Сценарий 4. Несуществующий промокод (негативный)
Когда: покупатель вводит QWERTY
Тогда: показано «Промокод не найден»Всегда добавляйте негативные сценарии: неверные данные, истёкшие сроки, отсутствие прав, недоступность внешней системы, граничные значения.
Кроме GWT, критерии приёмки пишут списком правил (rule-oriented): «скидка не суммируется с другими акциями», «промокод можно применить один раз на заказ».
Definition of Ready и Definition of Done
- DoR — история готова к взятию в спринт: понятна ценность, есть критерии приёмки, есть макеты, зависимости сняты, команда её оценила.
- DoD — история считается сделанной: код прошёл ревью, тесты зелёные, критерии приёмки выполнены, документация обновлена, фича выложена на нужный стенд.
Use case
Use case — подробное описание взаимодействия актора с системой для достижения цели. Шаблон (по Коберну, упрощённо):
| Поле | Пример: «Оформить заказ» |
|---|---|
| Актор | Покупатель |
| Цель | Оформить и оплатить заказ |
| Предусловия | Покупатель авторизован, корзина не пуста |
| Основной сценарий | 1. Покупатель открывает корзину. 2. Система показывает товары и сумму. 3. Покупатель выбирает доставку. 4. Система рассчитывает стоимость доставки. 5. Покупатель выбирает способ оплаты и подтверждает. 6. Система создаёт заказ и перенаправляет на оплату. 7. Платёжная система подтверждает оплату. 8. Система меняет статус на «Оплачен» и отправляет письмо. |
| Альтернативные сценарии | 4а. Адрес вне зоны доставки: система предлагает самовывоз. 7а. Оплата отклонена: заказ остаётся в статусе «Ожидает оплаты», покупатель может повторить попытку. |
| Постусловия | Заказ создан и оплачен, товары зарезервированы |
User story или use case?
- User story — Agile, короткие итерации, команда рядом и детали обсуждаются устно.
- Use case — сложные сценарии с множеством ветвлений, интеграции, распределённые команды, подрядчики, договорная разработка.
- На практике их часто совмещают: история в бэклоге со ссылкой на use case или спецификацию.
Вопросы для самопроверки
Что не так с историей «Как пользователь, я хочу кнопку экспорта»?
Роль не конкретная, вместо потребности назван элемент интерфейса, нет ценности («чтобы…»). Лучше так: «Как бухгалтер, я хочу выгрузить список оплат за месяц в Excel, чтобы сверить их с банковской выпиской».
Чем критерии приёмки отличаются от DoD?
Критерии приёмки уникальны для каждой истории и описывают её поведение. DoD — общий для команды чек-лист качества, который применяется ко всем историям.
Как описать НФТ через user story?
Можно отдельной историей-ограничением («Как владелец магазина, я хочу, чтобы каталог открывался быстрее 1 с, чтобы не терять покупателей»). Но чаще НФТ записывают в DoD или как критерии приёмки к функциональным историям.
Конспекты статей по теме
Подробные конспекты полезных статей. В конце каждого есть ссылка на оригинал и автора.
- User Story: полный гайд по написанию без ошибок — Сергей Прощаев (sproshchaev, OTUS)
- Гайд по написанию пользовательских историй и критериев приёмки — Валентина Ляликова (ValyaLialya, X5 Tech)
- Критерии приёмки для пользовательских историй: цели, форматы, примеры — ProQualityCommunity (перевод AltexSoft)