Бизнес генерирует сотни идей, а разработчики пишут код вслепую, выпуская фичи, которыми никто не пользуется. Разрыв между фантазией стейкхолдера и первым коммитом сжигает бюджеты быстрее, чем падают серверы. Чтобы остановить этот конвейер мусора, нужен жесткий фильтр.
Где идеи становятся гипотезами
Scrum Guide 2020 требует от Владельца Продукта (Product Owner) максимизировать ценность. Любая идея на входе — это просто гипотеза. Она обязана пройти проверку на соответствие Цели Продукта (Product Goal). Прошла — попадает в Product Backlog.
Дальше запускается Product Backlog Refinement (Уточнение). Это непрерывный процесс. Разработчики (Developers) и Владелец Продукта вместе детализируют элементы, добавляют критерии приемки и оценивают размер. Майк Кон настаивает: пока команда не обсудила задачу (Conversation) и не подтвердила условия ее выполнения (Confirmation), писать код нельзя. Уточнение снимает неопределенность до того, как тикет попадет в Спринт.
Таблица
| Этап | Действие | Артефакт / Инструмент |
|---|---|---|
| Генерация гипотезы | PO отсекает идеи, не бьющие в цель. | Product Goal |
| Уточнение (Refinement) | Разработчики дробят фичу и задают вопросы. | Product Backlog |
| Оценка | Команда определяет размер и сложность. | Planning Poker (по Кону) |
| Синхронизация | Формирование четких критериев приемки. | User Story (3C) |
Детали, тесты и оценка
Внедрите постоянный Refinement. Выделяйте на него время прямо внутри текущего спринта. Владелец Продукта приносит бизнес-контекст, а Разработчики ищут технические решения.
Режьте огромные идеи на мелкие куски. Если фича не влезает в один спринт, дробите ее до тех пор, пока она не станет прозрачной. Используйте критерии INVEST Майка Кона. Задавайте неудобные вопросы: «Зачем мы это делаем? Как мы проверим результат?».
Фиксируйте договоренности. Напишите четкие приемочные тесты. Тикет переходит в Sprint Backlog только тогда, когда каждый инженер понимает, как превратить его в рабочий Инкремент.
Главная мысль
Пространство между идеей и кодом — это зона убийства слабых гипотез. Писать код дорого, а обсуждать и выкидывать плохие идеи — дешево. Настройте жесткий фильтр на входе, иначе ваша команда превратится в принтер для генерации технического долга.
Часто задаваемые вопросы (FAQ)
Scrum Guide не ставит жестких лимитов. Тратьте ровно столько времени, сколько нужно для подготовки задач на 1-2 спринта вперед.
Никто. Владелец Продукта приносит проблему, а Разработчики придумывают техническое решение. Живое обсуждение заменяет мертвую документацию.
Запускайте Spike (исследовательскую задачу). Разработчики пишут прототип, чтобы снять технический риск, а затем оценивают основную фичу.
Нет. PO отвечает за ценность и приоритет. Детали рождаются в диалоге с Разработчиками.
Это прямой путь к провалу спринта. Если Разработчики не понимают объем работы, они не могут дать обязательство (Commitment) выполнить Цель Спринта.