Закон Литтла и его применение в IT-менеджменте Закон Литтла (Little's Law) - это фундаментальный закон в теории массового обслуживания и теории очередей. Закон был доказан и формализован американским профессором Джоном Литтлом в 1961 году, хотя интуитивно применялся задолго до этого. В чем его суть: среднее число задач внутри системы равно произведению средней интенсивности входящего в систему потока этих задач на среднее время нахождения задачи в системе. В чем его гениальность: он устанавливает простую, но мощную взаимосвязь между тремя ключевыми метриками любой системы, работающей с потоками. В большей или меньшей степени закон применим вообще для любой сферы бизнеса/производства, где актуален поток задач/заявок, но нас традиционно интересует айтишечка. Если чуточку пораскинуть мозгами, придем к выводу, что три наиболее популярных канбановских метрики - WIP, Throughput, Cycle Time - ни что иное, как три параметра обозначенной выше формулы. Что за метрики: Work in Progress (WIP) - количество задач, находящихся в работе одновременно (то, что на борде между столбцами "In progress" и "Done"). Throughput — пропускная способность команды (например, 5 задач в неделю). Cycle Time — среднее время выполнения одной задачи, начиная с момента непосредственной работы над ней. Итого, Закон Литтла в Канбане будет выглядеть так: WIP = Throughput * Cycle Time В чем польза применения Закона Литтла здесь: ▪️возможность манипулировать одними параметрами, изменяя другие; ▪️возможность прогнозировать сроки, бюджеты, ресурсы; ▪️возможность фокусироваться на потоке, а не на утилизации задач: вместо того чтобы заставлять всех быть фултайм занятыми (это неизбежно приведет к росту WIP и росту времени выполнения каждой задачи), закон учит ценить быстрый поток задач от начала до конца. Примеры применения: ▪️если ограничить количество одновременно выполняемых задач (WIP), то при стабильной пропускной способности (Throughput) среднее время выполнения задачи (Cycle Time) автоматически уменьшится. ▪️зная свою текущую пропускную способность и количество задач в бэклоге, можно предсказать, когда будет допилен проект. Это основы Канбана. А теперь пара слов о подводных камнях: ▪️Закон Литтла идеален для ситуаций, когда все задачи, проходящие через систему, имеют приблизительно одинаковый объем и сложность, однако это не про айти. В нашем с вами случае, т-щи, следует использовать, как вы уже догадались, Story Points или человеко-часы. Оперируя, например, часами, получим: WIP - это не "штуки", а сумма эстимейтов (в часах), находящихся в работе. Throughput измеряется в человеко-часах, реализуемых за единицу времени (например, за неделю). Cycle Time - время выполнения задачи в часах. Скорректированная т.о. формула будет работать идеально в том случае, если ваши оценки достаточно точны, а производительность команды относительно стабильна. На практике так бывает нечасто, поэтому держим в уме возможность использования Story Points для оценки задач (если, конечно, заказчик не против такой затеи). Да, Story Points - это по ряду причин чаще скрамовская история, чем канбановская, но где наша не пропадала? Стабилизируйте команду и переходите обратно на часы. ▪️Надо помнить, что 9 женщин не способны родить ребенка за 1 месяц. Сам по себе Закон Литтла не учитывает этот аспект, но помогает его обнаружить. Он утверждает, что если ваша система устойчива и способна обрабатывать поступающую нагрузку, обозначенные три параметра будут связаны описанной формулой. При этом он не гарантирует, что вы можете бесконечно уменьшать Cycle Time, уменьшая WIP.