Пользовательская история
User Story — формат описания требований, придуманный в XP (Extreme Programming) и взятый Scrum'ом. Классическая формула:
Как [роль пользователя],
я хочу [возможность],
чтобы [получить пользу].
Пример: «Как новый пользователь, я хочу видеть видео-туториал на главной, чтобы быстро разобраться с продуктом».
У хорошей User Story есть три качества (мнемоника INVEST):
- Independent — независима от других историй
- Negotiable — детали можно обсуждать
- Valuable — даёт ценность пользователю
- Estimable — можно оценить трудоёмкость
- Small — помещается в один спринт
- Testable — можно проверить готовность
К каждой User Story прилагаются Acceptance Criteria — критерии, по которым команда понимает, что история выполнена.
Когда применять и когда нет
Применять
- Работаете в Scrum или Kanban
- Хотите ставить требования с фокусом на пользу для пользователя
- Нужна гибкость в обсуждении деталей реализации
Не применять
- Чисто технические задачи (рефакторинг, миграция БД) — лучше использовать формат Task
- Зарегламентированные процессы со строгими ТЗ
Примеры применения
«Как менеджер по продажам, я хочу видеть стадию каждой сделки на канбан-доске, чтобы быстро понимать, какие сделки требуют внимания.»
Acceptance Criteria:
• На странице «Сделки» отображается канбан-доска с колонками по стадиям воронки.
• Сделки можно перетаскивать между колонками.
• При перетаскивании отправляется событие в аналитику.
Часто задаваемые вопросы
ТЗ описывает как сделать (детали реализации), User Story — зачем (польза для пользователя). Детали реализации обсуждаются командой при работе над историей, а не фиксируются заранее.
Конкретные проверяемые условия: «при клике на X происходит Y», «поле Z обязательно для заполнения», «ошибка отображается красным». Это чек-лист для приёмки.
Чаще всего — в Story Points (по шкале Фибоначчи: 1, 2, 3, 5, 8, 13). Если история больше 13 — её надо разбить на меньшие.