User story — короткая формулировка потребности от лица пользователя: «Как <роль>, я хочу <цель>, чтобы <ценность>». Она не описывает реализацию, она фиксирует, кому и зачем это нужно, и служит поводом для разговора. Use case — детальный сценарий взаимодействия актора с системой: основной ход событий плюс альтернативы и ошибки. Критерии приёмки — проверяемые условия, по которым понятно, что работа сделана. User story без критериев приёмки — самая частая ошибка: красивая карточка, под которой каждый понял своё. Берите story для простого и обсуждаемого, use case — для сложного с ветвлениями, критерии приёмки — всегда.
Я однажды видел стори «Как пользователь, я хочу восстанавливать пароль, чтобы вернуть доступ к аккаунту». Идеально по форме. Разработчик сделал восстановление по email. На приёмке выяснилось, что половина пользователей регистрировалась по телефону, без почты, — и для них фича не работала вообще. Стори была права, но под ней не было ни одного критерия приёмки. Все кивнули на красивую формулировку и разошлись, поняв каждый своё.
Что такое user story
User story — это короткое описание потребности с точки зрения того, кому она нужна. Канонический формат — три части:
Как <роль>, я хочу <цель>, чтобы <ценность>.
Как покупатель, я хочу сохранить карту,
чтобы не вводить её номер при каждой покупке.Каждая часть несёт смысл. Роль — для кого (не «пользователь» вообще, а конкретно покупатель, админ, курьер). Цель — что он хочет сделать. Ценность — зачем, какую его проблему это решает. Третья часть самая важная и её чаще всего пропускают: без «чтобы» вы не знаете, ради чего фича, и не сможете предложить более дешёвое решение той же проблемы.
Ключевое: story — это не спецификация и не контракт. Это напоминание о разговоре. Она намеренно короткая, чтобы команда обсудила детали устно, а не вычитывала их из документа. Детали живут в критериях приёмки.
Что такое use case
Use case описывает, как актор (пользователь или внешняя система) взаимодействует с системой, чтобы достичь цели — но не одной строчкой, а пошагово, со всеми ветками. У классического use case есть структура:
- Актор — кто инициирует (покупатель).
- Предусловие — что должно быть верно до старта (пользователь авторизован).
- Основной сценарий — успешный ход событий по шагам.
- Альтернативные сценарии — ветки и ошибки (карта отклонена, нет связи с банком).
- Постусловие — что стало верно после (заказ оплачен, статус обновлён).
flowchart TD
A["Покупатель нажал «Оплатить»"] --> B{"Карта валидна?"}
B -- "да" --> C["Списываем сумму"]
B -- "нет" --> E["Ошибка: проверьте данные карты"]
C --> D{"Банк подтвердил?"}
D -- "да" --> F["Заказ оплачен, чек на email"]
D -- "нет" --> G["Ошибка: платёж отклонён, заказ не создан"]
E --> A
Схема выше — это и есть use case «оплата заказа» в виде сценария. Основной ход — зелёная дорога: карта валидна, банк подтвердил, заказ оплачен. Но интересны ветки: что если карта невалидна (вернуть к вводу), что если банк не подтвердил (платёж отклонён, заказ не создаём). Именно эти ответвления — главная ценность use case: они заставляют продумать, что система делает, когда что-то идёт не так. User story такие ветки в себя не вмещает — она для этого слишком короткая.
Разница и когда что брать
| User story | Use case | |
|---|---|---|
| Объём | Одна-две строки | От полстраницы и больше |
| Фокус | Зачем нужно (ценность) | Как происходит (сценарий) |
| Ветки и ошибки | Нет, выносятся в критерии | Да, явно прописаны |
| Когда удобно | Гибкая команда, фича обсуждается устно | Сложная логика, много ветвлений, внешние интеграции |
На практике это не «или-или». Простую и понятную фичу достаточно описать стори с критериями приёмки — лишний документ только замедлит. Сложный процесс с десятком исходов (оплата, бронирование, расчёт скидок) лучше развернуть в use case или диаграмму, иначе ветки потеряются. Я часто пишу стори как «шапку» — кому и зачем, — а под ней use case или сценарий для деталей. Одно не отменяет другое.
Критерии приёмки: то, что делает story проверяемой
Критерии приёмки (acceptance criteria) — это список проверяемых условий, при которых задача считается выполненной. Они превращают расплывчатую «хочу восстанавливать пароль» в то, что можно протестировать и принять. Без них не существует объективного «готово» — есть только мнения.
Писать их можно просто списком, а можно в формате Gherkin — given-when-then («дано — когда — тогда»):
Дано: пользователь зарегистрирован по номеру телефона
Когда: он запрашивает восстановление пароля
Тогда: код приходит в SMS, а не на email
Дано: введён неверный код подтверждения 3 раза подряд
Когда: пользователь вводит код в 4-й раз
Тогда: система блокирует попытки на 15 минутФормат given-when-then удобен тем, что заставляет проговорить контекст (дано), действие (когда) и ожидаемый результат (тогда). Именно второй критерий выше спас бы ту историю с восстановлением пароля из начала: кто-то на этапе критериев спросил бы «а если пользователь без email?» — и дыра вскрылась бы до разработки, а не на приёмке.
Правило, которое экономит спринты
Критерии приёмки пишутся до того, как задача уходит в работу, а не после. Это часть Definition of Ready — задача не готова к разработке, пока непонятно, как её принимать. Если вы не можете сформулировать критерии — значит, вы сами ещё не понимаете задачу, и разработчик тем более не поймёт.
Самая частая ошибка
Story без критериев приёмки. Карточка звучит понятно — и все думают, что договорились. Но «восстановить пароль», «показать профиль», «отправить уведомление» каждый достроит по-своему. Проверка простая: если по формулировке тестировщик не может написать тест, а разработчик не уверен, когда задача закрыта, — критериев не хватает.
Откуда это взялось
Use case старше. Его формализовал Айвар Якобсон в методе OOSE (1992), оттуда понятие «актор» и сценарии попали в UML. Это наследие тяжёлого, документо-ориентированного подхода: всё продумать заранее. User story — реакция на эту тяжесть: придумана в Extreme Programming (Кент Бек, около 1999) и закреплена Agile-манифестом 2001 года. Идея была радикальной: вместо толстого ТЗ — карточка-напоминание и живой разговор. Формат «Как роль, я хочу… чтобы…» добавил позже Майк Кон. Поэтому выбор между ними — это во многом выбор между «всё задокументировать» и «договориться устно, зафиксировать минимум».
Частые вопросы
User story или use case — что выбрать?
Берите user story для простых, понятных фич, которые команда легко обсудит устно — она фиксирует кому и зачем нужно, а детали уходят в критерии приёмки. Берите use case (или диаграмму сценария) для сложной логики с множеством веток и ошибок: оплата, бронирование, интеграции с внешними системами. Часто их сочетают: стори как шапка «зачем», use case под ней — «как именно». Критерии приёмки нужны в любом случае.
Как писать критерии приёмки?
Критерии приёмки — это проверяемые условия готовности задачи. Удобный формат — Gherkin: «Дано <контекст>, Когда <действие>, Тогда <ожидаемый результат>». Главное правило: они пишутся до начала разработки и обязательно покрывают не только успешный сценарий, но и ошибки и граничные случаи (неверный код, отсутствие email, лимит попыток). Если тестировщик не может написать по ним тест — критерии сформулированы плохо.
Чем user story отличается от use case?
User story — это короткая (одна-две строки) формулировка потребности «Как роль, я хочу цель, чтобы ценность»; она про «зачем» и служит поводом для разговора. Use case — это развёрнутый пошаговый сценарий взаимодействия актора с системой с основным ходом и всеми альтернативными ветками; он про «как именно». Story намеренно не содержит веток и ошибок — они выносятся в критерии приёмки или в use case.