Никаких "водопадных моделей" в том смысле, как её описывают пропагандисты agile, в реальности в разработке софта никогда не существовало, это миф, придуманный борцами за всё хорошее против всего плохого. Agile пришёл на смену unified process (RUP как наиболее известной его разновидности), который по природе уже итеративный и вполне себе предполагает, например, активности по аналитике и проектированию вплоть до самого конца итерации.
Существовала модель вида:
- начальник с заказчиком разбивают проект на этапы по полгода
- методом 3П (три пэ) кто-то формирует скоупы этапов, предполагая, что сделав часть продукта на этапе 1 не надо будет к нему возвращаться на этапе 2 и 3
- аналитики и программисты в очередной раз охреневают от оценок и объёмов спецификаций, но уже поздно что-то менять, так как сроки, объемы и выплаты уже согласованы
- аналитики формируют ТЗ и спецификации (по несколько месяцев), игнорируя правило «пишешь спеку на новый этап — не трожь прошедший»
- программисты на реализации этапа N вынуждены менять предыдущие этапы 1...N-1, так как иначе оно либо не скомпилируется (в лучшем случае), либо не взлетит (в худшем)
Отличие agile от стандартной водопадной разработки, как её видел на практике (возможно она была не по всяким RUP) — обязательность обратной связи по срокам реализации как часть рабочего процесса. А не просто как отписка одного человека «ок» на документе с оценкой сроков. В результате вместо задачи «уложись с данными ресурсами в указанный срок по фиксированному обьему» решается задача «что мы можем впихнуть в указанный срок по ресурсам в релиз».
Как только до организаторов процесса доходит, что формирование скоупа очередного релиза N происходит по итогам обсуждения сроков и деталей, причём ближе к выпуску релиза N-1, а не к началу проекта, как только это превращается из «процедуры исправления факапа» в BAU (business as usual) рабочий процесс, в этот момент, с моей точки зрения, мы и переходим от нездорового водопада к нездоровому scrum.
Допускаю, что где-то в глубинах RUP есть и соответствующие scrum-механизмы обратной связи при формировании скоупов и оценок. Вот только они оказались настолько погребены под ворохом правил о use case'ах, взаимодействиях и протоколах согласования документов сторонами, что про них просто не вспоминают на практике. В то время как в scrum это краеугольный камень организации процесса, что не позволяет его выкинуть (особенно при насаждении "снизу", а не как в СберДжайл).
