瀑布模型失败的根源
1.
瀑布模型的4个错误假设
瀑布模型是以4个假设为基础，并在此基础上推导出的一系列方法。但最终这4个假设都被证明是错误的。基础错误了，在基础上推导出的方法也必然是错误的。
以下是瀑布模型的4个错误假设。
1.1. 只要花时间，就能明确需求
瀑布模型认为需求是可以在设计之前就明确的，只要通过正确的方法，就一定能够在设计前把握所有需求。
而事实上，“需求唯一不变的就是‘需求永远是变化的 ’”。
瀑布模型的思想是沿用传统行业的流程来指导软件工程，特别是受建筑业的影响，架构（Framework）、工程（Project）这些术语都是引用自建筑业。这样不可避免地受传统行业的“隐喻”影响，从而加大了软件工程的错误方向。拿砖工来比较程序员，就是这种错误思想的反映。
1.2. 在开发过程中，需求的改动是非常小的
事实上，项目越大、项目周期越长，在开发过程中需求的改变就越大越频繁。而且致命的是，当我们以为我们看到了25%的需求是改变的时候，其实是有50%的需求被改变了（这是基于需求无法全部明确的推导）。
1.3. 系统在交付前会顺利地集成
一个大项目通常分解成多个子项目（系统），由不同的团队（人）负责。瀑布模型认为只要有足够的预期和测试，这些子系统就能顺利地集成。但事实上，系统集成之后都会有不可预料的问题，它们并不能顺利地工作。并且集成越晚，花费在解决集成带来的问题上的时间就越多——集成的周期与解决集成带来的问题的时间，不是线性增长的，而是指数级增长。
记住，当系统未通过集成前，系统的风险永远存在。不要指望组件级（子系统）测试成功，就意味着系统级（整个项目）的测试就会成功。
1.4. 只要计划妥善，项目就可以按时交付
瀑布模型之所以提出这个假设的理由是：
1. 我们已经计划好所有的事情，并且为未知的事件留下了足够的宽裕时间。
2. 整个软件工程过程都是按照计划来进行，我们能够计算出每一步计划所花费的时间。
当然，这两个理由最后都被证明是错误的，那么在此基础上提出的假设也就不成立了。
2. 使用敏捷方法避免瀑布模型的假设错误
以下是敏捷方法避免瀑布模型的假设错误的观点。
2.1. 需求是不可完全预知的
没有人（包括系统分析师和客户）可以预知所有的需求。
也就是说，在系统调研时，即使我们花再多的时间，也不可能完全了解项目的所有需求。
2.2. 需求的变化是长期和巨大的
这是软件开发行业与传统行业（建筑业）的巨大差异。软件是纯虚拟思想的结晶，它在抽象上和快速改进上是传统行业无法匹及的。
2.3. 系统需要不断地集成
系统集成是非常重要的，它可以有效地降低交付风险。项目从一开始就必须不断地集成，随时保持系统可以顺利运行。
2.4. 不存在按时交付的计划，使用快速迭代代替固定的计划
不断地向客户提交“未完善”版本，得到客户实际体验之后反馈的问题。
快速迭代可以用较小的代价重构系统。快速迭代还带来另外一个红利：项目经理和客户在不断的体验中，能够把握项目的真实进度。