Что такое критерии приёмки INVEST для User Story?

INVEST критерии для User Stories

Что такое INVEST

INVEST — это аббревиатура для критериев оценки качества User Stories в Agile разработке. Была предложена Биллом Вейком в 2003 году.

User Story, которая соответствует INVEST критериям, имеет больше шансов на успешную реализацию за один спринт и не будет оставить технический долг.

Расшифровка INVEST

I — Independent (Независимая)

• История должна быть максимально независима от других
• Разработчики должны уметь выбрать её в любом порядке
• Минимум зависимостей между историями

Примеры:

❌ Плохо (зависимая):
  "Как пользователь, я хочу отредактировать профиль
   (требует завершение истории регистрации)"

✅ Хорошо (независимая):
  "Как пользователь, я хочу изменить своё имя
   (работает для уже зарегистрированного пользователя)"

N — Negotiable (Переговариваемая)

• История не должна быть жёсткой спецификацией
• Детали могут быть обсуждены между team и заказчиком
• Оставляет место для диалога

Примеры:

❌ Плохо (жёсткая спецификация):
  "Реализовать кнопку авторизации с цветом #FF5733,
   шрифт Arial 14px, тень 2px 2px 4px rgba(0,0,0,0.2)"

✅ Хорошо (переговариваемая):
  "Как пользователь, я хочу авторизоваться через email и пароль,
   чтобы получить доступ к своему аккаунту.
   
   Дизайн кнопки обсудим с командой дизайна."

V — Valuable (Ценная)

• История должна приносить ценность пользователю или бизнесу
• Не писать истории для разработчиков ("рефакторинг", "оптимизация")
• Ценность должна быть понятна заказчику

Примеры:

❌ Плохо (для разработчиков, без пользовательской ценности):
  "Переписать модуль кэширования на Redis"

✅ Хорошо (приносит ценность пользователю):
  "Как пользователь, я хочу видеть результаты поиска
   за менее чем 1 секунду, чтобы быстро находить товары."
   
✅ Хорошо (техническая история, но с пользовательской ценностью):
  "Как пользователь, я хочу быстрый поиск товаров
   (улучшить производительность поиска через кэширование)"

E — Estimable (Оценяемая)

• Team должна уметь оценить объём работы
• Достаточно информации для прогноза сроков
• Если не можем оценить → нужна дополнительная информация

Примеры:

❌ Плохо (невозможно оценить):
  "Как пользователь, я хочу лучший UI"
  (слишком расплывчато)

✅ Хорошо (оценяемая):
  "Как пользователь, я хочу видеть список своих покупок
   с сортировкой по дате, сумме и статусу."
   (разработчик может оценить: 5-8 story points)

S — Small (Маленькая)

• История должна быть завершена за 1-5 дней
• Идеально 2-3 дня
• Если оценивается дольше → разбить на меньшие истории

Примеры:

❌ Плохо (очень большая Epic):
  "Разработать платёжную систему"
  (это не история, это эпик на месяцы)

✅ Хорошо (история на спринт):
  "Как покупатель, я хочу выбрать способ оплаты,
   чтобы выбрать карту или кошелёк" (2-3 дня)

✅ Хорошо (история на спринт):
  "Как разработчик, я интегрирую API Stripe,
   чтобы получить карты платёжной системы" (3-4 дня)

T — Testable (Тестируемая)

• History должна иметь чёткие критерии приёмки
• Должна быть возможность проверить, выполнена ли она
• Критерии не должны быть субъективными

Примеры:

❌ Плохо (нетестируемая):
  "Как пользователь, я хочу красивый интерфейс"
  ("красивый" — субъективно)

✅ Хорошо (тестируемая):
  "Как пользователь, я хочу видеть ошибку валидации,
   если ввожу неправильный email формат.
   
   Критерии приёмки:
   - При вводе "invalid" появляется сообщение ошибки
   - При вводе "test@example.com" ошибки нет
   - Сообщение исчезает при исправлении email"

Формат User Story

Общий формат:

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

Реальный пример:

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

Критерии приёмки:
☐ Список отображает товары с запасом < 10 единиц
☐ Список отсортирован по возрастанию запаса
☐ Пагинация по 20 товаров на странице
☐ Есть фильтр по категориям
☐ При клике на товар открывается детальная страница

Частые ошибки при написании User Stories

1. Too big (слишком большая)

❌ "Разработать админ-панель"
✅ "Добавить возможность редактирования в админ-панель"

2. Too technical (слишком техническая)

❌ "Переключиться с использования useState на useReducer для управления состоянием"
✅ "Как пользователь, я хочу чтобы форма сохраняла мой прогресс при перезагрузке страницы"

3. Unclear acceptance criteria (непонятные критерии приёмки)

❌ Критерии: "Код работает корректно"
✅ Критерии:
   - При отправке формы без email: показывается ошибка
   - При отправке с невалидным email: показывается ошибка
   - При отправке с валидным email: сообщение об успехе

4. Dependencies (зависимости между историями)

❌ История 1: "Создать БД таблицу users"
   История 2: "Создать API endpoint для получения пользователя" (зависит от 1)
   
✅ История: "Как админ, я хочу видеть список пользователей в системе"
   (команда разработки сама решит, что нужно сделать)

Пример Good vs Bad User Story

BAD:

Разработать форму регистрации

GOOD:

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

Критерии приёмки:
☐ Форма содержит поля: Email, Пароль, Подтверждение пароля, Имя
☐ Email валидируется по RFC 5322
☐ Пароль должен быть минимум 8 символов
☐ При регистрации создаётся запись в БД
☐ После регистрации пользователь автоматически логинится
☐ Ошибки отображаются под полями
☐ При отправке формы кнопка становится disabled

Дополнительно:
- Design: согласовать с UI/UX team
- API endpoint: POST /api/v1/auth/register

Как проверить, соответствует ли история INVEST

Проверка перед планированием спринта:

Если хотя бы один ответ "Нет" → нужна доработка истории.

Заключение

INVEST критерии — это чеклист качества user stories, который помогает:

• Избежать больших историй
• Свести к минимуму зависимости
• Упростить планирование спринтов
• Убедиться, что история тестируемая

Добрая user story — это основа успешного спринта.