Привет, Хабр!
Многие команды однажды замечают, что оценочные сессии превращаются в рутину, а прогресс всё не торопится улучшаться. Парадоксально, но именно так родилось движение #NoEstimates — отказ от традиционных оценок времени и переключение на метрики, основанные на реальных данных. Вместо гаданий «сколько времени займёт фича» мы смотрим на поток работы и используем его показатели для планирования.
Концепция #NoEstimates во многом объяснена в публикациях старожилов Agile. Оценки всегда неточны, обычно очень сильно. Единственный случай, когда оценка может сработать — это когда вы строите то же самое снова. Во всём остальном мире — где постоянно что‑то меняется — тратить время на приблизительные расчёты бессмысленно. Гораздо важнее смотреть на реальные показатели команды: скорость выполнения задач, время их прохождения и т. п. Холуб дальше замечает, что планировать «строгие» сроки — это пережиток водопадной модели, а Scrum‑фреймворк даже не требует от команды жёсткого commit«а на объем работ: в Scrum говорят о прогнозах (forecast), а не о фиксированных обязательствах.
Идея #NoEstimates
Суть #NoEstimates не в том, чтобы вообще ничего не делать, а в том, чтобы заменить оценку времени объективными метриками потока. Неизменный принцип: работайте над наиболее важным функционалом дальше вместо того, чтобы серьёзно коммититься на полный список фич. Планирование спринта становится проще: берёте верхушку бэклога по приоритету, начинаете над ней работать, а если что‑то не успели — просто возвращаете задачу обратно. Показатели в сторипойнтах при этом теряют актуальность.
Кроме того, #NoEstimates предполагает использовать исторические данные для прогнозов. Лучше сравнить оба подхода — обычные оценки и потоковые метрики — и посмотреть, что точнее предсказывает сроки. Для этого можно взять статистику из Jira или другой системы и пойти на простой сайт.
Основные Flow-метрики
Flow‑метрики (метрики потока) — количественные показатели эффективности движения работы через процесс разработки. Они фокусируются на скороcти и предсказуемости поставки ценности, а не на субъективных оценках. Метрики, с которыми стоит работать:
Throughput (пропускная способность) — число задач/эпиков, завершаемых командой за единицу времени (например, в неделю). Если команда закрыла 8 задач за неделю, то throughput = 8 задач/неделю. Это число объективно и сложно «накрутить», в отличие от рассказов про скорость в сторипойнтах.
Cycle Time (время цикла) — время от начала работы над задачей до её завершения. Эта метрика показывает, сколько реально тратится дней (или спринтов) на завершение задачи.
Lead Time (время доставки) — время от появления запроса (или принятия обязательства) до фактической поставки результата пользователю. По сути, это суммарное время ожидания и работы по задаче.
WIP (Work In Progress) — количество задач, находящихся в работе одновременно (незавершённой работы). Важный параметр, ведь по закону Литтла увеличение WIP прямо увеличивает время выполнения. По закону Литтла: среднее время выполнения = WIP / Through. То есть, если в работе 24 задачи, а команда закрывает 2 задачи в день, среднее время = 24÷2 = 12 дней. Ограничение WIP в нашем примере до 10 задач резко сократило время до 5 дней, без роста скорости разработки.
Flow Efficiency (эффективность потока) — отношение времени активной работы к общему времени цикла задачи. По сути, это «КПД» процесса. Обычно многие задачи простаивают в ожидании ревью, тестирования или релиза — так что эффективность потока в подавляющем большинстве команд низкая (обычно 10–15%). Это означает, что ~85–90% времени задача простаивала, а не обрабатывалась.
Эти метрики помогают увидеть «узкие места» процесса.
От Story Points к потоковым метрикам
Исторически многие использовали Story Points и velocity для планирования. Но на практике это часто приводит к проблемам. Уже после пары спринтов команды начинают «молча ставить оценки» без обсуждений и выравнивания понимания, а результаты всё равно неточно отражают реальный прогресс. При этом зачастую Story Points используются не для обсуждения сложности, а превращаются в самоцель — «накапливаем баллы» под понятный результат, что напоминает просто другой взгляд на старый привычный подход (коммит обьёма задач).
Согласно опыту вместо того чтобы вложить силы в долгие тренинги по SP, командам проще использовать метрики потока, которые дают автоматические объективные данные. Flow‑метрики не требуют постоянного фасилитатора, дают понятную картину и сразу показывают застряла ли работа в узких местах или нет», чего Story Points не дают.
Есть и сугубо технические причины. Например, если заменить все значения Story Points на единицы, то качество прогноза не ухудшается. То есть, можно с большей точностью прогнозировать рабочие объёмы, просто считая число задач, а не тратя ресурсы на сложные оценки.
Многие рекомендуют разделить цели: Story Points хороши для внутренних обсуждений и выравнивания понимания задачи (например, при планировании или рефинементе). А Flow‑метрики нужны для прогноза и улучшения процесса: они позволяют делать надёжные бизнес‑прогнозы, выявлять bottleneck«и и принимать решения на объективных данных. Такая практика доказала свою эффективность: если стоит задача „прогнозировать сроки“ или „улучшить поток“, метрики потока часто дают лучший результат с меньшими затратами усилий.
Применение flow-метрик
Чтобы начать управлять потоком, нужно собирать данные о текущем процессе. Команда может, например, вести простой трекер выполненных задач по дням или спринтам. Важно понять, насколько стабилен поток. Хорошая практика — смотреть на throughput не только спринтами (всего ~25–50 точек в год), но и покороче. Еженедельные или ежедневные измерения дают десятки‑шестьдесят точек в год, что позволяет увидеть закономерности.
Например, анализ throughput по дням недели часто показывает: по понедельникам почти ничего не закрывается (время планирования), в середине недели активность растёт, перед релизом в пятницу — пик, а после — спад. Если такие паттерны есть — стоит учесть их при прогнозах.
Шаги прогноза обычно таковы:
Соберите историю throughput (например, число завершённых задач за каждый прошедший период).
Постройте распределение этого показателя, выделите среднее и дисперсию.
Примените симуляцию Монте‑Карло, генерируя тысячи сценариев на основе исторических данных. Это даст вам вероятностный диапазон прогнозов.
Результатом Monte Carlo будет не одно число, а кривая вероятностей: например, вывод: «50% сценариев завершают 10 задач за 39 дней, 85% — за 50 дней». Тогда корректно сообщить, что работы хватит примерно на 5–7 недель (с учётом 85%‑го уровня доверия). Такой прогноз сразу честно показывает разброс. К тому же, прогнозы имеют смысл только при ограниченном WIP. Если в работу можно бесконечно «запихивать» задачу за задачей, поток становится хаотичным, и любые модели дают «мусор на выходе».
Кстати, про закон больших чисел. Потоковые метрики хорошо работают именно из‑за статистики: чем больше элементов учтено, тем меньше случайные колебания от разной сложности «зашумляют» картину.
Предупреждения и рекомендации
При работе с метриками потока важно помнить, что нет «сирены», на которую нужно просто палить. Ни одна метрика сама по себе не скажет, какой функционал важен для бизнеса. Например, опасно гнаться только за ростом throughput, забывая о качестве: уменьшение времени выполнения ценой роста числа багов — это не улучшение. Наоборот, это приведёт к росту техдолга и разочарованию пользователей.
Ещё одна ошибка — оптимизировать все метрики одновременно. Если вы хотите и увеличить throughput, и сократить WIP, и повысить flow efficiency — это разные задачи, и стремление делать всё сразу часто создаёт противоречие целей. Лучше честно поставить приоритет: сначала выявить и устранить самые критичные узкие места, затем переходить к следующему. И, конечно, связывать метрики с бизнес‑результатом: сокращать lead time бессмысленно, если на выходе ничего ценного не появляется.
Не забывайте регулярно обновлять прогнозы: рынок меняется, приоритеты клиентов могут сдвигаться, а состав команды — меняться. Монте‑Карло и другие методы дают вероятность, а не железный дедлайн. Лучше подойти к бизнесу и сказать: «по нашим данным, 85%‑ный прогноз выполнения этой работы — X дней, а 50%‑ый — Y дней», чем выдумывать конкретную дату без учёта вариативности.
Заключение
Отказ от оценки «на глаз» не означает отказ от планирования. #NoEstimates + Flow‑метрики предлагают другой маршрут: вместо трат времени на сомнительные расчёты — использовать реальные данные команды для обоснованных прогнозов. Flow‑метрики (Throughput, Lead Time, WIP, Flow Efficiency и др.) открывают глаза на узкие места процесса и позволяют давать более честные прогнозы. Если ваша цель — надёжные прогнозы и постоянное улучшение, метрики потока часто дают лучшие результаты при меньших затратах.
Да, это потребует немного перестроить мышление: принимать, что в какой‑то мере выходим из зоны комфорта «чек‑листов», и смотреть на работу как на поток ценности. Зато взамен вы получаете реальную предсказуемость и объективные данные для принятия решений. И разве не этого мы хотим как прагматичные мыслители?
После того как мы обсудили, как Flow‑метрики помогают оптимизировать поток задач и принимать решения на основе реальных данных, стоит обратить внимание на аналогичный подход к развитию команды.
Всем заинтересованным в развитии команды рекомендуем ознакомиться с корпоративными услугами от OTUS, которые позволяют системно улучшать компетенции сотрудников. Обучение строится на объективных показателях: бесплатные открытые уроки и тесты дают возможность оценить текущий уровень знаний команды без лишних обязательств и спланировать обучение на основе реальных данных.
А чтобы оставаться в курсе актуальных трендов управления в IT и первыми узнавать новости о бесплатных мероприятиях, подписывайтесь на Telegram‑канал OTUS4Business.