Без заголовка

Скрам -- это отнюдь не весь agile, там ведь много разных школ, в том числе и более приспособленных к реалиям больших проектов. Кроме того, "процессы" это тоже только одна из парадигм, в обсуждении agile более пригодна парадигма практик+управления кейсами (хотя и проектная парадигма тоже хороша, оценки времени-то выполнения в крупных проектах тоже нужно делать). Конечно, в современном инженерном agile есть инструментально поддержанные практики верификации и управления конфигурацией -- так что всегда хорошо понятно, на чём стоит верификационная подпись, и какая при этом проводилась верификация тем, кто ставит эту подпись. Ничего необычного, хотя современный инструментарий позволяет существенно облегчить и верификацию и управление конфигурацией, а также выполнение координационных практик (типа "подписывание"). Ну, и современная инженерия различает валидацию (по отношению к user needs) и верификацию (где проверяется, насколько хорошо выполнена спецификация, составленная самими инженерами). Так что потихоньку дело идёт. Водопад это не просто модель финансирования. Пошаговое выделение финансирования не эквивалентно водопаду. И даже в современной трактовке гейты (все эти майлстоуны "графиков верхнего уровня" -- их когда три всего, а когда и штук восемь проектах типа строительства АЭС) необязательно должны быть водопадными, просто это моменты сбора полной конфигурации и дополнительной верификации и оценки рисков (я тут поминал Boehm, он как раз этим озабочен больше всего: стыковкой инженерных практик и менеджерских практик, модели финансирования и модели разработки). А что любым топором можно либо по полешку, либо по пальцу -- это и так понятно. Но топор должен быть острым. Понятно, что agile можно извратить как угодно, равно как и водопад и все их возможные гибриды. Но это не повод прекращать обсуждать способ организации разработки, вид жизненного цикла и поддерживающий их инструментарий.