Бизнес требует назвать точную дату релиза, а разработчики мямлят про стори-поинты и отказываются давать гарантии. Зафиксировать время, бюджет и объем работы одновременно невозможно — физика создания программного обеспечения работает иначе. Попытка выбить из команды клятву на крови всегда заканчивается ложью и лавиной багов.
Почему в начале проекта все врут
Scrum Guide 2020 жестко опирается на эмпиризм. Знание приходит из опыта. Написание кода — это исследование неизвестного, а не сборка типовых деталей на конвейере. Вы не можете точно оценить задачу, которую решаете впервые.
Майк Кон описывает эту механику через Конус неопределенности (Cone of Uncertainty). На старте крупной фичи погрешность оценки достигает 400%. Требование зафиксировать дату релиза на этапе сырой идеи заставляет инженеров завышать оценки или скрывать риски. Любой первоначальный план устаревает в тот момент, когда программист открывает IDE и обнаруживает кривой легаси-код или неработающий сторонний API.
Agile переворачивает треугольник ограничений. Время (таймбокс Спринта) и ресурсы жестко зафиксированы. Плавает только объем работы (Scope). Владелец Продукта (Product Owner) управляет Бэклогом Продукта, безжалостно меняя приоритеты и отсекая лишнее. Разработчики (Developers) берут в спринт ровно столько гипотез, сколько могут превратить в готовый Инкремент. Если фича оказалась сложнее, команда режет функционал, а не сдвигает таймбокс. Выпускается урезанная, но на 100% рабочая версия, строго соответствующая Definition of Done.
Таблица
| Ожидание бизнеса | Механика разработки | Инструмент Agile |
|---|---|---|
| Точная дата релиза фичи | Погрешность оценки на старте достигает 400% | Конус неопределенности и вероятностный прогноз |
| Оценка задачи в часах | Часы игнорируют риски, блокеры и сложность интеграции | Относительная оценка в Story Points |
| Фиксированный объем работы | Требования меняются после первого фидбека от рынка | Изменение Бэклога Продукта и жесткое урезание скоупа |
| Гарантия 100% выполнения плана | Скрытые баги и легаси-код ломают первоначальные оценки | Фиксированный таймбокс (Спринт) и переменный объем |
Что делать: от гаданий к математике
Перестаньте выбивать из команды точные даты. Начните управлять рисками через вероятностное прогнозирование. Откройте трекер и посмотрите на Throughput (пропускную способность) и Lead Time (время выполнения). Запустите симуляцию на основе исторических данных. Скажите стейкхолдерам: «Мы закроем эти 20 тикетов к 15 мая с вероятностью 85%». Оперируйте диапазонами.
Зафиксируйте ритм. Спринт длится ровно две недели. Если задача не влезает в таймбокс, Разработчики рубят ее на части (декомпозируют) прямо на Product Backlog Refinement. Владелец Продукта выбрасывает из релиза рюшечки, анимации и сложные фильтры. Оставляйте только критический путь. Вместо сложной системы рекомендаций сделайте простую строку поиска. Выпускайте урезанный, но рабочий Инкремент, собирайте метрики и решайте, стоит ли писать код дальше.
Ограничьте WIP (Work in Progress). Заставьте инженеров доделывать начатое. Чем меньше тикетов висит в статусе «В работе», тем быстрее они доезжают до продакшена. Скорость поставки растет, а разброс сроков сужается. Применяйте роение (Swarming): если задача застряла на тестировании, программист откладывает свой код и идет помогать QA-инженеру.
Хотите точных дат? Идите в строительство мостов.
Главная мысль
Точные сроки — это галлюцинация. Agile не дает гарантий даты, он дает гарантию прозрачности и контроля над рисками. Вы всегда знаете реальный темп команды и можете в любой момент остановить разработку, если гипотеза не подтвердилась. Управляйте объемом работы, режьте фичи без жалости и опирайтесь на математику потока, а не на фантазии стейкхолдеров.
Часто задаваемые вопросы (FAQ)
Назовите диапазон и привяжите его к вероятности. Покажите исторические данные: «С вероятностью 85% мы выпустим фичу между 10 и 15 числом. Если нужно точнее — давайте выкинем половину требований прямо сейчас».
Поинты измеряют сложность и риск, а не время. Задача на 5 поинтов может занять день, если нет блокеров, или неделю, если упадет тестовый стенд. Конвертация в часы заставляет команду завышать оценки и прятать реальные проблемы.
Ужесточите Definition of Ready. Запретите брать в Спринт задачи без декомпозиции. Если тикет больше 5-8 Story Points, рубите его на части еще на этапе уточнения. Не берите в работу то, что нельзя завершить за пару дней.
Таймбокс Спринта не плавает. Команда обязана выдать Инкремент. Расхолаживает отсутствие Цели Спринта (Sprint Goal), когда люди просто жгут тикеты без понимания бизнес-результата. Жесткий таймбокс дисциплинирует лучше любых дедлайнов.
Планируйте релизы на основе исторической Velocity или Throughput. Синхронизируйте маркетинг не с датой старта разработки, а с моментом, когда фича переходит в стадию финального тестирования или раскатывается на пользователей через Feature Toggle.