Привет 🫂

В продолжение темы про производственные метрики, прежде, чем переходить к следующей метрике, Cycle Time, хочу отметить пару моментов относительно Lead Time.

1️⃣ В моей истории, Lead Time путали с Time to Market, что приводило к тотальному непониманию при разговоре, то есть они называли метрику LT не Lead Time, а Time to Market. И пост был, в том числе для того, чтобы больше не было путаницы что такое Lead Time. Так же печалит, хоть и не удивляет, что, вроде бы, пытающиеся быть серьёзными организации типа Enterprise Agile Russia публикуют отвратительнейшее видео, в котором, помимо прочего, говорится, что LT - это период равный простою после окончания предыдущего этапа работ + времени нахождения задачи на этапе (конкретном), и им пришлось ввести новое понятие Total Lead Time, который, на самом деле, является простым Lead Time’ом. 🤬 Хотя, в целом, достаточно ресурсов с подобными самоинтерпретациями, выдумками и придумками… Поэтому я и посчитала важным в прошлом посте привести стандарты и общеотраслевые источники, на которые имеет смысл полагаться. 2️⃣ Так же, те же люди, которые путали LT с T2M, применяли LT к scrum, хоть и называли иначе. Так вот, метрика LT в scrum ничего не покажет, она бесполезна и в неумелых руках, с коими я как раз столкнулась, вредна. Объясню почему.

LT включает время от момента появления задач в бэклоге до момента поставки на PROD, это мы выяснили в прошлом посте о метриках.

Факты, сопутствующие scrum: 1️⃣ Бэклог может, а зачастую и должен, заполняться минимум на 2-3 спринта вперёд. Часто бэклог заполняется в момент проработки story mapping, то есть в начале проекта/релиза. И далее задачи дополняются/убираются/переприоритизируются. Таким образом, вполне нормальна ситуация, когда какая-то задача появляется и уходит на PROD в течение спринта, а какая-то висит в бэклоге с момента начала проекта до… да хоть до момента вывода продукта из эксплуатации, почему бы и нет? Благодаря лишь этому метрика в scrum показывает погоду на Марсе. По ней нельзя сделать никаких выводов: ни хорошо/плохо, ни ускорились/замедлились… 2️⃣ В конце спринта должен быть продукт, потенциально готовый к поставке. При этом, поставляться на PROD в отдельных случаях продукт будет не каждый спринт, а, например, 1 раз в 2 спринта. Регулярно, но реже. Это время простоя продукта в готовом состоянии так же будет учитываться в LT. Но, с учетом первого, непонятно где “дольше” висит задача - в бэклоге или в “готово к поставке”. Да, тут, конечно, поможет Cycle Time и другие метрики, но у вас нет обязательства катить на PROD каждый спринт, вы должны поставлять продукт тогда, когда заказчик будет готов его принять на PROD. И метрика снова “плывёт”. 3️⃣ Сама задача начинает простаивать в спринте просто потому что scrum. Какие-то задачи закрываются в первые дни спринта, но на PROD они уходят вместе с остальными, в конце спринта, допустим. То есть из-за самой организации процесса в scrum, LT увеличивается.

Я, если честно, так и не поняла, хотя искренне упорно и долго пыталась понять зачем эти ребята мерили LT. Сами они внятно ни разу так объяснить и не смогли 😕

Так вот, не занимайтесь натягиванием очередной бедной совы на глобус. Ей больно! Lead Time хорошо работает в случае с поточным процессом поставок, она имеет смысл быть для задач сопровождения, когда нужно понимать время выполнения обращений от пользователей. Но scrum не про поточность, и он со скрипом подходит к проектам сопровождения, хотя и есть такое в опыте, вполне рабочий вариант. Но… многое зависит от договоренностей с заказчиком и всё-равно нарушались определённые правила scrum…

23.06.2025

#LeadTime