Каскадная модель самая дешевая

При отсутствии потока изменений и изменений на изменения.

Естественно, тк скоуп задач фиксируется на старте проекта

Есть нормативы на изменения. Понятно, что без них ничего не делается, это же проект. Но они не должны определять направление дальнейшего развития, они только корректируют его немного. А вот если изменения определяют дальнейшее развитие, то так называемый ватерфольный процесс становится дороже.

Всегда есть фазы - "Создание Изделия" и "Эксплутация Изделия" , большое количество запросов на измнения приходит на второй фазе.
Однако, если мы не вложились в обеспеченеие целостности (непрерывная поставка, обеспечение качестсва, управление знаниями)  , то эти изменения похоронят продукт. (пример - проект С3)

Где-то есть та грань когда лучше сделать сразу хорошо (а для этого сразу хорошо подумать), чтобы потом не пределывать.

Сделать хорошо легко. Трудно сделать хорошо то, что будет надо.

Иначе получаем всякие грандиозные, хорошо сделанные проекты, которыми никто не пользуется

Накропал небольшую заметку про нестиранные вещи, гонцов с плохими вестями, NBack и канбан )

Захотелось поделиться
https://t.me/antxt/1023

Опять про влияние ограничения незавершёнки на пропускную способность. Не знаю уж сколько повторять что на пропускную это не влияет ровно никак, это влияет на время производства

Пример про светофор (ограничение) на стыке основной и второстепенной дорог из книги The Flow продолжаешь игнорировать?)

Чтобы его не игнорить, его бы неплохо сюда скопировать ибо я эту книгу читал очень давно

Даже в твоём посте в твоём канале ты говорил о добавлении дополнительных сушилок чтобы увеличить пропускную способность. Это никак не связано с wip лимитами

Это то же самое что нанять тестировщиков, если в твоём производственном процессе тестирование стало узким звеном

https://pikabu.ru/story/the_principles_of_product_development_flow_second_generation_lean_product_development_6833329?view=amp

Q8: Принцип связанных очередей: смежные очереди видят вариативность прибытий и обслуживания в зависимости от загрузки.

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

Например, хайвей Лос-Анжелеса. Светофоры придерживают машины на въезде и впускают их строгими регулярными порциями. Таким образом система борется с волнами прибытий, когда большая порция машин пытается въехать на хайвей и тормозит весь поток. При этом возникают волны, т.к. машины на хайвее тормозят, пропуская въезжающий поток, и это торможение распространяется дальше.

Controlling Flow under Uncertainty

One of the hallmarks of this book is the use of some unexpected sources for models of behavior. In this chapter, Reinertsen uses traffic control systems because they must adapt to constantly changing and uncertain conditions — accidents happen. Weather happens. Street repair happens. Some of these things happen on a schedule that can be anticipated and others cannot. Sound familiar?

What we learn from this example is that flow is a product of speed and density. Furthermore, small changes in either can have a profound effect on flow. When either goes up significantly, congestion quickly ensues. As we already know, congestion for product developers means bigger queues, higher capacity utilization, delays and higher costs. How to manage this?

One of the best examples of what Reinertsen calls “controlled occupancy” is familiar to Californians. It is what they refer to as the “ramp meter.”



Ramp meters control the volume of vehicles on the freeway and thereby increase flow without actually limiting access. We can use similar mechanisms to manage WIP level. Ideas such as cadence, forecasting and synchronization are discussed. As is the case throughout the book, concepts introduced elsewhere are interwoven. Capacity utilization is revisited with an eye towards determining the correct margin to leave available to ensure higher flow rates.

https://www.bptrends.com/principles-of-product-development-flow-second-generation-lean-product-development-by-donald-g-reinertsten/

ну и шикарный пример, светофор регулирует количество машин на хайвее и это приводит к снижению LeadTime - времени от того как машина вьедет на хайвей и выедет с него. На пропускную способность это не влияет. Точнее есть влияния на крайне низких значениях лимита (сделай так, чтобы была всего одна машина на хайвее) - у тебя будет чудовищно низкая пропускная способность, увеличь WIP Limit до 2 и у тебя пропускная способность удвоится, развяжи еще лимит и она опять увеличится. Но потом будет ОГРОМНЫЙ диапазон лимитов количества машин в системе при котором влияния не будет НИКАКОГО, но с ростом числа машин начнет увеличиваться LeadTime. И только при лимите, при котором утилизация дороги будет очень большой у нас может начать падать пропусная способность. И вот эти диапазоны на которых влияние есть - крайне малые, ими тупо можжно принебречь. При этом многие хотят сказать, что уменьшение лимита увеличит пропускную способность, но это не так, на крайне низких значениях лимита пропускная способность только уменшится. НО! есть хорошая новость, есть инструменты воздействия на систему к которым пропускная способность более чувствительная, например в примере с дорогой - расширение дороги, вот эта штука поднимет пропускную способность, а также технологические решения типа разгонных полос

Текста книги под рукой нет. Вот ссылка ещё https://blog.danslimmon.com/tag/queueing-theory/

In some cities (Minneapolis and Los Angeles, for example), highway occupancy is controlled during rush hour by traffic lights on the on-ramp. The light flashes green to let a single car at a time onto the highway, and the frequency at which that happens can be tuned to the current density of traffic. It’s a safeguard against an abrupt increase in density shoving throughput over the peak into congestion collapse.

С уточнением, что влияние наблюдается в пределе нагрузки - соглашусь, в тексте выше речь как раз о часе пик (rush hour).

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

еще раз, эту идею я покупаю если речь будет для ограничения ради того, чтобы время перемещения автомобиля было меньше, а не пропускная способность

Человек не робот(хотя они уже близки) и у него есть мозги, которые позволяют принимать правильные решения. Быть фанатиком одного способа решения задачи это как молотком забивать гвозди, болты и шурупы :-) И все юморные картинки про то как каждая методология решает одинаковую задачу есть пример "молотка".

Hello, есть тут кто-нибудь с опытом Настройки SAFe в JIRA?