Что такое INVEST?

INVEST: критерии качественной user story

INVEST — это мнемоника для оценки качества user story в Agile разработке. Предложена Билл Уэйком (Bill Wake) в 2003 году. Каждая буква обозначает критерий, которому должна соответствовать хорошая история.

Расшифровка

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

У story не должно быть зависимостей от других stories. Она должна быть разработана в любом порядке без блокировок.

Плохо:

Story A: Пользователь может войти
Story B: Пользователь видит профиль (зависит от А)

Хорошо:

Структурировать так, чтобы каждую можно было сделать отдельно,
или явно указать зависимости и спланировать вместе в одном спринте

N — Negotiable (Договорная)

Детали story НЕ высечены в камне. Это не контракт, а основа для переговоров между Team и Product Owner.

❌ Плохо (контракт, 100% определено):
"Кнопка должна быть красной (RGB: 255, 0, 0), 20px, с шрифтом Arial 14pt"

✅ Хорошо (договорная основа):
"Кнопка Submit должна быть заметной и соответствовать дизайн-системе"
// детали обсуждаются во время встреч

Основная информация идёт в story, детали уточняются в обсуждениях.

V — Valuable (Ценная для бизнеса)

Story должна приносить ценность. Это должен быть полноценный increment, который может быть доставлен пользователю, а не технический долг или refactoring.

Плохо:

Story: "Обновить версию jQuery с 2.1 на 3.0"
// Это техдолг, не ценность

Хорошо:

Story: "Как пользователь, я хочу быстрее загружаться страница профиля,
чтобы не жать 5 секунд"
// Обновление jQuery — это реализация, не story

Стory должна начинаться с "Как [актор], я хочу [действие], чтобы [ценность]".

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

Team должна иметь возможность оценить объём работы (в story points или часах). Если story слишком неясна для оценки — она не готова к спринту.

❌ Неоценяемая:
"Улучшить перформанс системы"
// Слишком неопределённо

✅ Оценяемая:
"Оптимизировать queries в поиске, чтобы результаты появлялись за <1 сек"
// Есть критерий приёма, можно оценить

Если story не оценяется — нужна research spike (техническое исследование).

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

Story должна быть завершена за 1-5 дней работы. Если story занимает 2+ недели, она слишком большая.

❌ Большая epic:
"Переписать систему рекомендаций"

✅ Маленькие stories:
1. "Загрузить ML модель в production"
2. "Интегрировать scoring API"
3. "Отобразить рекомендации в UI"

Большие истории называют epics, их нужно разбить на stories.

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

Для story должны быть ясные критерии приёма (acceptance criteria), по которым можно проверить, что она выполнена.

❌ Нетестируемая:
"Пользователь может отправить сообщение"
// Как проверить, что это работает?

✅ Тестируемая:
"Пользователь может отправить сообщение
AC1: Сообщение отправляется при клике на кнопку Send
AC2: Сообщение сохраняется в БД
AC3: Пользователь видит подтверждение ("Sent")
AC4: Сообщение отправляется за <500ms"

Пример хорошей user story

## Story: Восстановление пароля по email

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

### Acceptance Criteria
- [ ] На странице логина есть ссылка "Forgot Password"
- [ ] Ввод email показывает валидацию (real-time)
- [ ] После отправки показывается сообщение "Check your email"
- [ ] Email приходит за <1 минуту
- [ ] Ссылка в email работает 24 часа
- [ ] После клика на ссылку показывается форма установки нового пароля
- [ ] Пароль валидируется (8+ chars, буквы + цифры)
- [ ] После установки пароля пользователь перенаправляется на логин

### Notes
- Использовать SendGrid для email
- JWT token в ссылке, не DB токены
- Email шаблон согласовать с дизайнером

### Estimate
- 5 story points (3-5 дней)

### Tasks
- [ ] Backend: API endpoint для password reset request
- [ ] Backend: Email sending logic
- [ ] Backend: Token validation
- [ ] Frontend: UI компоненты
- [ ] Testing: E2E тесты

Как использовать INVEST в практике

При планировании спринта:

1. Перед спринтом проверить каждую story по INVEST
2. Если story не соответствует — вернуть в Product Backlog на уточнение
3. Только готовые stories попадают в Sprint Backlog

Частые проблемы:

Отличие от других подходов

INVEST vs Traditional Requirements

• INVEST: гибкие, пересматриваются каждый спринт
• Traditional: жёсткие спецификации, контрактные

INVEST vs Epic

• INVEST story: 1-5 дней
• Epic: несколько спринтов, разбивается на stories

Заключение

INVEST — это не правила, а руководящие принципы. Цель — иметь stories, которые:

• Понятны всем (разработчикам, QA, PO)
• Выполняемы в пределах одного спринта
• Приносят ценность пользователю
• Могут быть протестированы