Да и сама ‘Agile-движуха’ была популярна в банке в 2017 — сейчас она в значительной степени законсервирована

Agile не гарантирует соблюдение графика в длительной перспективе. Невозможно спланировать  проект разработки софта на полгода по скраму и в самом начале проекта  иметь чёткое ощущение, что времени и ресурсов хватит сделать его в срок.

Согласен.

А существует-ли методология, которая ‘гарантирует выполнение графика в длительной перспективе’?

Существует.

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

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

+

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

мне вот интересно, а в производстве что используют. особенно в больших, когда 100500 субподрядных организаций и производство/доставку и т.д. всех частей нужно учесть в процессах. неужто туда тоже "стильно, модно, молодежно" пихают?

Да по всякому бывает

А так теже канбаны это же корнями в lean уходит например производственная система тайоты, всякие just in time, разные кайдзен и гемба. Это все как раз с производства. На газе и камазе кайдзен с гембой

Да и без этого половина практик. На производстве похожи на скрамы со своими стендапами-планерками

Это "модное и молодежное» в 90х еще на производстве проходили

90х? Стенды, которые мы тестовыми называем, на заре космонавтики активно использовались. Методологии - все уже в начале 20 века были в том или ином виде. ИТ как отрасль только-только доросла до взрослой инженерии, с процессами, результатами, ответственностью... Ну почти. То и дело заново что-то открываем. Хотя все уже придумано до нас, нефиг тут выдумать, работать надо ;)

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

> То и дело заново что-то открываем. Хотя все уже придумано до нас, нефиг тут выдумать, работать над

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

а пока у человека все время уходит на технологии и написание кода, когда он изучать управление-то будет?

Учиться, учиться и еще раз учиться! Это непосредственная основная обязанность молодого инженера. Ну и не молодого тем более ;)

Про велосипеды и играющего тренера - ох, как вы правы.

Играющий тренер - это как командир роты, который вместо управления боем схватил автомат и начал ловко набивать фраги. Это все. Финал. Управление потеряно, подразделение уничтожено. Не надо так делать.

вот именно так. И оттого когда я вижу, что СТО компании на 300чел идет собеседовать разработчика, что на пару-тройку уровней ниже его, или еще какую дичь — хочется кричать, ребята, вы чо?

Про учиться — согласен полностью. Иметь время на обучение. Убирать непосредственно программирование из своих обязанностей,если ты руководитель. ЗАниматься своим делом.

И не бомбить, когда зп такого начинающего руководителя будет _ниже_толкового программиста 🙂