Введение
User Story (пользовательская история) — это краткое, неформальное описание одной или нескольких функций программного обеспечения с точки зрения конечного пользователя. Это не подробное техническое задание, а скорее напоминание о необходимости обсудить требования. Чтобы User Story были эффективными, они должны соответствовать определенным критериям. В этом помогает акроним INVEST, предложенный Биллом Уэйком.
INVEST — это набор из шести критериев, которые помогают оценить качество пользовательской истории. Каждая буква в акрониме представляет один из критериев: Independent (Независимая), Negotiable (Обсуждаемая), Valuable (Ценная), Estimable (Оцениваемая), Small (Маленькая) и Testable (Тестируемая). Использование этих критериев помогает командам создавать качественные User Stories, которые способствуют гибкой и эффективной разработке.
Основные концепции
Independent (Независимая)
Пользовательские истории должны быть независимыми друг от друга. Это означает, что их можно разрабатывать в любом порядке, и зависимость одной истории от другой должна быть минимальной. Независимость историй дает гибкость в планировании и позволяет команде поставлять ценность инкрементально. Если истории сильно связаны, это может привести к задержкам и усложнить планирование.
Negotiable (Обсуждаемая)
User Story — это не контракт, а отправная точка для обсуждения. Детали реализации должны обсуждаться командой совместно с владельцем продукта. История должна оставлять пространство для диалога и совместного принятия решений о том, как лучше реализовать ту или иную функциональность. Это способствует лучшему пониманию требований и поиску оптимальных решений.
Valuable (Ценная)
Каждая User Story должна приносить ценность для конечного пользователя или заказчика. Если история не несет в себе ценности, ее не стоит реализовывать. Ценность может быть разной: улучшение пользовательского опыта, автоматизация рутинных задач, добавление новой функциональности, которая решает проблему пользователя. Важно, чтобы команда понимала, какую пользу принесет реализация истории.
Estimable (Оцениваемая)
Команда разработки должна иметь возможность оценить трудозатраты на реализацию User Story. Если историю невозможно оценить, это может быть признаком того, что она недостаточно понятна или слишком велика. Оценка помогает в планировании спринтов и прогнозировании сроков выполнения работ. Для оценки могут использоваться различные техники, такие как Story Points или идеальные человеко-дни.
Small (Маленькая)
Пользовательские истории должны быть достаточно маленькими, чтобы их можно было завершить за один спринт (итерацию). Большие истории (эпики) следует разбивать на более мелкие, управляемые части. Маленькие истории легче оценивать, планировать и тестировать. Это также позволяет команде чаще поставлять готовую функциональность и получать обратную связь.
Testable (Тестируемая)
У каждой User Story должны быть четкие критерии приемки (Acceptance Criteria), которые позволяют проверить, что история реализована корректно. Тестируемость гарантирует, что команда и владелец продукта имеют общее понимание того, что значит «готово». Критерии приемки должны быть конкретными, измеримыми и понятными для всех участников процесса.
Практические примеры
Пример 1: Хорошая User Story
User Story:
Как пользователь интернет-магазина, я хочу иметь возможность добавлять товары в корзину, чтобы совершать покупки.
Анализ по INVEST:
- -Independent:** Да, добавление в корзину — это базовая, независимая функция.
- -Negotiable:** Да, можно обсуждать детали: как будет выглядеть кнопка, будет ли анимация, что произойдет после добавления.
- -Valuable:** Да, без этой функции невозможно совершать покупки.
- -Estimable:** Да, команда может оценить сложность реализации.
- -Small:** Да, эту историю можно реализовать за один спринт.
- -Testable:** Да, можно определить четкие критерии приемки. Например:
- При нажатии на кнопку «Добавить в корзину» товар появляется в корзине.
- Иконка корзины в шапке сайта обновляется, показывая количество товаров.
Пример 2: Плохая User Story
User Story:
Как администратор, я хочу управлять пользователями.
Анализ по INVEST:
- -Independent:** Нет, эта история слишком большая и включает в себя множество зависимых функций (создание, редактирование, удаление, блокировка пользователей).
- -Negotiable:** Нет, слишком общее описание, неясно, что обсуждать.
- -Valuable:** Да, но ценность не конкретизирована.
- -Estimable:** Нет, невозможно оценить из-за большого объема.
- -Small:** Нет, это эпик, а не история.
- -Testable:** Нет, невозможно протестировать все сразу.
Как улучшить: Эту большую историю нужно разбить на несколько маленьких:
Как администратор, я хочу иметь возможность создавать нового пользователя, чтобы предоставлять доступ к системе.
Как администратор, я хочу иметь возможность редактировать данные существующего пользователя, чтобы обновлять информацию.
Как администратор, я хочу иметь возможность удалять пользователя, чтобы лишать его доступа к системе.
Типичные ошибки и как их избежать
- -Слишком большие истории:** Разбивайте эпики на более мелкие, управляемые истории.
- -Зависимые истории:** Старайтесь минимизировать зависимости между историями. Если зависимости неизбежны, планируйте их реализацию последовательно.
- -Отсутствие ценности:** Всегда задавайте вопрос: «Какую пользу это принесет пользователю?». Если ответа нет, возможно, история не нужна.
- -Нечеткие критерии приемки:** Формулируйте конкретные и измеримые критерии приемки до начала разработки.
Связь с другими темами
- -Agile и Scrum:** INVEST — это один из ключевых инструментов в гибких методологиях разработки. Он помогает командам эффективно работать с бэклогом продукта.
- -Definition of Done (DoD):** Тестируемость истории тесно связана с определением готовности. DoD — это общий для всей команды набор критериев, которым должен соответствовать готовый инкремент продукта.
Заключение
Критерии INVEST — это простой и мощный инструмент для создания качественных пользовательских историй. Соблюдение этих критериев помогает командам избегать многих распространенных проблем, улучшает планирование, повышает прозрачность и, в конечном счете, способствует созданию продуктов, которые действительно нужны пользователям. Начинающим командам рекомендуется постоянно сверяться с INVEST при написании User Stories, со временем это войдет в привычку и станет естественной частью рабочего процесса.