显然，应用这两种方法对团队、客户、投资回报率等的影响是巨大的，并且是许多书籍和无休止的讨论和会议的主题。
但是当我想得更多时，我很难找到两者之间的任何差异，这些差异最终不会映射到一个单一的根差异，即发布频率。
瀑布花时间在设计上，然后是编写代码，然后是测试，最后是发布。但是敏捷执行完全相同的一组步骤——只是每个步骤都更小。
敏捷方法的一个关键部分是从每个版本中学习并使用它来让更大的设计出现，而不是在一开始就试图预测它。
但瀑布也这样做。只是瀑布团队不是每 3 或 4 周学习一次，而是每 6 或 9 个月才学习一次。但瀑布设计仍然出现。也就是说，瀑布式第 2 版将反映第 1 版中学到的内容。所以这个过程没有什么不同，只是它以不同的速度执行。
敏捷专注于密切的客户协作。但瀑布也这样做。只是由于瀑布的迭代时间较长，因此更需要以合同形式列出的需求列表，以使每个人在很长一段时间内都保持在同一页面上。但同样，这只是频率的产物。交付频率越高，对合同的需求就越低。
是否还有其他我遗漏的原始差异 - 或者它真的只是频率？
瀑布：
敏捷：
user story）（在您完成每个功能之后或在时间限制期之后（通常称为sprint或iteration））
区别对我来说很清楚。
使用敏捷，您可以通过频繁交付一小部分软件来调整要构建的内容。当你有足够的时候你可以停下来。
更快的反馈——在所有规模上，不仅仅是发布，肯定是许多敏捷实践中的一个共同因素。但我真的不认为这是敏捷和瀑布之间的主要区别。例如：
瀑布团队倾向于围绕一组狭窄的专业领域建立。分析师/建筑师/设计师/编码员/测试员往往是单独工作的不同群体。敏捷团队一起工作。
瀑布式流程依赖于大量文档和移交。敏捷团队以工作代码/产品为导向。
我不同意瀑布关注客户协作。与整个开发团队的一小部分有一个单一的联系点，通常只在流程开始时。敏捷建立在整个开发过程中的持续协作之上。非常不一样。
瀑布式流程是围绕这样一个理念构建的，即您可以在开发开始之前完全定义产品和架构。敏捷过程是围绕着你发现产品/架构的想法而构建的。
瀑布花时间在设计上，然后是编写代码，然后是测试，最后是发布。但是敏捷执行完全相同的一组步骤——只是每个步骤都更小。
敏捷不是一个单一的实体，而是许多不同方法的保护伞。
正如其他人所指出的那样，至少在其中一些中，这些“阶段”重叠得更多，并且正常顺序有所不同。
事实上，在 XP 中，顺序或多或少是：
哪种反转了大部分序列。
并且测试、代码和设计都比发布完成得更好。
敏捷方法的一个关键部分是从每个版本中学习并使用它来让更大的设计出现，而不是在一开始就试图预测它。
但瀑布也这样做。只是瀑布团队不是每 3 或 4 周学习一次，而是每 6 或 9 个月才学习一次。但瀑布设计仍然出现。也就是说，瀑布式第 2 版将反映第 1 版中学到的内容。所以这个过程没有什么不同，只是它以不同的速度执行。
这在很大程度上取决于实践。如DOD-STD-2167A中所述，（第 4.1.1 节）瀑布模型确实允许开发过程的各个阶段重叠和迭代（简而言之，有点敏捷）。但大多数实际实践都忽略了这一点，直到项目结束才学习。
敏捷专注于密切的客户协作。但瀑布也这样做。只是由于瀑布的迭代时间较长，因此更需要以合同形式列举的需求列表，以使每个人在很长一段时间内保持在同一页面上。但同样，这只是频率的产物。交付频率越高，对合同的需求就越低。
再次依赖实践。我在上面提到的规范中根本没有看到太多提到客户责任，更不用说连续了。
正如 Jerry Coffin 在评论中指出的那样，Waterfall 确实是一个曾经支持敏捷的稻草人（事实上我现在正在使用它......），但值得查看这份文档并思考它的含义以及它的含义被应用。
该规范确实显示了对合同、计划和文件的交付和维护以及遵守计划的高度关注。我相信这确实延续到了实践中。
与敏捷的对比不是时间盒，而是价值观的变化。
正如敏捷宣言所宣称的：
我们正在通过开发软件并帮助他人开发软件来发现更好的方法。通过这项工作，我们开始重视：
个人和交互超过流程和工具
工作软件优于综合文档
合同谈判中的客户协作
响应变化而不是遵循计划
也就是说，虽然右边的项目有价值，但我们更重视左边的项目。
奇怪的是，这个价值观声明没有提到交付频率（尽管下面的“原则”部分有）。然而，它确实将价值体系从计划、文件和合同转移到了它所属的地方，真正交付了工作软件。
频繁发布是实现这些价值的一种机制。
如果您在“迷你瀑布”中工作，它确实会比稻草人 BDUF 瀑布更灵活一些。但交付频率肯定不是全部。
一个区别是透明度：在开发周期中，开发团队之外的人是否对过程、进度、障碍以及最终结果的外观有任何可见性。
瀑布并不意味着透明。通常（尽管不一定）它被实现为“程序员进入他们的洞穴并在n周/月后出现'完成'产品”。业务专家预先编写规范，这可能是他们参与的结束——当程序员在实施过程中遇到问题时，他们可能不再可用。在周期结束之前，程序员可能不会向任何人展示任何可交付成果。
敏捷需要透明度——它是基本结构的一部分。团队之外的人将（或至少可以）看到团队正在做什么。（如果不是，团队在撒谎说敏捷。）这可能是 Scrum 的每日站立会议，或者是大可视图表和信息辐射器，或者是迭代结束时的演示。XP 的要求可能是客户做出所有业务决策，而不是让程序员在需求不明确时摸不着头脑并盲目地选择一个选项。这可能是因为测试人员——以及客户——被认为是团队的一部分，而不是独立的团队。
您当然可以透明地运行 Waterfall，并且在经营良好的 Waterfall 商店中，您可能会这样做。但是对于敏捷，这是给定的。
标记，
正如您所指出的，这两种方法都共享每个好项目中应该包含的“好东西”。以这两个为例：早期反馈和透明度。虽然敏捷确实有一个鼓励这一点的结构，但这两个“好东西”也可以（并且应该）出现在任何瀑布项目中。
但是，我倾向于（恭敬地！）不同意发布频率是唯一区别的想法。一个实质性的区别如下：
瀑布花时间在设计上，然后是编写代码，然后是测试，最后是发布。但是敏捷执行完全相同的一组步骤——只是每个步骤都更小。
我不这么认为。在敏捷中，您尝试与多学科团队同时完成所有这些事情。我说“尝试”是因为不是一件容易的事……但至少尝试会有所帮助。
相反，在传统的瀑布流中，您希望拥有独立的团队（研究/分析、质量保证、设计、营销等）并在他们之间进行交接。只有在特殊情况下，或者当您需要在复杂项目中进行探索性研究或风险分析时，您才可以混合学科并组建一个特殊的团队。
就我的两分钱...
我真的很喜欢这个问题。
我曾使用大型瀑布项目的不良示例进行维护。最初开发人员的可交付成果是几组文档和一个代码库。一旦完成了高级设计文档，它就被交付了，并且再也没有更新过。同上 SRS，详细设计等。有文档，所有这些都是不可靠和可疑的。
有了敏捷，就有了代码。久违的开发人员认为它是自我记录的，因为他们在编写项目时与项目保持同步。（你曾经校对过你自己的备忘录吗？它们对作者来说总是有意义的。）我将尝试通过查看 1500-2000 个模块来辨别架构。同样试图弄清楚高级设计。我会做大量的笔记。甚至可能装满了活页夹。查看“自我记录”代码将告诉我正在做什么（在该模块中），但不知道为什么。哦，是的，与开发人员合作的员工被提升（或害怕）并且不再可用。
糟糕的敏捷并不比糟糕的瀑布好。事实上，糟糕的敏捷可能比糟糕的瀑布更糟糕。好的敏捷比好的瀑布好吗？
宣言只字未提文档。这里真正的危险在于，“敏捷”对许多开发人员和客户来说意味着快速廉价英雄模型的正当性。您认为客户喜欢阅读高级设计的三个厚三环活页夹吗？我们都在计算机科学 100 中听说过，软件的大部分成本是维护，而不是开发。我认为在这个讨论中完全忽略了维护方面是不正确的吗？
不同之处可能在于现代客户不能不指定“敏捷”，因为他们害怕被认为是落后的。