User Stories и Acceptance Criteria
User Story — короткое описание функциональности с точки зрения пользователя; Acceptance Criteria — чёткие условия, при выполнении которых история считается завершённой.
Зачем нужно
User Stories помогают фокусироваться на ценности для пользователя, а не на технической реализации. Acceptance Criteria (AC) устраняют неоднозначность: разработчик знает точно, что нужно сделать, тестировщик — что проверять, PO — что принять. Плохо написанные истории — главная причина споров в конце спринта.
Где используется
- Scrum Sprint Planning — основная единица планирования
- Product Backlog — формат хранения требований
- QA — основа для тест-кейсов
- RS School — задания часто описаны в формате User Stories
Формат User Story
Шаблон:
Как [роль пользователя],
я хочу [действие/возможность],
чтобы [польза/ценность].
Примеры:
Как зарегистрированный пользователь,
я хочу восстановить пароль через email,
чтобы вернуть доступ к аккаунту без обращения в поддержку.
Как администратор,
я хочу экспортировать отчёт в CSV,
чтобы передавать данные в бухгалтерию.
Как гость сайта,
я хочу видеть цены без регистрации,
чтобы принять решение о покупке.
INVEST-критерии хорошей User Story
I — Independent (независима от других историй)
N — Negotiable (детали обсуждаемы, не жёсткие)
V — Valuable (несёт ценность для пользователя)
E — Estimable (можно оценить в SP)
S — Small (выполнима за 1 спринт, идеально 1–3 дня)
T — Testable (есть чёткие критерии проверки)
Acceptance Criteria
Формат Given / When / Then (Gherkin)
Given [начальное состояние / контекст]
When [действие пользователя]
Then [ожидаемый результат]
Пример:
Story: Восстановление пароля
AC 1:
Given пользователь не авторизован
When открывает /forgot-password и вводит email
Then получает письмо со ссылкой для сброса в течение 5 минут
AC 2:
Given пользователь перешёл по ссылке из письма
When вводит новый пароль дважды (совпадает, 8+ символов)
Then пароль изменён, пользователь перенаправлен на /login
AC 3:
Given пользователь перешёл по ссылке из письма
When вводит пароль менее 8 символов
Then показывается ошибка: "Минимум 8 символов"
AC 4 (edge case):
Given ссылка для сброса устарела (>24 ч)
When пользователь открывает ссылку
Then показывается ошибка: "Ссылка устарела, запросите новую"
Чеклист-формат AC
Для более простых историй:
- Форма содержит поля: email, пароль, подтверждение
- Валидация: email по формату, пароль 8+ символов
- При успехе: письмо уходит в течение 5 минут
- При ошибке email: "Пользователь не найден"
- Ссылка истекает через 24 часа
- Один email → одна активная ссылка (старые аннулируются)
Частые ошибки
| Ошибка | Проблема | Решение |
|---|---|---|
| "Сделать авторизацию" без AC | Разработчик сделает по-своему | Написать AC до начала разработки |
| AC только happy path | Баги в edge case идут в прод | Всегда добавлять негативные сценарии |
| Слишком большая история (эпик) | Не входит в спринт | Декомпозировать на несколько историй |
| Технические детали в Story | Решение навязывается разработчику | Story о потребности, детали — в задачах |
Связанные темы
- _MOC Процессы
- Scrum -- роли, события, артефакты
- Estimation -- Story Points и Planning Poker
- Декомпозиция задач
- Задача -- как прочитать и понять ТЗ