User Story и Use Case: чем отличаются и что писать

На груминге команда читает историю: «Как покупатель, я хочу оплатить заказ картой, чтобы получить товар». Все кивают, оценка — пять очков, история уходит в спринт. Через две недели тестировщик спрашивает, что делать, если банк списал деньги, а магазин ответа не дождался. Ответа нет ни в истории, ни у кого в голове.

User story и use case отвечают на разные вопросы. История говорит, кому и зачем нужна возможность, и остаётся короткой: одна фраза плюс критерии приёмки, которые делают её проверяемой. Сценарий описывает, как система ведёт себя шаг за шагом, включая все ветки, где что-то идёт не по плану. Выбор между ними решает не методология команды, а число развилок в задаче: чем их больше и чем дороже ошибка в ветке, тем нужнее сценарий.

Сравнительных таблиц по этой теме много. Здесь другой ход: одно и то же требование к оплате заказа записано двумя способами, и видно, что теряет каждая запись.

Две записи — два разных вопроса

Формат истории «Как <роль>, я хочу <возможность>, чтобы <ценность>» придумала в 2001 году команда лондонской компании Connextra. Причина была практическая: истории писали продажи и маркетинг, записывали нужную функцию, а разработчикам потом приходилось искать автора, чтобы понять, для кого она и зачем. Шаблон заставил записывать «кто» и «зачем» сразу.

История намеренно неполна. Она — повод для разговора, а не спецификация. Проверяемой её делают критерии приёмки: условия, по которым команда и заказчик договариваются, что история сделана. Без них история остаётся пожеланием.

Use case старше. Ивар Якобсон представил его на конференции OOPSLA в 1987 году, а широко он разошёлся после книги 1992 года «Object-Oriented Software Engineering: A Use Case Driven Approach». Сценарий описывает актора, его цель и шаги взаимодействия с системой. Алистер Коберн в книге «Writing Effective Use Cases» разделил его на основной успешный сценарий и расширения — ветки, где что-то пошло иначе, — и советовал перебирать эти ветки исчерпывающе.

Обе записи могут нести требования разного уровня — от бизнес-цели до поведения экрана; как их различать, разобрано в статье чем бизнес-требования отличаются от функциональных. И ещё одна частая путаница: диаграмма вариантов использования в UML — не то же, что текстовый use case. На диаграмме видны акторы и цели, но не шаги; где она стоит среди других нотаций, — в статье BPMN и UML: чем отличаются.

А как сформулировать одно функциональное требование, чтобы его поняли одинаково, — в статье функциональные требования: как писать, пример и шаблон.

Одна задача: оплата заказа картой

Интернет-магазин, покупатель оформил заказ и платит картой через внешний платёжный шлюз. Задача выглядит простой, но развилок в ней много. Карта может быть отклонена. Банк может запросить подтверждение, а покупатель — его не пройти. Шлюз может не ответить вовсе. А может ответить позже, чем магазин перестал ждать, — и тогда деньги списаны, а заказ висит неоплаченным.

Запишем эту задачу дважды.

Запись первая: история с критериями приёмки

История. Как покупатель, я хочу оплатить заказ картой, чтобы получить товар и не оформлять заказ заново, если оплата не прошла с первого раза.

Вторая половина фразы появилась не сразу. Её дал вопрос «зачем»: покупатель хочет не просто заплатить, а не потерять собранную корзину. Это меняет поведение системы при отказе.

Критерии приёмки:

1. Дано: заказ оформлен, карта действительна. Когда покупатель подтверждает оплату, тогда заказ получает статус «Оплачен», а покупатель видит номер заказа.
2. Дано: банк отклонил карту. Когда покупатель возвращается к заказу, тогда корзина и данные доставки сохранены, и можно повторить оплату другой картой.
3. Дано: банк запросил подтверждение. Когда покупатель его не прошёл, тогда деньги не списаны, заказ остаётся неоплаченным и доступным для повторной оплаты.

