瀑布模型与增量/迭代模型的对立

瀑布模型坚持需求分析、设计、实现、测试必须严格依次完成、只朝一个方向”流动”，理由是允许大型系统在开发中途变更是危险的；但这种高度结构化的流程与创造性问题求解所依赖的”自由试错”天然冲突，催生了增量模型（先做出功能有限的简化版本，验证后再逐步叠加功能）和迭代模型（对已有版本反复改进）这类替代路径，二者的极致形态是敏捷方法：用不到十几人的小团队，每天不断重复一轮压缩版的”非正式需求分析、设计、实现、测试”，让软件以小步快跑的方式持续演进。发散：这场对立的核心分歧在于”变更”到底是应该被提前规避的风险、还是应该被主动拥抱的常态——瀑布模型假设需求在项目早期就能被完整、准确地定义清楚（现实中很少如此），敏捷方法则直接承认需求会变、并把”快速响应变化”设计成流程本身的一部分，这个分歧至今仍是评估任何流程方法论时最该先问的问题：它对”计划外的变化”是抵抗还是拥抱？