User Story: от потребности к критериям приёмки

User Story кажется базовым инструментом, но команды нередко используют её как короткое техническое задание и теряют главное — потребность пользователя. Разберём, что должна фиксировать история, зачем ей критерии приёмки и где чаще всего возникают ошибки.

User story — что это на самом деле

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

Полезная опора — три C Рона Джеффриса: Card, Conversation, Confirmation — карточка, обсуждение и проверка результата. Короткая запись задаёт контекст для разговора, а не заменяет спецификацию. Детали реализации команда определяет отдельно. Если же сама потребность сформулирована неточно, обсуждение с самого начала пойдёт не туда.

Шаблон сам по себе прост, но его ценность появляется только при общем понимании. Полезно проверить, одинаково ли команда трактует роль пользователя, ожидаемый результат и границы истории.

Как это выглядит

Один из распространённых шаблонов — Connextra. Это подсказка для разговора, а не обязательный синтаксис:

• Как <тип пользователя>, я хочу <действие>, чтобы <цель или причина>.

Несколько примеров, чтобы поймать ритм:

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

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

Три вопроса, которые всё решают

Популярный шаблон держится на трёх вопросах: кто, что, зачем.

Кто — «Как [тип пользователя]». Не стоит писать абстрактное «как пользователь» для каждой задачи. Администратор, покупатель, гость и контент-менеджер работают в разных контекстах и имеют разные права и цели.

Что — «я хочу [действие]». Если в одной истории перечислено несколько самостоятельных результатов, её, скорее всего, стоит разделить.

Зачем — «чтобы [цель или причина]». Эта часть объясняет ценность и помогает обсуждать альтернативы. Например: «Как студент, я хочу видеть свои оценки онлайн, чтобы отслеживать успеваемость». Если цель не зафиксирована, команда может реализовать запрос буквально и не решить исходную задачу.

Критерии приёмки — то, без чего история не работает

Сама по себе user story — повод для разговора, а не полная спецификация. Чтобы команда одинаково понимала результат, нужны критерии приёмки: проверяемые условия, при которых история считается выполненной.

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

Возможные критерии приёмки:

• Авторизованный пользователь может добавить доступный товар в избранное из карточки товара.
• Добавленный товар появляется в списке избранного и остаётся там после обновления страницы.
• Пользователь может удалить товар из избранного; после удаления товар исчезает из списка.

Конкретный набор зависит от продуктовых правил, но уже эти пункты уточняют контекст, действие и наблюдаемый результат. Они уменьшают пространство для разных трактовок у заказчика, аналитика, разработчика и QA.

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

Зачем всё это вообще нужно

У user story есть три практических преимущества.

Фокус на пользователе. Связка «кто — что — зачем» возвращает обсуждение от элемента интерфейса к задаче человека.

Упрощение планирования. Если истории нарезаны на небольшие вертикальные результаты, их проще оценивать, приоритизировать и поставлять независимо. Сам шаблон не гарантирует хорошую декомпозицию, но поддерживает её.

Коммуникация. Аналитик, разработчик, QA и заказчик обсуждают одну потребность и одни критерии приёмки. Это снижает риск разных ожиданий.

Частые грабли (из практики)

Раз уж база разобрана, вот на чём спотыкаются чаще всего.

Пишут историю как техническое задание. «Как пользователь, я хочу, чтобы система отправляла POST-запрос на /auth с JWT-токеном» описывает реализацию, а не потребность. Пользователю важно войти в аккаунт; протокол и механизм аутентификации относятся к техническому решению.

Забывают «зачем». Фраза «как пользователь, я хочу кнопку экспорта» не объясняет задачу. От ответа зависит формат, состав данных, права доступа и весь сценарий: отчёт для бухгалтера и резервная копия перед миграцией требуют разных решений.

Раздувают одну историю до эпика. Несколько независимых действий и результатов в одной формулировке — сигнал проверить декомпозицию. Небольшую историю проще оценить, проверить и довести до пользователя.

Пишут непроверяемые критерии. «Система должна работать быстро» — пожелание. «Список избранного загружается не более чем за две секунды в согласованном тестовом профиле» — проверяемое условие. Число и профиль нагрузки должны быть обоснованы контекстом продукта.

История должна приводить к проверяемому результату

User story полезна как компактная рамка для разговора о потребности пользователя. Формула «кто — что — зачем» и проверяемые критерии приёмки не заменяют анализ, но помогают команде согласовать ожидаемый результат до реализации.

---

Впервые опубликовано в моём Telegram-канале @it_underside.

Ваш ДПУПП