🛠️ Инструменты мониторинга метрик команды и что почитать по теме.

Начал смотреть второй сезон Wednesday (который пока так себе).
- 🔥если тоже смотрите сериал
- 🤔если не смотрите

🕵️‍♂️ Где смотреть на метрики вашей команды

- Jira: без плагинов посмотреть на Throughput в задачах не получится и гаджетов для дешборда. Но есть решение ⬇️

- Jira Metrics Plugin (автор @akhakimov, hh.ru) - такой ультимативный плагин для хрома, читает данные с вашей Jira, причем безопасно (на сайте есть целый блок про секурность и его разрешают в этих ваших энтерпрайзах). Я даже у себя на его основе провожу обучение. Скоро будет AI-агент внутри с анализом и рекомендациями 🚀

- Predictable.team (это уже моё приложение): умеет кушать CSV / XLS выгрузки с Jira, Youtrack, кастомные форматы и визуализировать все flow-метрики. В дополнение - есть раздел с выводами по динамике команд и рекомендациям - что делать чтоб стало лучше. 🔮

- ActionableAgile: сильная визуализация флоу‑метрик (scatterplot cycle time, aging WIP, Монте‑Карло). Но для россиян доступ только через VPN. 📈

- Scope360: плагин для хрома и сайт, встраивается в Jira, но если есть Jira Metrics Plugin - будто б и не нужен. 🔭


📚 Список литературы

- Daniel Vacanti — Actionable Agile Metrics for Predictability [EN] — базовая книга по метрикам потока, aging и вероятностным прогнозам.

- Troy Magennis (классный дядька, автор блога observable hq) — вот тут инструменты и калькуляторы, вот тут статьи (что точнее) по прогнозированию и Монте‑Карло (Observable/Focused Objective)

- Bye Bye Velocity. Hello Throughput (статья на Scrum.org). Коротко о причинах сдвига от velocity/SP к потоку.

- Обзорные и критические материалы по SP (иллюзии измерения и сравнения между командами).

- Mike Cohn — Agile Estimating and Planning (полезно как набор практик).

#metrics

Всем привет! Сегодня продолжим покрывать основные метрики потока.

⏰ Lead Time (1/2): погружающий в базу пост.

Опять возьмем суши-бар в качестве примера. Опять приходим в пятницу и заказываем хенд-ролл с тунцом. Точкой отсчета мы считаем Commitment Point (когда ресторан берет на себя обязательство сделать нам хендролл - то есть время приёма заказа).

🍣 Так вот, Lead Time — в классическом понимании это время с момента заказа до момента, когда тебе подали заслуженную пищу богов после лютой рабочей недели. Всё, что тебе важно как клиенту, — когда эта еда окажется во рту и ты закроешь глаза от удовольствия.

👨‍💻В разработке то же самое: коммитмент сделан (пообещали что возьмете в работу) → взята в работу → разработана → протестирована → выкачена в продакшен → пользователь получает ценность. Иногда можно упростить до времени создания тикета, но тут надо быть осторожным и понимать где действительно начинаются ваши обязательства, и где вы ведете Discovery backlog.

💎Почему Lead Time одна из главных метрик потока?

- Это главный ориентир и для клиента ("когда будет готово?"), и для бизнеса (можно ли обещать релиз/фичу).
- По Lead Time видно, насколько реально наша команда быстрая (а не “про субъективную скорость”).

❓ А что и как считать-то?

Вот набралась у тебя статистика по времени завершения роллов / задач / чего угодно.
Когда задают вопрос про Lead Time, многие просто отвечают про “среднее время”.

❌Так вот, среднее в целом очень плохой показатель для анализа (например книжка Flaw of Averages). Среднее очень сильно подвержено выбросам данных, и не отражает реалий.

✅ Настоящие котаны и котанессы смотрят на перцентили вместо среднего. Нам для наглядности надо 50p, 85p, 95p.

- Для простоты - за какое время завершается 50% работы (50p или медиана), 85% работы (85p), 95% работы:
- 50p (медиана) показывает типичную работу. Например, мы можем стараться планировать на основе данных медианы.
- А вот 85p, 95p показывают не только “обычные” случаи, но и экстремальные ожидания.

💼 Примеры:

- "Среднее" время ожидания в суши-баре — 20 минут, но половина получает заказ за 10 минут, а часть ждёт по 40-50.
- Медиана (50p) покажет типичное время (10 минут), а 85p — насколько быстро обслуживают почти всех (40 минут). Это честнее и точнее — клиент меньше разочарован и команда видит, где реальные задержки.)

🏆 Самое главное для нас:

- Чем ближе 50p и 85p - тем вы предсказуемее.
- 85p не должен превышать 50p (медиану) в 3 раза. Но.. везде есть свои приколы и специфика домена.

🧩 Паттерны

- Если 85p намного больше медианы (пример во второй картинке присобаченной)— у вас есть “зависшие” задачи или бутылочные горлышки.
- Если 95p намного больше / выше чем 85p - есть какие-то супер специфические зависшие или зависимые от других команд задачи.

#leadtime #metrics

🚦Time to Market, Lead Time, Cycle Time и почему они про одно и то же?

Расставим точки над "i" после вчерашних дискуссий в @agileufa с Сережей (организатором @UfaJS)

🏗 Базовый термин времени производства: Cycle Time. Это супер-простая идея: выбери любую пару точек на процессе (начало и конец) и посчитай, сколько времени проходит между ними. Главное, после слов Cycle Time указать начало и конец цикла.

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

🧱 Как это работает на практике:

В IT и продуктовых командах часто под термином Cycle Time подразумевают время от момента, когда задача переходит в состояние “В работе”, до момента “Готово”. Это отражает длительность всех активных действий по задаче, исключая время, когда она находилась в бэклоге.

✅ Чтобы быть более точным, стоит обозначать этот показатель как Cycle Time (In Progress -> Closed), а не просто Cycle Time.

Какие еще циклы бывают?
- От “Идея!” до “Go Live” — Time to Market (общая скорость реакции компании на рыночные изменения).
- От “Будет сделано” до “В проде!” — Lead Time (качество планирования и уровень доверия клиентов).

❓ Зачем нам все это?

Если Time to Market, Lead Time не соответствуют нашим ожиданиям, то конкретные циклы внутри них (In Progress -> Closed, а может еще глубже: отдельно цикл Code Review / Ready for Testing / Testing) подсвечивают узкие места. Это наш базовый инструмент диагностики для понимания затыков в работе.

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

А еще большинство времени фича вообще ждет реализации в беклоге. Принимая решения на основе данных (время в беклоге или цикл Created -> Committed) мы можем существенно оптимизировать и балансировать наш поток работы.

🍰 TLDR

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

⚠️ Очень важно, что Time to Market (а зачастую и Lead Time, и Cycle Time (In Progress -> Done) и мы все таки считаем у фичей (новый функционал приносящий ценность), а не у рядовых задач, которые делает кусочек нового функционала.

#timetomarket #cycletime #leadtime #metrics

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

- Посты про метрики были подготовкой к нашему митапу @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).