Опережающая Канбан-метрика

Канбан-метод позволяет прогнозировать время выполнения задач с вероятностью 80–90%. Опытные канбанисты привыкли смотреть на 85% перцентиль Lead Time и хвалиться предсказуемыми сроками, но такой подход похож на взгляд в зеркало заднего вида, и вот почему.

Что если не смотря на хорошую статистику по Lead Time, незавершенные задачи, как бомба замедленного действия, накапливают свой возраст до критических значений, а потом срабатывают накопленные риски и происходит взрыв срыва сроков? И это все происходит у вас под самым носом.

Недавно я увидел пример такой ситуации в дипломной работе студентки Университета Agile-коучей.

Статистика распределения Lead Time выглядела довольно хорошо: 85% задач закрывались за 198 дней, и, казалось бы, всё под контролем. Но когда мы проанализировали возраст незавершенных задач, то обнаружилось, что 17% из этих задач «висят в работе» уже более 200 дней, а возраст трех самых старых незавершенных задач: 790, 815 и 884 дня!

Получается, что за бодрой статистикой Lead Time скрывалась неприглядная действительность, в которой множество старых задач, никак не двигались к к своему завершению.

Почему классическая статистика по Lead Time подводит нас именно в тот момент, когда стоит включить тревожные сигналы?

Дело в том, что Lead Time показывает данные лишь по завершенным задачам. Это отлично подходит для ретроспективного анализа, но не дает информации о том, что происходит «здесь и сейчас».

Пока вы ждете появления новой точки на диаграмме распределения Lead Time, ваш объем незавершенной работы (WIP) продолжает накапливать «возрастные» задачи,.

Конечно, Канбан-доска и ежедневные Канбан-митинги призваны подавать сигналы, когда возраст задачи начинает опасно расти, но если задач на доске очень много, то не мудрено упустить этот момент.

Чтобы не фиксировать проблемы постфактум, а реагировать на них, пока ещё есть время, нужна опережающая метрика.

В качестве такой метрики отлично работает возраст задачи (Work Item Age), потому что он растет ежедневно, его просто отслеживать, и при наличии контрольных порогов эта метрика начнет сигнализировать про опасное старение задач раньше, чем появится соответствующий «хвост» в диаграмме распределения Lead Time.

Особенно это становится интересным, когда возраст задачи растет, но на Канбан-доске нет явного блокера, который бы служил тому причиной. Это сигнал, что есть какие-то скрытые факторы, влияющие на работу по данной задаче, которые стоит выявить и расследовать.

Даниэль Ваканти, один из классиков Канбан-метода, пишет в своей статье, что чем больше возраст задачи, тем больше риск, что к моменту завершения она окажется не актуальна, или, что само решение о начале работ над ней, окажется ошибкой. Поэтому не следует позволять задачам бесконтрольно “стареть”. Динамику старения нужно опрозрачить, и управлять ею.

Ваканти определяет “ненужное старение задач”(unnecessary aging of work items), как ситуацию, когда задача находится в работе (или в очереди на выполнение) дольше, чем это действительно требуется для её завершения и доставки ценности клиенту

В своей статье Даниэль Ваканти утверждает, что предотвращение ненужного старения задач является самым важным базовым принципом Канбан-метода. Он даже пишет, что все практики Канбан-метода могут быть выведены из этого базового принципа:

Чтобы не гадать, сколько «вечных» задач копится у нас в WIP, и вовремя реагировать на скрытые риски, нужен специальный инструмент — диаграмма WIP Aging Chart. Давайте посмотрим, как она строится, и пошагово разберем ее элементы.

По оси X мы откладывается статус задачи на вашей Канбан-доске

По оси Y — ее текущий возраст в днях.

Когда на таком графике мы видим, что задачи справа по статусам обладают бОльшим возрастом, чем задачи слева по статусам - это вполне логичное и нормальное развитие событий.

Но вот если вдруг окажется, что задача в статусах ближе к началу, почему-то вдруг "живут" дольше, чем задачи в статусах ближе к концу рабочего процесса - вот тут уже точно все идет не хорошо, и надо бить тревогу. Потому что это означает, что задачи стареют и НЕ умирают на ранних стадиях рабочего процесса, превращая первые колонки в "помойку", где копятся, но не реализуются хотелки заказчиков

Чтобы лучше понять причины, по которым задачи делаются долго, полезно “покрасить” задачи разных классов обслуживания в разные цвета, а заблокированные задачи выделить отдельным цветом (красным).

Например, можно принять следующую систему цветового кодирования:

Красный - заблокированная задача

Оранжевый - Expedite -задача (критический дефект, срочная задача на 1 млн долларов и так далее)

