PO
Т.е. почему это именно «основная» метрика?
Size: a a a
2020 January 17
AP
Алексей, а можно я ещё раз спрошу: что такого важного в эффективности потока при наличии первых трёх метрик?
паервые три метрики не показывают ничего про то, сколько во времени производства работы. FE дает понимание потенциала для улучшений, после него надо лезть в детали
AP
Т.е. почему это именно «основная» метрика?
дальше идут специфичные метрики типа количества отказов и т.п.
PO
Кстати я бы в основные ещё %CA в любой форме поставил.
PO
паервые три метрики не показывают ничего про то, сколько во времени производства работы. FE дает понимание потенциала для улучшений, после него надо лезть в детали
Я не очень расшифровал.
Т.е. если есть частота выпуска, частота, гм, впуска и SLA, зачем на постоянной основе ещё и throughput мерять? Т.е. почему именно его, а не takt time по участкам заодно, например? Не cycle time? Не WIP в любой форме?
Т.е. я понимаю ценность throughput, я не понимаю, почему она - «основное».
Т.е. если есть частота выпуска, частота, гм, впуска и SLA, зачем на постоянной основе ещё и throughput мерять? Т.е. почему именно его, а не takt time по участкам заодно, например? Не cycle time? Не WIP в любой форме?
Т.е. я понимаю ценность throughput, я не понимаю, почему она - «основное».
AP
Я не очень расшифровал.
Т.е. если есть частота выпуска, частота, гм, впуска и SLA, зачем на постоянной основе ещё и throughput мерять? Т.е. почему именно его, а не takt time по участкам заодно, например? Не cycle time? Не WIP в любой форме?
Т.е. я понимаю ценность throughput, я не понимаю, почему она - «основное».
Т.е. если есть частота выпуска, частота, гм, впуска и SLA, зачем на постоянной основе ещё и throughput мерять? Т.е. почему именно его, а не takt time по участкам заодно, например? Не cycle time? Не WIP в любой форме?
Т.е. я понимаю ценность throughput, я не понимаю, почему она - «основное».
takt time бесполезен в нашем случае ибо поток работ не гомогенный. takt time будет скакать
PO
takt time бесполезен в нашем случае ибо поток работ не гомогенный. takt time будет скакать
Да, это я его зря тут упомянул :)
AP
Я не очень расшифровал.
Т.е. если есть частота выпуска, частота, гм, впуска и SLA, зачем на постоянной основе ещё и throughput мерять? Т.е. почему именно его, а не takt time по участкам заодно, например? Не cycle time? Не WIP в любой форме?
Т.е. я понимаю ценность throughput, я не понимаю, почему она - «основное».
Т.е. если есть частота выпуска, частота, гм, впуска и SLA, зачем на постоянной основе ещё и throughput мерять? Т.е. почему именно его, а не takt time по участкам заодно, например? Не cycle time? Не WIP в любой форме?
Т.е. я понимаю ценность throughput, я не понимаю, почему она - «основное».
на throughput мы смотрим - потому как это характеристика потока. Смотри, ты что-то кому то поставляешь. Есть время с которым проискодит поставка и объем поставки за время. Если зажать объем одновременной работы, то время поставки сократится, но и объем поставки сократится. Если делать много всего одновременно, то время поставки увеличится и объем поставки увеличится. При этом зависимости будут сильно нелинейными и нам надо искать такой объем одновременного производства, при котором все еще маленькое время производства и все еще большой объем поставки
PO
на throughput мы смотрим - потому как это характеристика потока. Смотри, ты что-то кому то поставляешь. Есть время с которым проискодит поставка и объем поставки за время. Если зажать объем одновременной работы, то время поставки сократится, но и объем поставки сократится. Если делать много всего одновременно, то время поставки увеличится и объем поставки увеличится. При этом зависимости будут сильно нелинейными и нам надо искать такой объем одновременного производства, при котором все еще маленькое время производства и все еще большой объем поставки
Слушай, хуже стало. Давай на примере.
Вот смотри, мы меряем, скажем, Lead Time, время между поставками и %SLA (я взял прокси для частоты входа и понимаю, что не всегда Lead Time эквивалентен частоте входа, просто для упрощения).
С метрикам все хорошо, %CA тоже в пределах отраслевой нормы.
Какую критично важную информацию я не вижу, и как мне ее добавит именно throughput?
Т.е. я бы посмотрел ещё на WIP, это мне связанный капитал покажет. Или на длину очереди между участками (ну или любое соотношение между process и wait time) - тоже говорит об эффективности системы.
Чем именно throughput лучше?
Вот смотри, мы меряем, скажем, Lead Time, время между поставками и %SLA (я взял прокси для частоты входа и понимаю, что не всегда Lead Time эквивалентен частоте входа, просто для упрощения).
С метрикам все хорошо, %CA тоже в пределах отраслевой нормы.
Какую критично важную информацию я не вижу, и как мне ее добавит именно throughput?
Т.е. я бы посмотрел ещё на WIP, это мне связанный капитал покажет. Или на длину очереди между участками (ну или любое соотношение между process и wait time) - тоже говорит об эффективности системы.
Чем именно throughput лучше?
AP
он не лучше, он часть картины
AP
можно делать все за 5 дней и иметь пропускную способность 1 фича в неделю, а можно делать все за 10 дней и иметь пропускную способность 3 фичи в неделю (а не две как можно было бы подумать)
PO
можно делать все за 5 дней и иметь пропускную способность 1 фича в неделю, а можно делать все за 10 дней и иметь пропускную способность 3 фичи в неделю (а не две как можно было бы подумать)
И это при неизменных прочих трёх параметрах?
PO
Ладно, перечитаю завтра на свежую голову.
Пока мне кажется, что %complete and accurate или любой адекватный заменитель будут лучше в качестве «основной» :)
Throughput, впрочем, вреда не принесёт.
Пока мне кажется, что %complete and accurate или любой адекватный заменитель будут лучше в качестве «основной» :)
Throughput, впрочем, вреда не принесёт.
D
Message from 曹款 deleted. Reason: new user and forwarded (?)
SG
(Уважаемые лесовики, это не в вашу сторону наброс)
Сообщество, можете посоветовать какие-то инструменты для визуализации зависимостей между командами, кроме program board в SAFe.
Есть 12 команд (и скоро будет ещё 5), которые работают над огромным продуктом.
Есть компонентные зависимости: каждая команда (реже две) разрабатывает свою независимую часть и эти части по отдельности имеют смысл, но все чаще встречаются «бизнес»-требования, для реализации которых одной команде нужно использовать функционал, написанный другой командой, причём часто с ожиданием, что этотфункционал будет доработан: всякие дополнительные методы в апи, новые ожидания по нагрузке и т.п.
Команды готовы перейти на какой-то scaling (SAFe, LeSS, гибрид - что угодно), но до перехода хотят, чтобы проблема с пониманием зависимостей была хотя бы визуализированна чтобы видеть масштаб.
Сообщество, можете посоветовать какие-то инструменты для визуализации зависимостей между командами, кроме program board в SAFe.
Есть 12 команд (и скоро будет ещё 5), которые работают над огромным продуктом.
Есть компонентные зависимости: каждая команда (реже две) разрабатывает свою независимую часть и эти части по отдельности имеют смысл, но все чаще встречаются «бизнес»-требования, для реализации которых одной команде нужно использовать функционал, написанный другой командой, причём часто с ожиданием, что этотфункционал будет доработан: всякие дополнительные методы в апи, новые ожидания по нагрузке и т.п.
Команды готовы перейти на какой-то scaling (SAFe, LeSS, гибрид - что угодно), но до перехода хотят, чтобы проблема с пониманием зависимостей была хотя бы визуализированна чтобы видеть масштаб.
Каждая команда в LeSS должна уметь делать ЛЮБОЙ элемент бэклога, код общий. Естественно с разной степенью эффективности. Если в команде не хватает компетентностей - она обучается, другие команды помогают. Поэтому компонентных зависимостей быть не должно в идеале. Видимо в примере компонентные команды, раз одной команде нужны API сделанные другой. Я допускаю, что есть в мире Продукты, которые прошивают сотни систем. Но думаю тут больше проблема в архитектуре и в определении Продукта. На своем опыте могу сказать, что мы в своей работе (7 команд) не сталкиваемся с подобным явлением. Лично мое такое мнение.
SK
Каждая команда в LeSS должна уметь делать ЛЮБОЙ элемент бэклога, код общий. Естественно с разной степенью эффективности. Если в команде не хватает компетентностей - она обучается, другие команды помогают. Поэтому компонентных зависимостей быть не должно в идеале. Видимо в примере компонентные команды, раз одной команде нужны API сделанные другой. Я допускаю, что есть в мире Продукты, которые прошивают сотни систем. Но думаю тут больше проблема в архитектуре и в определении Продукта. На своем опыте могу сказать, что мы в своей работе (7 команд) не сталкиваемся с подобным явлением. Лично мое такое мнение.
Не обязательно же, чтобы все команды в лесс должны быть фиче-командами?
DK
Каждая команда в LeSS должна уметь делать ЛЮБОЙ элемент бэклога, код общий. Естественно с разной степенью эффективности. Если в команде не хватает компетентностей - она обучается, другие команды помогают. Поэтому компонентных зависимостей быть не должно в идеале. Видимо в примере компонентные команды, раз одной команде нужны API сделанные другой. Я допускаю, что есть в мире Продукты, которые прошивают сотни систем. Но думаю тут больше проблема в архитектуре и в определении Продукта. На своем опыте могу сказать, что мы в своей работе (7 команд) не сталкиваемся с подобным явлением. Лично мое такое мнение.
Смотря что называть продуктом.
Решения, где "фича" в понимании конечного пользователя прошивает решение насквозь, есть.
Если считать каждый модуль такого решения продуктом, будет одна картина. Если все решение целиком - другая.
Решения, где "фича" в понимании конечного пользователя прошивает решение насквозь, есть.
Если считать каждый модуль такого решения продуктом, будет одна картина. Если все решение целиком - другая.
SG
Не обязательно же, чтобы все команды в лесс должны быть фиче-командами?
Есть мнение, что в любом случае их должно быть большинство. Но только если это не вызывает проблем при работе, в том числе вышеописанных с зависимостями. И в любом случае они должны быть кросс-функциональными. Если бэклог позволяет работать части команд только с компонентой, то норм. Зависит от контекста.
DK
Да, там 7 команд на модуль. На все решение кратно больше.
MV
Denis Kachnov
Смотря что называть продуктом.
Решения, где "фича" в понимании конечного пользователя прошивает решение насквозь, есть.
Если считать каждый модуль такого решения продуктом, будет одна картина. Если все решение целиком - другая.
Решения, где "фича" в понимании конечного пользователя прошивает решение насквозь, есть.
Если считать каждый модуль такого решения продуктом, будет одна картина. Если все решение целиком - другая.
В Less продукт максимально широкий с точки зрения пользователя. Настолько, насколько это практически возможно.