👀️️️️️️ Друзья, делюсь планом контента с отпускными фото из Приэльбрусья ❤️🏔

- Посты про метрики были подготовкой к нашему митапу @agileufa в воскресенье. Уже 70 человек зарегистрировалось! Планирую завершить темы Lead Time, Aging и закон Литтла к концу недели.

- Хочу реже публиковать посты (раз в неделю) и больше обсуждать оргизменения, исследования и прогнозирования. Проголосуем?
- 👍 за посты реже
- 🔥 и так норм частота

- Метрики важны как база, в том числе чтоб делать разбор в моем инструменте прогнозирования: https://predictable.team

- Есть темы (кейсы / советы / обзоры), которые интересно было бы обсудить?

Часть третья про Lead Time (база тут, про связь cycle time+lead time+time to market тут). Обсудим кластеризацию типов работы, динамику, гистограммы и диаграммы рассеивания, end 2 end.

Дорогой друг, давай прям на практике пройдёмся по показателям:
- Открываем в хроме https://predictable.team, нажимаем на Try with Demo Data, и кликаем на вкладку Lead Time. На графике Scatteplot показывается, за какое время завершается 50% задач (median), а за какое 85%.

🏄‍♂️ В Lead Time динамика всегда важнее текущего состояния

Один раз замерить lead/cycle time полезно. Но если хочешь реально улучшать показатели надо смотреть в динамике на типы работы (прямо как в throughput).

🎳 Кластеризуй Lead Time по типам работы (потому что они все разные)

На практике, чаще показывают гистограмму Lead Time. Но мне субъективно кажется что в ней не хватает временной динамики, поэтому я люблю диаграмму рассеивания (scatterplot, control chart в Jira).

- Баги — обычно устраняются быстрее (у них часто самые короткие lead time).
- Полноценные end-2-end стори — куда длиннее, иногда с кучей согласований.
- Инциденты — вообще особый поток, SLA, жёсткое реагирование.

Посему смотрим на динамику в два шага:

1. Общая динамика (вкладка Lead Time)
2. Динамика по классам задач. Для этого в верхнем меню можно менять набор "Issue Types".

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

🧩 Цикл твоей команды ≠ end-to-end всего потока ценности.

Оптимизировал поток своей команды вместе с ребятами, далаете свои задачи быстрее? Молодцы, но зачастую на всем end-2-end потоке работы ваша оптимизация будет локальной (то есть расширить самые медленные бутылочные горлышки и простои в сквозной системе всегда будет эффективнее, чем оптимизировать какую-то только подконтрольную вам часть).

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

#leadtime #cycletime #timetomarket #метрики #metrics #flowmetrics

Маленький пост, важная и очень простая тема.

🦾 Закон Литтла - универсальная взаимосвязь метрик потока

Мы с вами прошлись по Throughput, Lead Time - а как они взаимосвязаны, есть ли формула? Да, закон Джона Литтла! В следующий раз, когда ваш менеджмент/команда будет говорить "да давайте напихаем побольше в спринт" - покажете что это приведет к определенным последствиям.

📜 Чем больше у вас элементов в работе (Work In Progress, WIP) - тем дольше вы делаете каждый элемент (Lead Time) и тем меньше элементов выпускаете (Throughput).

🍣 Что такое WIP на примере суши‑ресторана

WIP — это сколько заказов одновременно «висят» в работе на кухне: повара режут рыбу, варят рис, собирают роллы. Если взять в работу слишком много заказов сразу, очередь расползается, каждый заказ «готовится» дольше, клиенты ждут и нервничают. Если удерживать разумное число параллельных заказов, кухня идёт ровнее и предсказуемее: гости получают еду быстрее, а команда — меньше стресса.

💻 А в IT?

В айти также. У команды куча недоделанных задач? Ну так а зачем размывать фокус и брать все подряд, контролируй количество параллельной работы!

👌 Простота и универсальность

Логика закона Литтла тривиальна в использовании и не требует спецподготовки. В практике она превращается в один вывод: чтобы lead time был меньше, а throughput — выше, нужно не раздувать параллельную работу. Слишком много начатого — значит, мало законченного и долгое ожидание.

🛣 С чего начать с WIP‑лимитов

- Базовая настройка: стартовать с WIP примерно «размер команды + 1».
- Наблюдать пару итераций: если throughput растёт и lead time сокращается — можно пробовать аккуратно снижать WIP дальше.
- Если при снижении WIP throughput падает — лимит задушили, верните на шаг назад.

👨‍🦰Так что наматываем на ус правило: ограничивая параллельную работу, мы управляем и временем поставки (lead time), и пропускной способностью (throughput).

Как правильно прогнозировать, когда команда закончит следующие X задач и причем тут прогнозирование через симуляцию Монте-Карло?

❌ Точную дату говорить не надо "Эпик будет готов ровно через 42 дня" — это неправда.
✅ Правильный прогноз: 10 задач за 35-45 календарных дней, где:
- 35 дней = 50% вероятности
- 45 дней = 85% вероятности

У любого прогноза есть
- Разброс,
- Вероятность,
- Мы предполагаем что работа в будущем будет похожа на работу в прошлом.

Работает следующим образом:

- 1️⃣ Собираем историю throughput команды
- 2️⃣ Запускаем 1000+ симуляций со случайной выборкой
- 3️⃣ Получаем распределение вероятностей

Главное условие: нужны WIP-лимиты!
"Нет WIP-лимита = нет потока = нет предсказуемости" — Daniel Vacanti

👩‍🔬 Исследования и материалы:

- 🖥 На прикрепленной картинке пример прогноза из приложения: Predictable.team (я когда-нибудь переведу его на русский) — загружаете CSV из Jira (или demo data) и тыкаете во вкладку Монте-Карло.

- ActionableAgile доказали: простая случайная выборка работает лучше сложных алгоритмов.
- Российские кейсы (Тинькофф, SportMaster) подтверждают точность 80-90%.
- Daniel Vacanti "Actionable Agile Metrics".
- Моя статья на Хабре
- Материалы на Scrum.ru, Neogenda.

Впрочем, это все неважно если продажники уже подписали контракт, обещая новую фичу клиенту. Но хотя б вы им покажете данные.