INVEST – это критерии качества User Story
Введение
Пользовательские истории — основной способ описания требований в Agile-разработке. Однако даже при использовании стандартной формулы «Я, как <роль>, хочу <функция>, чтобы <ценность>» история может оказаться расплывчатой, нереализуемой или бесполезной.
Чтобы избежать таких ситуаций, Билл Уэйк в статье «INVEST in Good Stories, and SMART Tasks» предложил критерии INVEST — шесть характеристик, которым должна соответствовать качественная пользовательская история. Эти принципы помогают командам создавать задачи, которые легко обсуждать, оценивать, реализовывать и проверять.
Что такое INVEST?
INVEST — это мнемоника, где каждая буква обозначает важное свойство:
Рассмотрим каждый критерий с примерами.
I — Independent (Независимая)
Хорошая история не должна зависеть от других, чтобы её можно было реализовать в любом порядке без блокировок.
Пример зависимости:
«Я, как пользователь мобильного приложения, хочу видеть рекомендации на основе моей истории просмотров, чтобы находить интересный контент быстрее».
На первый взгляд — полезная функция. Но на практике она требует:
Если хотя бы один из этих компонентов отсутствует, история не может быть реализована автономно.
Как сделать её независимой:
Разбить на более мелкие истории:
Теперь каждая история может быть реализована независимо при наличии базовых функций.
N — Negotiable (Обсуждаемая)
История — не техническое ТЗ, а отправная точка для диалога. Она должна оставлять пространство для уточнений и компромиссов.
Слишком общая формулировка:
«Я, как администратор сайта, хочу улучшить безопасность, чтобы снизить риск утечки персональных данных».
Это не история — это пожелание. Что именно улучшать? Авторизацию? Защиту от ботов? Шифрование?
После обсуждения:
«Я, как администратор, хочу, чтобы после трёх неудачных попыток входа аккаунт блокировался на 15 минут, чтобы снизить риск брутфорса».
Теперь команда может обсудить:
Именно такой диалог делает историю гибкой и реализуемой.
V — Valuable (Ценная)
Каждая история должна приносить ощутимую выгоду — пользователю, бизнесу или команде.
Пример без явной ценности:
«Я, как разработчик, хочу обновить версию библиотеки React».
Само по себе обновление — техническая задача. Чтобы история стала ценной, нужно связать её с бизнес-эффектом:
«Я, как пользователь, хочу, чтобы интерфейс загружался на 30% быстрее, чтобы сократить время ожидания при открытии приложения».
Обновление React здесь — средство достижения цели, а не цель сама по себе. Такая формулировка объясняет зачем это нужно и помогает приоритизировать задачу.
E — Estimable (Оцениваемая)
Если команда не может оценить сложность задачи, значит, она недостаточно понятна.
Неоцениваемая история:
«Я, как владелец интернет-магазина, хочу улучшить поиск».
Что именно улучшить? Скорость? Релевантность? Подсказки? Без уточнений разработчики не могут дать оценку.
Уточнённая версия:
«Я, как покупатель, хочу, чтобы при вводе “кофе” в поиске отображались товары с названием или описанием, содержащим это слово, даже если написано с опечаткой, чтобы сэкономить время на исправлении опечаток».
Теперь команда понимает: нужна интеграция с движком нечёткого поиска (например, Elasticsearch), и может оценить трудозатраты.
S — Small (Компактная)
История должна быть достаточно маленькой, чтобы её можно было завершить за один спринт (обычно 2-4 недели).
Слишком большая история:
«Я, как клиент банка, хочу полнофункциональное мобильное приложение для управления счётом, чтобы не заходить в интернет-банк».
Это эпик, а не история. Его нужно разбить:
Каждая из этих историй — компактная, завершённая и приносящая ценность.
T — Testable (Тестируемая)
Без чётких критериев приёмки невозможно понять, выполнена ли задача.
Пример с критериями приёмки:
История:
«Я, как пользователь, хочу получать уведомление, если остаток на счёте падает ниже 1000 рублей».
Критерии приёмки:
Эти условия можно проверить как вручную, так и автоматизированными тестами.
Даже нефункциональные требования (например, «уведомление должно приходить в течение 5 минут после изменения баланса») должны быть сформулированы так, чтобы их можно было протестировать.
Заключение
INVEST — не догма, а практический инструмент для повышения качества пользовательских историй. Применяя эти критерии, команда:
Помните: хорошая история — это не просто описание функции, а инструмент для совместного поиска решения, которое действительно работает на бизнес.
Введение
Пользовательские истории — основной способ описания требований в Agile-разработке. Однако даже при использовании стандартной формулы «Я, как <роль>, хочу <функция>, чтобы <ценность>» история может оказаться расплывчатой, нереализуемой или бесполезной.
Чтобы избежать таких ситуаций, Билл Уэйк в статье «INVEST in Good Stories, and SMART Tasks» предложил критерии INVEST — шесть характеристик, которым должна соответствовать качественная пользовательская история. Эти принципы помогают командам создавать задачи, которые легко обсуждать, оценивать, реализовывать и проверять.
Что такое INVEST?
INVEST — это мнемоника, где каждая буква обозначает важное свойство:
- I — Independent (Независимая)
- N — Negotiable (Обсуждаемая)
- V — Valuable (Ценная)
- E — Estimable (Оцениваемая)
- S — Small (Компактная)
- T — Testable (Тестируемая)
Рассмотрим каждый критерий с примерами.
I — Independent (Независимая)
Хорошая история не должна зависеть от других, чтобы её можно было реализовать в любом порядке без блокировок.
Пример зависимости:
«Я, как пользователь мобильного приложения, хочу видеть рекомендации на основе моей истории просмотров, чтобы находить интересный контент быстрее».
На первый взгляд — полезная функция. Но на практике она требует:
- Сбора и хранения истории просмотров;
- Наличия алгоритма рекомендаций;
Если хотя бы один из этих компонентов отсутствует, история не может быть реализована автономно.
Как сделать её независимой:
Разбить на более мелкие истории:
- «Я, как пользователь, хочу, чтобы приложение сохраняло историю моих просмотров, для того чтобы анализировать их в дальнейшем»
- «Я, как пользователь, хочу видеть рекомендации на основе последних 5 просмотренных фильмов, чтобы быстрее выбирать фильм который мне понравится»
Теперь каждая история может быть реализована независимо при наличии базовых функций.
N — Negotiable (Обсуждаемая)
История — не техническое ТЗ, а отправная точка для диалога. Она должна оставлять пространство для уточнений и компромиссов.
Слишком общая формулировка:
«Я, как администратор сайта, хочу улучшить безопасность, чтобы снизить риск утечки персональных данных».
Это не история — это пожелание. Что именно улучшать? Авторизацию? Защиту от ботов? Шифрование?
После обсуждения:
«Я, как администратор, хочу, чтобы после трёх неудачных попыток входа аккаунт блокировался на 15 минут, чтобы снизить риск брутфорса».
Теперь команда может обсудить:
- Длительность блокировки;
- Уведомлять ли пользователя;
- Вести ли лог таких попыток;
- Как это повлияет на UX.
Именно такой диалог делает историю гибкой и реализуемой.
V — Valuable (Ценная)
Каждая история должна приносить ощутимую выгоду — пользователю, бизнесу или команде.
Пример без явной ценности:
«Я, как разработчик, хочу обновить версию библиотеки React».
Само по себе обновление — техническая задача. Чтобы история стала ценной, нужно связать её с бизнес-эффектом:
«Я, как пользователь, хочу, чтобы интерфейс загружался на 30% быстрее, чтобы сократить время ожидания при открытии приложения».
Обновление React здесь — средство достижения цели, а не цель сама по себе. Такая формулировка объясняет зачем это нужно и помогает приоритизировать задачу.
E — Estimable (Оцениваемая)
Если команда не может оценить сложность задачи, значит, она недостаточно понятна.
Неоцениваемая история:
«Я, как владелец интернет-магазина, хочу улучшить поиск».
Что именно улучшить? Скорость? Релевантность? Подсказки? Без уточнений разработчики не могут дать оценку.
Уточнённая версия:
«Я, как покупатель, хочу, чтобы при вводе “кофе” в поиске отображались товары с названием или описанием, содержащим это слово, даже если написано с опечаткой, чтобы сэкономить время на исправлении опечаток».
Теперь команда понимает: нужна интеграция с движком нечёткого поиска (например, Elasticsearch), и может оценить трудозатраты.
S — Small (Компактная)
История должна быть достаточно маленькой, чтобы её можно было завершить за один спринт (обычно 2-4 недели).
Слишком большая история:
«Я, как клиент банка, хочу полнофункциональное мобильное приложение для управления счётом, чтобы не заходить в интернет-банк».
Это эпик, а не история. Его нужно разбить:
- «Я, как клиент, хочу видеть баланс своего счёта на главном экране»
- «Я, как клиент, хочу переводить деньги по номеру телефона»
- «Я, как клиент, хочу получать push-уведомления о поступлениях»
Каждая из этих историй — компактная, завершённая и приносящая ценность.
T — Testable (Тестируемая)
Без чётких критериев приёмки невозможно понять, выполнена ли задача.
Пример с критериями приёмки:
История:
«Я, как пользователь, хочу получать уведомление, если остаток на счёте падает ниже 1000 рублей».
Критерии приёмки:
- Уведомление приходит в тот же день, когда баланс становится < 1000 ₽;
- Уведомление отображается в мобильном приложении и дублируется по email;
- Пользователь может отключить такое уведомление в настройках;
- Уведомление не отправляется чаще одного раза в сутки.
Эти условия можно проверить как вручную, так и автоматизированными тестами.
Даже нефункциональные требования (например, «уведомление должно приходить в течение 5 минут после изменения баланса») должны быть сформулированы так, чтобы их можно было протестировать.
Заключение
INVEST — не догма, а практический инструмент для повышения качества пользовательских историй. Применяя эти критерии, команда:
- Снижает риски недопонимания;
- Упрощает планирование и оценку;
- Обеспечивает прозрачность и фокус на ценности;
- Ускоряет доставку рабочего продукта.
Помните: хорошая история — это не просто описание функции, а инструмент для совместного поиска решения, которое действительно работает на бизнес.