Dmitry
Дмитрий, честно говоря я никогда не видел, чтобы термин Customer Lead Time активно использовался. Это либо какой-то внутренний термин из мира LCU, либо европейская фича :)
LKU и "европейская фича" – это почти синонимы в этом контексте)) но это вообще проблема канбан-метода в рф, его никто не знает, кроме тренеров lku и пары компаний
Pavel
Так, еще раз, имерение cycle time по одному участку не имеет смысла и явно является misuse :)
Pavel
вы пробовали?
Нет, я не вижу практической пользы в субоптимизации :)
Pavel
Я понимаю, что таким образом можно искать ограничение, но куда эффективней искать ограничение по queue length на каждом рабочем центре.
Pavel
С другой стороны, это может быть как с backlog grooming/backlog refinement
Mikhail
Нет, я не вижу практической пользы в субоптимизации :)
именно. эта метрика нужна, чтобы доказать отсутствие пользы субоптимизации
Mikhail
С другой стороны, это может быть как с backlog grooming/backlog refinement
не, в LKU Три термина - customer lead time, lead time, cycle time. Это из их концепции сервиса и разных типов коммитмента вышло
Pavel
не, в LKU Три термина - customer lead time, lead time, cycle time. Это из их концепции сервиса и разных типов коммитмента вышло
Михаил, я верю, что у них есть три термина, и customer lead time в их числе. Я говорю о том, что я не встречал испольование этого термина на практике и не видел метрик на его основе в реальных системах.
Mikhail
ну поздравляю! самое время попробовать
Mikhail
Что нужно сделать чтобы понимать о чём идёт речь
Mikhail
Зачем?
это вам решать. использовать новые знания или нет
Pavel
Судя по тому, что я про метрику почитал, это time to market
Mikhail
Что нужно сделать чтобы понимать о чём идёт речь
можно с вот этой штуки начать, если интересен Kanban method http://kanbanguide.ru/wp-content/uploads/2018/02/Essential-Kanban-Condensed-v1.0.01.02-_rus.pdf
Alexey
Что нужно сделать чтобы понимать о чём идёт речь
Посмотреть видео и прочитать ещё раз :)
Pavel
Т.е. какую пользу мне даст использование нового названия для метрики?:)
Pavel
Ладно, это риторический вопрос.
Pavel
Какое такое видео?🙈
https://www.youtube.com/watch?v=isu6MG3v0-s
Mikhail
👌
Pavel
@mihey911 так вернемся к cycle time - чем же оно не кумулятивное?:)
Mikhail
оно такое кумулятивное как минута это кумулятивная метрика 60 секунд
Pavel
давно единицы измерения стали метриками?
Pavel
Михаил, я могу взять пример из scrum - вот есть burndown chart. Его можно строить по каждому члену dev team?
Mikhail
понимаете, да? :) вы пытаетесь отрезку времени придумать какое-то своё название
Mikhail
такой же бред как мой про секунды и минуты
Mikhail
надо на них переходить!
Dmitry
@mihey911 так вернемся к cycle time - чем же оно не кумулятивное?:)
cycle time - кумулятивное время выполнения задачи всеми рабочими центрами. Вот эта формулировка была неверная, почему вы к слову "кумулятивное" привязались?
Pavel
понимаете, да? :) вы пытаетесь отрезку времени придумать какое-то своё название
Я честно говоря совсем не уловил релевантность аргумента :)
Mikhail
формулировка "всеми рабочими центрами" - не верная
Vladimir
cycle time - кумулятивное время выполнения задачи всеми рабочими центрами. Вот эта формулировка была неверная, почему вы к слову "кумулятивное" привязались?
А почему неверна. Павел давал цитату. "Cycle time clock starts when work begins on the request and ends when the item is ready for delivery." от работа началась и до поставки - разве это не суммарное время в прогрессе? Не могу понять )
Pavel
это вы придумали)
Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery.
Pavel
Вот я и прошу указать мне ту тонкую разницу, которая делает cycle time НЕ кумулятивным временем прохождения задачи по всем рабочим центрам.
Vladimir
Мой английский, конечно, оставляет желать лучшего. (да и русский) Но все таки предложение довольно однозначно говорит
Mikhail
всё. я сдаюсь
Pavel
Михил, рано сдаетесь, вы еще не объяснили
Mikhail
придумывайте себе какие хотите объяснения
Pavel
Но ок.
Vladimir
Может надо другую цитату )
Mikhail
Михил, рано сдаетесь, вы еще не объяснили
я не вижу смысла вам что-то доказывать. зачем?
Pavel
НЕ ПО ВСЕМ ЦЕНТРАМ а по тем, по которым вы решили посмотреть, ВКЛЮЧАЯ по одному
Эмн. Уточните, а для чего эта метрика в таком случае нужна?
Vladimir
Эх, я похоже так и не пойму. Придется книги читать опять
Vladimir
вот нашел пояснение https://stefanroock.wordpress.com/2010/03/02/kanban-definition-of-lead-time-and-cycle-time/
Vladimir
с картинками )
Dmitry
Эмн. Уточните, а для чего эта метрика в таком случае нужна?
например для того, чтобы показать, что локальная оптимизация почти не повлияла на lead time
Vladimir
https://connected-knowledge.com/2015/05/26/cycle-time-revisited/ тут говорится что термин вобще неоднозначный и стоит уточнять что имеется ввиду под ним
Pavel
например для того, чтобы показать, что локальная оптимизация почти не повлияла на lead time
Дмитрий, вот смотрите: когда я использую cycle time в том виде, в котором выше описал, я вижу, какая у меня статистически достоверная пропускная способность системы, а сравнивая cycle time с lead time - могу понять, какая у меня ожидаемая длинна очереди для случайной входящей карточки.
Pavel
Если я начинаю измерять сyсle time по выбранным рабочим центрам, то что я получаю?
Dmitry
Cycle time это ТЕРМИН, используйте что хотите
Dmitry
я объяснял суть термина
Dmitry
а не то, что нужно или не нужно мерить
Pavel
Дмитрий, термин не может существовать в отрыве от реальности. Более того, если не разводить долгие споры о семантике, ваше пояснение от моего не отличается: измерение по выбранным рабочим центрам, а не по всем, должно иметьс мысл и трактовал его в значении "по тем, по которым прошла карточка", а "добавлять по одному" - меод вычисления той самой кумулятивности.
Pavel
Если я неверно трактовал, то поясните СМЫСЛ этого измерения
Pavel
Потому что, повторюсь, метрика не может существовать в отрыве от реальности. Что конкретно она измеряет и для чего?
Dmitry
Дмитрий, термин не может существовать в отрыве от реальности. Более того, если не разводить долгие споры о семантике, ваше пояснение от моего не отличается: измерение по выбранным рабочим центрам, а не по всем, должно иметьс мысл и трактовал его в значении "по тем, по которым прошла карточка", а "добавлять по одному" - меод вычисления той самой кумулятивности.
термин cycle time в контексте канбан-метода выработан LKU как организацией, которая канбан-метод развивает сам LKU говорит, что вы можете посчитать Cycle time одного этапа, где-то посреди канбан системы. Это вовсе не значит, что вы должны это делать, или это полезно. Но это можно использовать НАПРИМЕР, для того, чтобы при внедрении канбан-метода показать команде, что ускорение одного этапа, нихрена не повлияло на lead time
Dmitry
особого смысла мерить cycle time вообще – нету, как только вы осознали, что вместо этого надо ориентироваться на lead time
Dmitry
лучше смотреть на эффективность потока и CFD
Pavel
лучше смотреть на эффективность потока и CFD
Это да, но многое зависит от уровня зрелости системы. + cycle time полезен при поставке пакетами (т.е когда в конечно статусе накапливается пакет завершенных карточек перед release/deploy).
Dmitry
Ок, LKU сложно переопределили термин. Очередное "зачем" в мою копилку вопросов к LKU :)
выше как раз ответ https://t.me/agile_ru/46851 переопределили, потому что термин засрался
Dmitry
сделали его как раз максимально простым
Pavel
выше как раз ответ https://t.me/agile_ru/46851 переопределили, потому что термин засрался
Потому что кроме LKU есть еще sick stigma в смысле SixSigma, которая тоже переопределяет термины, и есть еще TPS, которая теоретически и есть Lean, но очень старая и плохо формализованная.
Pavel
В итоге вышел срач из-за языка :)
Dmitry
Ну а что вы хотели, им надо отгородиться как-то
Dmitry
Скрам поступил проще, конечно
Dmitry
придумав все термины заново
Pavel
Ооо, про переопределение терминов с scrum я уже пример с грумингом/рефайнментом приводил :)
Dmitry
а чуваки из LKU никогда не отличались хорошей маркетинговой жилкой