Бизнес искренне не понимает, почему прошлая кнопка заняла два часа, а точно такая же новая висит в разработке третью неделю. Разработчики оправдываются, менеджеры требуют точных оценок, а доверие тает на глазах. Проблема кроется в том, что вы измеряете время написания кода, полностью игнорируя время ожидания в очередях.
Иллюзия активной работы
Scrum и Kanban опираются на эмпиризм. Создание кода — это не конвейерная штамповка деталей, а решение уникальных проблем. Двух одинаковых задач в ИТ не существует. Внешне идентичные фичи ложатся на разный легаси-код, требуют разных интеграций и сталкиваются с разными блокерами.
Время выполнения задачи (Cycle Time) состоит из времени активной работы и времени простоя. Практика показывает: 85% времени тикет просто ждет. Он ждет код-ревью, ждет свободного тестировщика, ждет ответа от смежного отдела. Инженер пишет код за те же два часа, но из-за забитых лимитов незавершенной работы (WIP) и постоянного переключения контекста задача доезжает до продакшена неделями.
Утверждать, что две задачи в ИТ одинаковые — это как верить, что два похода к стоматологу пройдут одинаково. Вроде и там, и там зубы, но в одном случае это чистка за 15 минут, а в другом удаление нерва без анестезии на три часа.
Таблица
| Фактор | Иллюзия оценки | Реальность потока |
|---|---|---|
| Сложность фичи | Одинаковый UI означает одинаковую работу | Под капотом разный легаси-код, костыли и зависимости |
| Время выполнения | Часы, потраченные программистом на кодинг | 85% времени задача лежит в очередях (ревью, QA, деплой) |
| Загрузка команды | 100% загрузка ускоряет релиз | Мультизадачность убивает фокус, Cycle Time растет экспоненциально |
| Ясность требований | Все детали понятны на этапе планирования | Скрытые блокеры всплывают только после открытия IDE |
Чиним поток, а не людей
Перестаньте выбивать из инженеров точные оценки в часах. Начните измерять и оптимизировать поток. Откройте Канбан-доску и найдите скрытые очереди. Разделите колонку «Тестирование» на «Готово к тестированию» и «В тестировании». Вы сразу увидите, где именно тикеты покрываются пылью.
Ограничьте WIP (Work in Progress). Запретите разработчикам брать новые фичи, пока старые висят на ревью. Применяйте роение (Swarming): застряла задача — вся команда бросает текущие дела и помогает протолкнуть ее к релизу. Жесткий лимит заставляет систему выплевывать готовый Инкремент быстрее.
Уничтожайте технический долг. Заложите в каждый спринт время на рефакторинг. Чем чище архитектура, тем меньше сюрпризов вылезает при реализации простых фич. Используйте метрику Work Item Age (Возраст задачи) на Daily Scrum: если тикет висит дольше обычного, немедленно эскалируйте проблему и снимайте блокировки.
Главная мысль
Время выполнения задачи зависит не от скорости печати программиста, а от пропускной способности вашей системы. Одинаковые фичи занимают разное время, потому что они попадают в разный контекст, разные очереди и разный уровень технического долга. Управляйте потоком и устраняйте блокеры, а не давите на исполнителей.
Часто задаваемые вопросы (FAQ)
Покажите график Cycle Time Scatterplot. Объясните на примере пробок на дороге: один и тот же маршрут занимает разное время в зависимости от заторов. Если система перегружена, любая задача будет ехать медленно.
Поинты оценивают сложность и риск, а не время в часах. Пять поинтов могут занять день чистой работы или неделю простоя из-за упавшего тестового стенда. Оценка не управляет очередями
Внедрите парное программирование (Pair Programming). Ревью происходит в реальном времени, очередь исчезает, тикет летит в релиз без задержек.
Нет. Используйте вероятностное прогнозирование (метод Монте-Карло) на основе исторических данных. Алгоритм уже учитывает все ваши прошлые простои, баги и блокеры.
Проводите жесткий Product Backlog Refinement. Дробите задачи, пишите критерии приемки и обсуждайте архитектуру до того, как тикет попадет в Sprint Backlog. Снимайте неопределенность заранее.