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

А вопрос команды – это уже нетехнологическая проблема (безусловно не менее больная).

Я бы сказал так… В целом, конечно agile сейчас перерекламирован. То есть много шума, результаты … ну скажем, разные.

С другой стороны, как по мне одна из проблем именно в том, что «отцы» agile скази – так как методика гибкая, адаптируйте ее под команду. Это не учитывает то, что не у всех есть опыт, знания и умения, как правильно адаптировать. Результатом зачастую получается – Agile по названию, waterfall по содержанию. Ну и получается, что все те же проблемы вылазят, что были раньше.

Я бы очень ратовал, за то, что был бы минимальный список требований Agile (которые составляли бы его ядро). Чтобы люди адаптируя не могли похерить все его преимущества.

А в целом Agile таки лучше Waterfall. Одна из самых полезных вещей в нем, что они отталкиваются от более реалистичных идей. Waterfall отталкивается от идеи, что все (требования, объемы работ и т.п) можно спрогнозировать (причем достаточно точно) и что оно потом меняться не будет. Agile – что спрогнозировать можно только приблизительно (статистически) и меняться оно таки будет активно. И естественно, отталкиваясь от более актуальных фактов, можно получать более актуальные результаты.

С убрать нееобходимость – я погорячился. То, что я сказал, что они могут уменьшить риски появления багов, но не могут уменьшить длительность регрессионного тестирования.

По поводу убрать необходимость: Ну, а её и не надо убирать. Куда ж без регрессии-то.

По поводу п. №0: Слепое адаптирование это оксюморон. Типа «прицельная стрельба вслепую».
Я говорил о том, что нужно брать от методологии лучшее, а не слепо следовать. Так же как сборная солянка наиболее удачных идей из разных методологий тоже скорее всего работать не будет (или будет, но не так, как хотелось бы).

Пункт N1. Скажем так, умный product owner и team lead могут частично минимизировать риски. Но убрать необходимость регрессионого тестировани они не могут.

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

Кстати, я удивлен насколько короткий у вас стабилизационный период.

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

Делать полное или частичное, но большое перетестирование каждый спринт – это нереально, для любого достаточно крупного продукта.