Реальная разница такая.

Waterfall - это контракт. Ты обещаешь конкретный продукт в конкретный срок за конкретные деньги. Заказчик подписывает. Дальше любое изменение требований - это допсоглашение с новой ценой и новым сроком. Заказчик это ненавидит, но зато у него есть иллюзия предсказуемости.

Agile - это отношения. Ты обещаешь двигаться в правильном направлении и регулярно это показывать. Заказчик получает контроль в обмен на свое время. Это честнее, но требует доверия.

Проблема большинства "Agile" проектов в том что они на самом деле не Agile. Менеджер хочет гибкость без потери предсказуемости. Заказчик хочет менять требования без последствий для сроков. Итог - ScrumFall: спринты есть, а реального управления беклогом нет, и дедлайны рисуются по Waterfall-логике. Это худший из двух миров.

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

Заранее пропиши в каком то документе (пусть это будет даже просто письмо в почте) как принимаются изменения требований и что они влияют на сроки. Иначе через 6 месяцев услышишь "мы же договаривались" - и никто не вспомнит о чем именно.

Waterfall не такой плохой как его малюют. Если бы вы потратили 2-3 недели нормально на сбор требований с комдиром, провели грамотный анализ и написали хорошее ТЗ - Waterfall вполне себе работал бы. Проблема не в методологии, а в том что никто не хочет инвестировать время в нормальный анализ. Agile часто выбирают именно чтобы не думать наперед - и потом удивляются что получился хаос.

Смотри на личности, не на методологии. Agile требует самоорганизованную команду. Если хоть один из пяти человек нуждается в четком ТЗ и не умеет работать в условиях неопределенности - у тебя будут проблемы. Waterfall дает таким людям комфорт. Иногда правильная методология та, с которой команда реально справится.

В соответствии с принципами PMI PMBOK Guide Seventh Edition, выбор подхода к управлению проектом определяется степенью неопределенности требований, сложностью продукта и частотой изменений. При наличии размытых требований рекомендован адаптивный (Agile) подход. Рекомендуем также ознакомиться с практическим руководством PMI "Agile Practice Guide" для детального планирования.

мы на прошлом месте работы делали на waterfall внутренний проект, полгода, 4 человека. итог: за 2 недели до сдачи заказчик посмотрел на прототип и сказал что хочет поменять главный экран. мы переделывали ночами. с тех пор только скрам)

Правильный ответ: Kanban. Для внутреннего продукта с непрерывными изменениями требований - Scrum со спринтами создает искусственные дедлайны которые никому не нужны. Канбан дает поток без этой театральности с планированием спринта, ретро и покером.

У нас тоже был такой выбор для похожего проекта... выбрали Agile, потом пожалели, потом снова выбрали Agile. В общем зависит от команды наверное