В мире Agile существует бесконечный спор о том, как правильно оценивать работу. Одни команды тратят часы на планирование в Story Points, другие пытаются высчитывать идеальные человеко-часы. Но есть метрика, которая игнорирует догадки и опирается только на факты. Это Throughput.
Throughput — это количество единиц работы, которое команда завершила за определенный период времени. Это может быть 10 задач в неделю, 5 фич в месяц или 20 тикетов за спринт. Здесь нет оценок сложности или размеров. Есть только сухой факт: сколько работы пересекло финишную черту.
В чем отличие от Velocity
Многие путают Throughput и Velocity, так как обе метрики говорят о скорости. Разница фундаментальна.
Velocity основана на оценке. Команда предполагает, что задача «А» весит 5 баллов, а задача «Б» весит 3 балла. В конце спринта мы суммируем эти баллы. Это субъективная величина, которая зависит от настроения команды и инфляции оценок.
Throughput основан на количестве. Мы просто считаем штуки. Задача «А» — это одна единица. Задача «Б» — тоже одна единица.
| Характеристика | Velocity (Scrum) | Throughput (Kanban/Flow) |
| Единица измерения | Story Points (баллы) | Количество задач (штуки) |
| Основа | Субъективная оценка сложности | Объективный факт завершения |
| Для чего нужно | Планирование емкости спринта | Прогнозирование сроков и дат |
| Точность | Зависит от качества оценки | Зависит от стабильности потока |
Почему размер задач не имеет значения
Самое частое возражение против Throughput звучит так: «Но ведь задачи бывают разными! Одна занимает час, а другая неделю. Как можно их просто складывать?».
Здесь вступает в силу закон больших чисел. На дистанции размеры задач усредняются. В одной неделе у вас будет пара крупных задач и три мелких. В другой — одна огромная и пять крошечных. Если вы посмотрите на данные за 10 недель, вы увидите, что среднее количество задач, которые команда способна «переварить», остается удивительно стабильным.
Более того, использование Throughput подталкивает команду к правильному поведению — декомпозиции. Чтобы метрика работала точнее, вы интуитивно начинаете дробить слонов на примерно одинаковые стейки, что улучшает поток и снижает риски.
Как использовать Throughput для прогнозов
Главная сила этой метрики, возможность отвечать на вопрос «Когда будет готово?» без гадания на кофейной гуще. Для этого используется метод Монте-Карло.
Вместо того чтобы спрашивать команду «За сколько вы это сделаете?», мы берем исторические данные о Throughput за последние 20 недель и запускаем симуляцию. Алгоритм проигрывает тысячи вариантов развития событий и выдает вероятностный прогноз.
Например: «С вероятностью 85% мы завершим эти 50 задач за 35 дней». Это гораздо надежнее, чем обещание, данное на планировании под давлением менеджера.
Связь с законом Литтла
Throughput не существует в вакууме. Он неразрывно связан с количеством работы в процессе (WIP) и временем выполнения (Cycle Time). Эту связь описывает закон Литтла:
Cycle Time = WIP / Throughput
Эта формула дает нам ключ к управлению скоростью. Если вы хотите, чтобы задачи делались быстрее (уменьшить Cycle Time), у вас есть два пути: либо увеличить Throughput (что сложно, так как люди не роботы), либо уменьшить WIP (что легко — просто перестаньте начинать новое, пока не закончите старое).
Резюме: Честность превыше всего
Throughput — это метрика для зрелых команд, которые готовы смотреть правде в глаза. Она не прощает простоев и не позволяет спрятаться за высокими баллами Story Points.
Если ваш Throughput падает, это не значит, что команда стала ленивой. Это сигнал системы. Возможно, выросли очереди на тестирование, или задачи стали слишком крупными, или внешний заказчик блокирует работу. Throughput это индикатор здоровья вашего потока, за которым нужно следить динамике.
Часто задаваемые вопросы (FAQ)
Да. Баг это работа, которая занимает время команды и проходит через доску. Если вы не считаете баги, вы завышаете свою реальную производительность по доставке ценности и получаете искаженные прогнозы.
Категорически нет. У каждой команды свой контекст, свой характер задач и свой процесс декомпозиции. Сравнивать пропускную способность команды поддержки и команды разработки ядра бессмысленно и вредно.
Парадоксально, но для этого нужно ограничить количество одновременной работы (WIP). Чем меньше задач находится в работе одновременно, тем быстрее они доходят до финиша, и тем чаще вы освобождаетесь для новых задач. Также помогает более мелкая нарезка задач.
В Канбан-методе — да. В Скраме они могут сосуществовать. Velocity помогает планировать емкость спринта, а Throughput помогает строить долгосрочные прогнозы дат релиза.
Это признак нестабильности процесса. Скорее всего, у вас проблемы с декомпозицией (задачи слишком разного размера) или с внешними блокировками. Вам нужно стабилизировать поток, прежде чем пытаться строить прогнозы.