Pavel
Так, еще раз, имерение cycle time по одному участку не имеет смысла и явно является misuse :)
Mikhail
Pavel
вы пробовали?
Нет, я не вижу практической пользы в субоптимизации :)
Pavel
Я понимаю, что таким образом можно искать ограничение, но куда эффективней искать ограничение по queue length на каждом рабочем центре.
Pavel
Pavel
С другой стороны, это может быть как с backlog grooming/backlog refinement
Vladimir
Pavel
Mikhail
ну поздравляю! самое время попробовать
Mikhail
Что нужно сделать чтобы понимать о чём идёт речь
Pavel
Mikhail
Зачем?
это вам решать. использовать новые знания или нет
Pavel
Судя по тому, что я про метрику почитал, это time to market
Alexey
Pavel
Т.е. какую пользу мне даст использование нового названия для метрики?:)
Mikhail
Pavel
Ладно, это риторический вопрос.
Mikhail
Mikhail
👌
Pavel
@mihey911 так вернемся к cycle time - чем же оно не кумулятивное?:)
Mikhail
оно такое кумулятивное как минута это кумулятивная метрика 60 секунд
Pavel
давно единицы измерения стали метриками?
Pavel
Михаил, я могу взять пример из scrum - вот есть burndown chart. Его можно строить по каждому члену dev team?
Mikhail
понимаете, да? :) вы пытаетесь отрезку времени придумать какое-то своё название
Mikhail
такой же бред как мой про секунды и минуты
Mikhail
Mikhail
надо на них переходить!
Pavel
Mikhail
Pavel
Mikhail
формулировка "всеми рабочими центрами" - не верная
Dmitry
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
Может надо другую цитату )
Dmitry
Pavel
Vladimir
Эх, я похоже так и не пойму. Придется книги читать опять
Vladimir
вот нашел пояснение
https://stefanroock.wordpress.com/2010/03/02/kanban-definition-of-lead-time-and-cycle-time/
Vladimir
с картинками )
Mikhail
Vladimir
https://connected-knowledge.com/2015/05/26/cycle-time-revisited/
тут говорится что термин вобще неоднозначный и стоит уточнять что имеется ввиду под ним
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).
Pavel
термин cycle time в контексте канбан-метода выработан LKU как организацией, которая канбан-метод развивает
сам LKU говорит, что вы можете посчитать Cycle time одного этапа, где-то посреди канбан системы. Это вовсе не значит, что вы должны это делать, или это полезно.
Но это можно использовать
НАПРИМЕР, для того, чтобы при внедрении канбан-метода показать команде, что ускорение одного этапа, нихрена не повлияло на lead time
Ок, LKU сложно переопределили термин. Очередное "зачем" в мою копилку вопросов к LKU :)
Dmitry
Dmitry
сделали его как раз максимально простым
Pavel
В итоге вышел срач из-за языка :)
Dmitry
Ну а что вы хотели, им надо отгородиться как-то
Dmitry
Скрам поступил проще, конечно
Dmitry
придумав все термины заново
Pavel
Ооо, про переопределение терминов с scrum я уже пример с грумингом/рефайнментом приводил :)
Dmitry
а чуваки из LKU никогда не отличались хорошей маркетинговой жилкой
Dmitry