User Stories

Как [роль пользователя],
я хочу [конкретное действие / функция],
чтобы [ценность / результат].

• Связь между бизнесом и разработкой
• Фокус на ценности, а не на технической реализации
• Упрощение коммуникации между заказчиком и командой
• Основа для планирования спринтов и оценки работы

• Пишутся от имени реального пользователя
• Фокусируются на ценности, а не на реализации
• Должны быть измеримыми и проверяемыми
• Являются основой для акцепт-критериев и тестов

💡 Помните: User story — это не требование, а напоминание для разговора. Подробности обсуждаются во время разработки.

• Хорошо: "Как пользователь, я хочу войти в систему, чтобы получить доступ к своим данным"
• Плохо: "Как разработчик, я хочу написать API для входа" (техническая задача, не пользовательская история)

• Роль должна быть реальным пользователем (не "админ", а "менеджер по продажам")
• Цель — конкретное действие
• Ценность — четкая польза для пользователя

• Не ценная для пользователя
• Не оцениваемая
• Не проверяемая
• Слишком большая

• Измеримые и тестируемые
• Написаны до начала разработки
• Согласованы с заказчиком
• Фокусируются на поведении системы

• Список условий: "Пользователь может...", "Система должна..."
• Given-When-Then (Gherkin): "Given пользователь на странице входа, When вводит корректный email и пароль, Then система перенаправляет на главную страницу"

• Пользователь может ввести email и пароль
• Система проверяет учетные данные
• При неверном пароле показывается сообщение об ошибке
• При успешном входе пользователь перенаправляется на главную страницу

• По функциональности (CRUD): Создание, Чтение, Обновление, Удаление
• По ролям пользователей: Админ, Пользователь, Гость
• По сценариям использования: Основной поток, Альтернативные потоки, Ошибки
• По техническим слоям: Frontend, Backend, Интеграции
• По приоритету: MVP сначала, затем дополнительные функции

• Как пользователь, я хочу просмотреть свои заказы
• Как пользователь, я хочу оформить новый заказ
• Как пользователь, я хочу отменить заказ
• Как админ, я хочу просмотреть все заказы
• Как админ, я хочу изменить статус заказа

Feature: Вход в систему
  Scenario: Успешный вход с корректными данными
    Given пользователь находится на странице входа
    When пользователь вводит корректный email и пароль
    Then система перенаправляет на главную страницу
    And показывается приветствие с именем пользователя

• Для автоматизации тестов
• Для документации требований
• Для улучшения коммуникации между заказчиком и командой
• В рамках BDD (Behavior-Driven Development)

• Истории без ценности для пользователя ("Как разработчик...")
• Слишком большие эпики вместо маленьких историй
• Отсутствие акцепт-критериев
• Технические задачи вместо пользовательских историй
• Истории с абстрактными ролями ("админ", "пользователь")

• Применять INVEST критерии
• Разбивать эпики на маленькие истории
• Совместная работа с заказчиком над акцепт-критериями
• Использовать вопросы для улучшения качества

• Фокус на пользовательском опыте и эмоциях
• Пример: "Как покупатель, я хочу быстро найти товар, чтобы сэкономить время"

• Фокус на бизнес-процессах и ROI
• Пример: "Как менеджер по продажам, я хочу импортировать клиентов из Excel, чтобы сократить время на ввод данных на 80%"

• Фокус на эффективности и интеграции
• Пример: "Как HR-специалист, я хочу автоматически генерировать отчеты по сотрудникам, чтобы сократить время подготовки отчетов с 4 часов до 15 минут"

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