Классическая методология, используемая «с незапамятных времен». Представляет собой строго последовательное выполнение всех стадий разработки. Иными словами, новая стадия не начинается до тех пор, пока не будет полностью закончена предыдущая.

Каскадная модель очень удобна для управления проектом, поскольку процесс разработки легко отслеживается. Это дает возможность жесткого контроля над процессом разработки, что позволяет достаточно точно заранее определить сроки окончания и общую стоимость проекта.

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

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

Данная методология используется для проектов, предусматривающих несколько вариантов (сборок) готового продукта. Зачастую разработка ведется несколькими циклами, то есть в итоге получается своего рода «мульти-водопад». При этом в каждом цикле имеются свои этапы и создаваемые модули. Для каждого модуля предусмотрены собственные этапы уточнения требований, создания проекта, кодирования, тестирования и т.д.

Инкрементная модель предполагает особую последовательность создания сборок: сначала реализуется основной проект (базовая сборка), затем на ее основе создаются новые сборки с новыми функциями, называемыми «инкрементами».

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

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

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

Важным атрибутом гибкой методологии является проведение непродолжительных ежедневных встреч, которые именуются «Scrum», а также регулярных собраний раз в неделю или реже, именуемых «Sprint».

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