Фиолетовый - Fixed Date - задача с фиксированной датой поставки, которую невозможно сдвинуть (например, регуляторные задачи)

Зеленый - обычная задача

Синий - Intangible- задача (задачи развития, техдолг и тд)

И тогда картинка становится гораздо более наглядной

Глядя на такой график становится с первого взгляда становятся понятны причины возраста отдельных задач.

Красные - заблокированные задачи - требуют ежедневного внимания, так как есть очевидные и явные причины, по которым они не движутся дальше.

Оранжевые - Expedite задачи, с наивысшим классом обслуживания, промедление по которым обойдется нам очень дорого. И хорошо если их возраст - самый маленький из всех остальных задач - это значит, что команда действительно уделяет им повышенное внимание и берется за нее в приоритетном порядке, стремясь быстрее довести до конца.

Фиолетовые - задачи с фиксированной датой исполнения, которую нельзя сдвинуть. Например - регуляторные задачи. Очевидно, что чем ближе к дате сдачи, тем больше внимания им должно уделяться.

Зеленые - обычные задачи, которые мы делаем в обычном режиме.

Синие - Intangible класс обслуживания. Задачи, которые надо делать, но не в приоритетном порядке. Это обычно задачи развития, задачи оптимизации, техдолга и так далее. Терять их из виду нельзя, но и ставить их первым приоритетом странно

Цветовое кодирование позволяет быстро сориентироваться в том, что происходит, но пока еще на диаграмме нет никаких элементов, которые подавали бы нам сигналы о том, что ситуация становится угрожающей, и пора реагировать, принимая управленческие решения.

И здесь нам помогут перцентили времени выполнения задач (Lead Time): 50%, 70%, 85%, 95% - эти значения показывают вероятность того или иного времени выполнения задач. Их обычно наносят на диаграмму в качестве горизонтальных линии, и когда возраст задачи опасно приближается к тому или иному перцентилю, это явное свидетельство пропорционального возрастания риска срыва сроков.

Но какой из перцентилей является главным? Нарушение какого порога кратно увеличивает риск срыва сроков, и вероятность визита разьяренного заказчика?

Для определения такого порога, Даниэль Ваканти предлагает использовать понятие Service Level Expectation (SLE) - Ожидаемый Уровень Обслуживания.

SLE вычисляется на основе исторических данных, и является прогнозом времени выполнения задач (Lead Time) на который мы будем ориентироваться при ответе на вопрос - все ли идет хорошо?. В нормальном состоянии, мы ожидаем, что большинство задач будут выполняться в рамках SLE. Превышение этого порога, или приближение к нему, является сигналом того, что что-то идет не так.

Обычно в качестве SLE выбирают 85% перцентиль времени выполнения задач (Lead Time).

Опираясь на этот перцентиль, мы можем давать прогноз, в котором вероятность ошибки составляет всего 15%. Это, зачастую, вполне достаточная точность, которая устраивает бизнес-заказчиков. Если толерантность к риску срыва сроков у заказчика меньше, то могут быть выбраны более высокие перцентили в качестве SLE.

Что означает SLE = 85%? Это означает, что как только задача появляется в системе (переходит в первый статус рабочего процесса), вероятность того, что она нарушит SLE уже не нулевая, и равна равна 15%.

Допустим, мы знаем, что 85% Lead Time равен 14 дням.

Это означает, что если к нам приходит заказчик и спрашивает “когда будет сделана задача”, то он получит следующий ответ: с вероятностью 85% задача будет сделана в течении 14 дней от даты начала работы над ней. Вероятность превысить эту длительность выполнения равна 15%

Представим, что у нас есть исторические данные по Lead Time 100 завершенных задач

Допустим, что из этой статистики видно, что:

То есть медиана (50%) времени завершения (Lead Time) равна 8 дням, а 85% задач завершились в течении 10 дней.

Теперь представим, что мы видим на доске еще не завершенную задачу, и ее возраст уже равен 8 дням. Какова теперь вероятность, что эта задача нарушит SLE? Все еще 15% или все-таки выше?

Давайте разбираться.

Раз эта задача "живет" уже 8 дней, то это значит, она точно не входит в число тех 50 задач, которые завершались быстро - за 1,3 или 5 дней. Эта задача уже попала в число долгих задач — тех, которые делаются больше 8 дней.

Чисто логически, чем старше задача, тем выше вероятность, что она будет стареть дальше и в итоге нарушит SLE.

Как это посчитать? С помощью условной вероятности.

Используя формулу условной вероятности можно рассчитать какова вероятность того, что Lead Time данной задачи превысит 10 дней, при условии что ее возраст уже равен 8 дням.

Математики обозначают такую условную вероятность вот так:
P(T>10 ∣ T>8)

