Формат истории (INVEST)
Тема дорожной карты · Business Analysis
Формат истории INVEST — это проверочный список, разработанный Биллом Уэйком, который помогает определить, насколько эффективно и правильно сформулирована каждая история пользователя. Этот формат играет ключевую роль в обеспечении того, чтобы каждая история была независимой, переговорной, ценной, оценочной, маленькой и проверяемой. Нарушение любого из этих принципов может указывать на необходимость разбить или уточнить историю до начала планирования.
Как это работает
INVEST используется как проверочный список на этапе детализации (refinement) истории пользователя. Independent (независимый): история должна быть способна к самостоятельному выполнению, без необходимости ожидания завершения других историй. Если история зависит от других, её следует разделить или явно последовательно связать. Negotiable (переговорная): история должна оставлять пространство для переговоров и уточнений команды. Переговорная история позволяет команде находить лучшие способы реализации. Valuable (ценная): история должна приносить реальную ценность для определенного стейкхолдера. Estimable (оценочная): история должна быть такой, чтобы команда могла оценить её размер. Если история слишком сложна для оценки, это может указывать на необходимость дополнительного исследования. Small (маленькая): история должна быть достаточно маленькой, чтобы ее можно было завершить в рамках одного спринта. Testable (проверяемая): история должна иметь четкие критерии приёма, которые позволяют команде проверить, что история выполнена правильно.
Когда применять
Прогоняйте INVEST на каждом этапе детализации истории пользователя, а не только на тех, которые вызывают проблемы. Истории, которые не соответствуют хотя бы одному из принципов INVEST, часто имеют проблемы и в других областях. Применение INVEST на каждом этапе детализации помогает предотвратить проблемы и обеспечивает более эффективное планирование.
Типичные ошибки
- Гипер-формальное применение — прохождение INVEST как нудного чек-листа для каждой истории может привести к тому, что команда потеряет вовлеченность. Вместо этого INVEST должен стать привычкой, а не ритуалом.
- Неправильное деление историй — деление истории по техническим слоям, например, 'story A: UI, story B: backend', нарушает независимость и ценность истории. Истории должны делиться по поведению пользователя или меньшим end-to-end-срезам.
- Притворство, что Large-истории Small — часто story-points могут быть переоценены, что маскирует переразмеренную работу. Важно доверять интуиции команды, если история кажется слишком большой для одного спринта.