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