Встречный вопрос - что должно релизиться не раз в полгода в среднестатистической компании для бизнес-приложения, который автоматизирует, например, управленческий учёт? Или расчет на то, что фанаты новых технологий из ИТ-службы будет постоянно рефакторить, менять платформы и внедрять новые плюшки?
Ещё раз, никто не говорит, что что одно - это априори плохо, а другое - хорошо (почти никто в этом чате😉). Речь о том, что всему своё место, и пока у довольно большого количества компаний бизнес - и соответственно ИТ-экосистема не меняется с такой частотой и на таком уровне сложности, чтобы микросервисы были безоговорочно оправданы.

Цикл тестирования

Про тестирование микросервисов тут довольно правдоподобно написано.

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

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

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

Ну так цена же!! Конечно, все можно и некоторым удается, но какой ценой?!

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

Кроме того Канбаном технические проблемы не лечатся. А на прещентациях много чего говорят

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

Без полного регресса такой релиз рискованно ставить. Но разве только хотфиксы

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

Зачем вы заочно на Лобасева наезжаете? Он отчитывался о реальном достижении.

Я ничего не имею против работы Скрамтрек. Они вообще молодцы. Но внедрение agile само по себе технических проблем не решает. Оно создают новую инженерную культуру. В которой команда зачастуюама решает переходить на msa