Когда решаться на Waterfall?

^^image source

Incremental & Iterative & Iterative+Incremental

Incremental подходит только в простых, ясных проектах.

Iterative - когда много неопределенности, неясности, крайне сжатые сроки. Впринципе, если не понятно как двигаться, лучше двигаться так.

Iterative+Incremental -  для больших проектов. Сначала формируем общий целостный каркас, который все-таки остается гибкий к изменениям. А дальше сосредотачиваемся в определенных участках исследованиями, пробами, проверками концептов, и доработкой до достаточного уровня, после этого переходим дальше с участка на участок.

Принимаем решения по архитектуре как можно позденее (Set-based design), имея множество концептов, которые мы проверяем и поддерживаем паралельно, отбрасывая отдельные, только после того, что они явно оказываются в действительной среде (где мы разрабатываем продукт/проект) не состоятельными или другие точно оказываются лучше. 

Так посредине(или даже под конце) проекта у нас будет самый оптимальный дизайн(и/или архитектура) для данной среды и проекта/продукта -- путем "останется только один" или сольется несколько воедино, родивши что-то лучшее. Подкоманды, что проверяли концепты, которые несостоялись, не считаются "лузерами" -- они часть команды, которая сделала важнейшую работу, проверила реальностью один из возможных концептов, получила необходимые доменные и експертные знания своей исследовательской работой и способны влиться в доделывание совместнонайденного оптимального решения.