Критерии INVEST, критерии приемки, Gherkin
Время освоения: ~40 минут
Цель: Научиться писать качественные пользовательские истории, разбивать эпики и использовать их для эффективной разработки
Как [роль пользователя],
я хочу [конкретное действие / функция],
чтобы [ценность / результат].
| Буква | Критерий | Что проверить |
|---|---|---|
| I | Independent (Независимая) | Можно взять в спринт без других историй? |
| N | Negotiable (Переговариваемая) | Детали обсуждаемы, не высечены в камне? |
| V | Valuable (Ценная) | Даёт ценность реальному пользователю? |
| E | Estimable (Оцениваемая) | Команда может оценить сложность? |
| S | Small (Маленькая) | Умещается в один спринт? |
| T | Testable (Проверяемая) | Есть чёткие критерии приёмки? |
| Формат | Пример |
|---|---|
| Список условий | Пользователь может войти с email и паролем |
| Gherkin (BDD) | Given / When / Then |
Given пользователь на странице входа
When вводит корректный email и пароль
Then система перенаправляет на главную| Метод | Применение |
|---|---|
| По CRUD | Создание / Чтение / Обновление / Удаление |
| По ролям | Пользователь / Админ / Гость |
| По сценариям | Основной поток → Альтернативы → Ошибки |
| По приоритету | MVP сначала, остальное потом |
| Плохая | Проблема | Хорошая |
|---|---|---|
| "Как разработчик, хочу написать API" | Нет ценности для пользователя | "Как покупатель, хочу войти в систему, чтобы видеть свои заказы" |
| "Как пользователь, хочу базу данных" | Техническая, не оцениваемая | "Как менеджер, хочу экспортировать отчёт в Excel" |
Пользовательские истории (User Stories) — это краткие описания функциональности с точки зрения пользователя, которые помогают команде фокусироваться на ценности для конечного пользователя.
Зачем нужны user stories:
Основные принципы:
💡 Помните: User story — это не требование, а напоминание для разговора. Подробности обсуждаются во время разработки.
Формула: "Как [роль], я хочу [цель], чтобы [ценность]"
Примеры:
Ключевые требования:
I - Independent (Независимая): Минимальные зависимости между историями
N - Negotiable (Переговариваемая): Детали обсуждаются, а не задаются жестко
V - Valuable (Ценная): Приносит ценность конечному пользователю
E - Estimable (Оцениваемая): Можно оценить сложность
S - Small (Маленькая): Помещается в один спринт
T - Testable (Проверяемая): Имеет четкие критерии приемки
Пример плохой истории: "Как пользователь, я хочу базу данных"
Пример хорошей истории: "Как покупатель, я хочу найти товар по названию, чтобы быстро найти нужный продукт"
Что это: Конкретные условия, которые должны быть выполнены для того, чтобы история считалась завершенной.
Как писать:
Форматы:
Пример для истории "Как пользователь, я хочу войти в систему":
Эпик — крупная функциональность, которую нельзя реализовать за один спринт.
Методы разбиения:
Пример: Эпик "Управление заказами"
Gherkin — формат описания сценариев тестирования в виде Given-When-Then.
Пример:
Feature: Вход в систему
Scenario: Успешный вход с корректными данными
Given пользователь находится на странице входа
When пользователь вводит корректный email и пароль
Then система перенаправляет на главную страницу
And показывается приветствие с именем пользователя
Как используется:
Основные анти-паттерны:
Решения:
B2C (потребительские продукты):
B2B (бизнес-решения):
Внутренние системы:
| Ошибка | Почему это плохо | Как исправить |
|---|---|---|
| История от имени разработчика: «Как разработчик, хочу написать API...» | Нет ценности для пользователя, нельзя приоритизировать относительно бизнес-целей | Роль = реальный пользователь, ценность = бизнес-результат |
| Нет Acceptance Criteria | Команда угадывает, что значит «готово», PO переделывает работу | AC пишутся до разработки, согласовываются с PO на Refinement |
| Acceptance Criteria пишут после разработки | Разработчик сделал «как понял», AC подгоняют под результат | AC = контракт, подписанный до начала работы |
| Эпик берут в спринт без разбивки | Эпик не завершается, velocity = 0, Sprint Goal не достигнута | Любая история > 8 SP должна быть разбита на меньшие |
| Абстрактная роль «пользователь» без конкретики | Нет контекста, непонятно что важно для этого типа пользователя | «Менеджер по продажам», «новый покупатель», «admin корпоративного аккаунта» |
| История описывает решение, а не потребность | Команда реализует конкретное решение, упуская лучшие варианты | Описывать «зачем», а не «как»: что хочет достичь пользователь |
Оцените следующие истории по INVEST критериям:
Что можно улучшить?
Эпик: "Управление профилем пользователя" Разбейте его на 5-7 маленьких user stories с акцепт-критериями.
Качественные пользовательские истории — основа успешной Agile-разработки.
Ключевые выводы:
🎯 Следующий шаг: Выберите одну текущую задачу и перепишите ее как user story с акцепт-критериями.
Время освоения: 40 минут
Уровень: Средний
Для кого: Product Owners, Business Analysts, Scrum Masters, разработчики, менеджеры проектов
Вопросы ещё не добавлены
Вопросы для этой подтемы ещё не добавлены.