在软件世界中，“瀑布”通常用于描述一种软件过程样式，该样式与迭代样式或敏捷样式的思想形成对比。像软件中的许多著名术语一样，其含义不明确且来源不明确-但我发现其基本主题是根据活动将大量工作分解为多个阶段。
目前尚不清楚“瀑布”一词如何如此流行，但是大多数人都基于Winston Royce的论文，特别是这个数字：
尽管本文似乎被普遍认为是瀑布概念的来源（基于向下的级联任务的形状），但“瀑布”一词在本文中从未出现过。目前尚不清楚该名称后来如何出现。
Royce的论文描述了他对当时（60年代后期）软件开发过程的观察，以及如何改进通常的实现步骤。[1]但是，“瀑布”已经走得更远了，被用来作为软件开发风格的一般描述。对于像我这样在软件大会上讲话的人来说，它几乎总是以贬义的方式出现-我回想起多年以来没有任何会议发言人说过有关瀑布的任何好消息。但是，当与企业从业者交谈时，我确实听说它是一种可行的甚至首选的开发风格。
但是“瀑布”到底是什么？这不是一个容易回答的问题，因为就像软件中的许多东西一样，没有明确的定义。根据我的判断，有一个共同的特征主导着人们对瀑布的任何定义，那就是根据活动将精力分解为多个阶段的想法。
让我解开那个短语。假设我要构建一些软件，并且我认为将花费大约一年的时间来构建它。很少有人会高兴地说“离开一年，告诉我何时完成”。取而代之的是，大多数人希望将这一年分解成较小的部分，以便他们可以监控进度并有信心按计划进行。那么问题是我们如何进行这种分解？
正如罗伊斯（Royce）所暗示的那样，瀑布式风格是通过我们正在做的活动来实现的。因此，我们的1年项目可能分为2个月的分析，4个月的设计，3个月的编码和3个月的测试。此处的对比是一种迭代方式，在这种方式中，我们将满足一些较高的要求（构建图书馆管理系统），并将其分为子集（搜索目录，预定书籍，退房和退货，评估罚款）。然后，我们选择其中一个子集，并花费几个月的时间来构建可运行的软件以实现该功能，并将其交付到暂存环境中，或者最好交付到现场制作环境中。完成一个子集的操作后，我们将继续其他子集。
在这种思维中，瀑布意味着“一次为所有功能执行一项活动”，而迭代意味着“一次为一项功能执行所有活动”。
如果“瀑布”一词的起源是模糊的，那么基于阶段的故障是如何产生的概念也是如此。我的猜测是，将大型任务分解为不同的活动是很自然的，尤其是当您以架构等活动为灵感时。每种活动需要不同的技能，因此在引入所有编码人员之前让所有分析师完成分析是很直观的。在人们开始编码之前，对需求的误解如果在编码之前解决肯定便宜得多，这似乎是合乎逻辑的，尤其是考虑到60年代后期的计算机状态（banq注：现在计算机速度提高了，但是编码效率并没有提升，尤其相对于复杂系统）。最终，相同的基于活动的细分可以用作许多项目的标准，而基于功能的细分则更难教授。
尽管不难发现这里解释了为什么有人认为这种瀑布式思维对于软件开发不是一个好主意，这里总结对瀑布式风格的主要反对意见：
瀑布样式通常将测试和集成作为周期的两个最后阶段，但是这些是开发项目中最难预测的元素。这些阶段中的问题导致早期阶段许多步骤的返工，并导致大量项目延误。将后期阶段以外的所有阶段都声明为“完成”太容易了，缺少很多工作，因此很难判断项目是否进展顺利。在完成所有功能之前，没有机会进行早期发布。所有这些给开发工作带来很大的风险。
此外，瀑布式方法迫使我们进入一种预测性的计划风格，它假定一旦完成了阶段（如需求分析），那么可交付的结果就是以后阶段进行工作的稳定平台。实际上，由于每个人都对领域，软件环境的特征以及业务环境的变化有了更多的了解，因此绝大多数软件项目都发现它们需要在几个月内进行重大更改。实际上，我们已经发现，提供功能的子集比做任何事情都有助于澄清下一步需要做的事情，因此，迭代方法使我们可以转向适应性计划方法，在学习真正的软件内容时可以更新计划需要。
这就是为什么我曾大胆地说 “您应该仅在要成功的项目中使用迭代开发”的主要原因。
瀑布和迭代可能相互嵌套。一个为期六年的项目可能包含两个为期三年的项目，其中两个项目均以瀑布形式进行结构化，但是第二个项目添加了其他功能。您可以将其视为顶层的两次迭代项目，而每次迭代都是一个瀑布。由于规模大且迭代次数少，我认为这主要是一个瀑布项目。相反，您可能会看到一个项目，每个项目有16个迭代，每个迭代一个月，其中每个迭代都是以瀑布样式计划的。我认为主要是迭代的。从理论上讲，存在难以分类的中间项目的潜力，但在实践中，通常很容易看出一种风格占主导地位。
瀑布式和迭代式混合是可能的，其中早期阶段（需求分析，高级设计）以瀑布样式完成，而后期（详细设计，代码，测试）以迭代方式完成。这降低了后期测试和集成阶段固有的风险，但无法进行自适应计划。
瀑布通常被用作敏捷软件开发的替代方案，但我认为这并非绝对正确。当然，敏捷过程需要迭代的方法，并且不能以瀑布形式工作。但是，遵循迭代方法（即非瀑布式）很容易，但并不敏捷。为此，我可能会采用100个功能并将它们在明年划分为十个迭代，然后期望每个迭代应按计划的功能集按时完成。如果这样做，我的最初计划是一个预测性计划，如果一切顺利，我应该期望工作紧跟计划。但是 适应性的计划是敏捷思维的必不可少的要素维。我希望功能会在迭代之间移动，会出现新功能，并且由于不再有价值而将许多功能丢弃。
我的经验法则是，任何说“我们成功的原因是我们准时且按预算”的人都在按照预测性计划进行思考，即使他们遵循的是迭代过程，因此也不以敏捷的思维方式思考。在敏捷的世界中，成功与商业价值息息相关-不管几个月前计划中写了什么。计划已制定，但会定期更新。它们指导下一步的决策，但不作为成功的衡量标准。
（banq注：任何说“按照我这种方式肯定成功”的人都在按照预测性计划进行思考）