Эта условная вероятность вычисляется как результат деления значения вероятности превысить SLE равный 10 дням:
P(T>10) = 15% = 0,15
на значение вероятности превысить Lead Time 8 дней:
P(T>8) = 50% = 0,5

Получается, что для нашей задачи, “прожившей” 8 дней (50% Lead Time), риск стать долгожителем и нарушить SLE=10 дней вырос до 30%.

Рост вероятности риска увеличился в два раза: с 15% до 30%

А что если возраст задачи достиг уровня 70% Lead Time? Давайте посчитаем.

Допустим, 70% Lead Time равен 9 дням.
Тогда вероятность превысить возраст 9 дней равен:
P(T>9) = 100% - 70% = 30% = 0,3

Зная это значение, можно вычислить условную вероятность того, что задача дожившая до 9 дней, будет делаться дольше уровня SLE=10 дней:

Ого! Риски сильно выросли! С 30% до 50%!

И так далее. Достижение каждого порогового перцентиля Lead Time пропорционально увеличивает риск срыва SLE

Вот почему так важно наблюдать за возрастом задач и вовремя реагировать на приближение к пороговым значениям, пока не стало слишком поздно.

Для того, чтобы быстро увидеть, что риски нарушения SLE выросли, и вовремя среагировать, на графике WIP Aging Chart разным цветом обозначают разные зоны рисков.

На этой диаграмме для каждого статуса работ обозначены зоны риска нарушить SLE:

Для большей точности, для каждого статуса задач на основе исторических данных определены 50%, 70%, 85% и 95% перцентили возраста уже закрытых задач, к моменту, когда они перешли в этот статус.
То есть, если нам известен Lead Time закрытых задач, то исходя из исторических данных мы можем построить для каждого статуса, который эти задачи проходили, построить частотную диаграмму возраста задачи, на момент когда задача вышла из этого статуса. И вычислить 50%,70%, 85% и 95% перцентили этих возрастов, и отложить их на графике

Цветовое кодирование зон риска трансформирует структуру ежедневных стендапов, перемещая фокус с индивидуальной отчетности на системное управление потоком.

Красная зона требует немедленного внимания менеджера с вопросом "Почему этот элемент застрял так надолго?" и действиями по привлечению дополнительных ресурсов, эскалации, или принятия тяжелого решения об отмене.

Оранжевая зона становится зоной каждодневного внимания с фокусом на возможности ускорения через совместную работу людей в команде, обсуждение с Менеджером Продукта возможности поставки минимального ценной части задачи, привлечение необходимых экспертов или другими способами.

Желтую зону можно мониторить реже - раз в неделю. Фокусируясь на анализе причин замедления и проверкой блокеров.

Зеленая зона мониторится по требованию с вопросами “Есть ли какие-то проблемы, которые мешают завершить эту задачу в ожидаемый SLE?”

Такой структурный подход перенаправляет усилия команды в зоны риска, и не дает перерасти потенциальным рискам в реальные проблемы.

Когда у команды сформируется соответствующая привычка работы с WIP Aging Chart, можно даже отказаться от ежедневных стендапов, и собираться только если какая-то задача оказалась в оранжевой или красной зоне, и нужно привлечь внимание менеджмента к проблеме.

Всю эту красоту наверняка очень хочется иметь в готовом виде, так как построить точечную диаграмму в Excel или Google Spreadsheet не так то просто, придется обходится столбцовыми диаграммами, которые не так наглядны. А программировать собственное решение на основе API вашего таск трекера - долго и дорого.

Исследование готовых инструментов показало следующую ситуацию на момент написания статьи такого рода график “из коробки” предоставляют в основном малоизвестные в России сервисы:

Похоже, выбор невелик - либо использовать “Jira Metrics Plugin” с JIRA, либо поручить это дело внешним сервисам аналитики

WIP Aging Chart позволяет удобно и наглядно отслеживать возраст задач, и предотвращать их неконтролируемого старение. Это позволяет на своевременно обнаружить риски нарушения SLE и сфокусировать усилия команды в нужном направлении.

WIP Aging Chart так же позволяет сфокусировать ежедневный Канбан-митинг на выявление ранних сигналов и реакцию на них.

К сожалению, небольшое количество таск-трекеров позволяют “из коробки” построить WIP Aging Chart, но есть возможность поручить это внешним аналитическим сервисам, чтобы держать руку на пульсе.

Таким образом, мы получаем опережающую Канбан-метрику, которая необходима для баланса управления рабочим процессом, чтобы не судить о происходящем “по прошлой погоде”, а держать руку на пульсе и реагировать в моменте на возникающие риски.

Больше материалов по анализу данных с помощью Канбан-метрик, можно найти в моем Телеграм-канале "Данные в действии"

PS Перепечатка материала или его части возможна только с согласия автора