История короткая, её легко оценить и обсудить с владельцем продукта. Ценность — не потерять заказ — видна в первой строке.

Запись вторая: сценарий с альтернативными потоками

Сценарий: Оплатить заказ картой. Актор: покупатель. Цель: заказ оплачен.

Основной поток:

1. Покупатель выбирает оплату картой.
2. Система передаёт сумму и номер заказа платёжному шлюзу.
3. Покупатель вводит данные карты на странице шлюза.
4. Шлюз подтверждает оплату.
5. Система меняет статус заказа на «Оплачен» и показывает покупателю номер заказа.

Альтернативные потоки:

• 4а. Карта отклонена. Система показывает причину отказа, заказ остаётся неоплаченным, покупатель может выбрать другую карту.
• 4б. Подтверждение не пройдено. Система не меняет статус заказа и предлагает повторить оплату.
• 4в. Шлюз не ответил за отведённое время. Система не отменяет заказ, а помечает его «Ожидает подтверждения оплаты» и запрашивает статус платежа у шлюза повторно.
• 4г. Шлюз подтвердил оплату после тайм-аута. Система по уведомлению шлюза переводит заказ в «Оплачен». Если заказ к этому моменту уже отменён — система запускает возврат денег.
• 4д. Уведомление об оплате пришло дважды. Система обрабатывает его один раз и не создаёт второй платёж.

Что потеряла каждая запись

История потеряла ветки 4в, 4г и 4д. Это ровно те, где деньги и статус заказа расходятся: покупатель заплатил, а магазин этого не знает. Их не видно из фразы «хочу оплатить заказ картой», и они не приходят в голову на груминге. Всплывают они на тестировании или в проде — в виде письма от покупателя, у которого списали деньги дважды или не отдали заказ.

Критерии приёмки можно дописать, и хорошая команда их допишет. Но формат истории не заставляет искать ветки. Он заставляет ответить «зачем», а перебор отказов оставляет на усмотрение того, кто пишет.

Сценарий потерял «зачем». В нём есть шаги и отказы, но нет строки, из которой следует, что корзину нужно сохранить. Без вопроса о ценности в ветке 4а легко написать «заказ отменяется» — формально корректно, а покупатель собирает корзину заново и уходит. Сценарий отвечает, как система себя ведёт, но не проверяет, нужно ли пользователю именно такое поведение.

История защищает от того, чтобы построить не то. Сценарий — от того, чтобы построить то, но с дырой в ветке, где пропадают деньги.

Что писать в своей задаче

Начните с подсчёта развилок. Один путь, две-три очевидные проверки — история с критериями приёмки закрывает задачу целиком, сценарий будет бюрократией. Много веток, и каждая ведёт к разному состоянию денег, данных или обязательств перед клиентом — нужен сценарий хотя бы для этой части.

Чаще всего работают обе записи сразу. История заводит задачу в бэклог и держит разговор о ценности с бизнесом. Для рискованной части — оплата, возвраты, интеграции с внешними системами — к ней прикладывают сценарий с альтернативными потоками, и критерии приёмки ссылаются на его ветки. Так оценка и тестирование опираются на один перебор, а не на то, что каждый вообразил сам.

Команда работает по Scrum — это не запрет на сценарии. Команда пишет ТЗ — не запрет на истории. Форма записи выбирается под задачу, а не под процесс.

Как это звучит на собеседовании

В нашем банке вопросов с реальных собеседований эта тема встречается 26 раз, и 16 из этих вопросов размечены как junior. Это больше половины: разницу между историей и сценарием спрашивают на входе в профессию.

Слабый ответ — пересказ определений: «user story — короткая, из Agile, use case — длинный и подробный». Верно, но это пересказ учебника, а не понимание. Сильный ответ показывает, что вы видите, что теряет каждая запись. История держит ценность, но пропускает ветки. Сценарий перебирает ветки, но не спрашивает «зачем». Дальше — как вы выбираете: по числу развилок и цене ошибки в них. Если есть пример из практики, где ветка всплыла поздно, — это лучший аргумент.