Agile vs Waterfall
Тема дорожной карты · Agile / Scrum / Kanban
Waterfall — последовательный процесс: требования → дизайн → разработка → тестирование → деплой, каждый этап полностью завершается до начала следующего. Agile — итеративный: каждый цикл (обычно 1-4 недели) выдаёт работающий продукт с учётом обратной связи прошлого цикла. Waterfall работает, когда задача полностью понятна заранее (системы наведения, регулируемое железо); agile — когда discovery происходит в процессе, что описывает большинство современных проектов.
Как это работает
Механическое различие — размер батча. Waterfall — один гигантский батч: сначала все требования, потом весь дизайн, потом весь код, потом всё тестирование. Обратная связь приходит только в конце. Agile нарезает ту же общую работу на много мелких батчей, каждый даёт пригодный output. Статистически: системы с маленькими батчами учатся быстрее (каждый батч — измерение), но имеют выше overhead на батч (у каждого цикла своё планирование, демо, ретро). Точка безубыточности — проекты, где пользователи точно знают, что хотят, и не передумают — это редко в software, часто в регулируемом железе.
Когда применять
Выбирайте waterfall когда (а) требования зафиксированы извне и доказуемо корректны, (б) цена изменения в полёте огромна (системы наведения, медицинская техника, контракты с обязательными приёмочными gate), (в) работу нельзя нарезать на независимо отгружаемые куски. Выбирайте agile когда (а) строите для неизвестного пользователя, (б) рыночные условия двигаются быстрее проекта, (в) команда может демонстрировать работающее ПО каждый цикл. Большинство internal-IT и B2C SaaS-проектов — agile-лагерь.
Типичные ошибки
Антипаттерн 'Scrum-fall' (Forrester 2011) — это когда организация запускает Scrum внутри waterfall-оболочки: маркетинг законтрактовал 6-месячный релиз с фиксированным scope, поэтому команда проводит спринты, но не может реально менять scope или релизить раньше. Результат — agile-церемонии, waterfall-ограничения, фрустрация обеих сторон. Чинить нужно оболочку, а не команду.