释放频率是敏捷和瀑布之间唯一真正的区别吗？

瀑布： 你设计的产品 你建立它 你测试一下 你记录它 你在制定了所有要求后释放它 敏捷： 您首先设计最有价值的功能（或

user story

） 你测试它（TDD;）） 你建造了它 你记录它 您将使用下一个最有价值的功能重复此过程 你可以随时发布它 （在您完成的每个功能之后或在包装时间之后（通常称为

sprint

或

iteration

）） 差异非常清楚。 使用Agile，您可以通过频繁提供小块软件来调整构建内容。你有足够的时候可以停下来。     

更快的反馈 - 在所有规模上，而不仅仅是发布，肯定是许多敏捷实践中的一个常见因素。但我并不认为这是敏捷和敏捷之间的主要区别。瀑布。例如： 瀑布团队倾向于围绕一组狭隘的专业化建立。分析师/建筑师/设计师/编码员/测试人员往往是独立工作的人群。敏捷团队一起工作。 瀑布流程取决于大量的文档和切换。敏捷团队围绕工作代码/产品。 我不同意瀑布专注于客户协作。只有一小部分联系人，只有一小部分整个开发团队，通常只在流程开始时。敏捷是围绕整个开发过程中的持续协作而构建的。非常不一样。 瀑布流程围绕着您可以完全定义产品的想法而构建。开发前的架构。敏捷流程围绕着您随时发现产品/架构的想法而构建。     

瀑布花费时间在设计上，然后编写代码，然后测试并最终发布。但是敏捷完成了同样的一系列步骤 - 只是每个步骤都更小。 敏捷不是一个单一的实体，而是许多不同方法的保护伞。 至少其中一些，正如其他人所指出的那样，这些“阶段”重叠得更多，并且在正常的顺序上有些不同。 事实上，在XP中，订单或多或少： 测试（TDD /测试第一） 码 设计（重构） 重复并最终释放 哪种反转大部分序列。 测试，代码和设计的完成程度比发布时更精细。   敏捷方法的一个关键部分是从每个版本中学习并使用它来让更大的设计出现，而不是在开始时尝试预测它。      但瀑布也是这样做的。只是不是每隔3或4周学习一次，瀑布团队每6或9个月只能学习一次。但瀑布设计仍然出现。也就是说，瀑布版本2将反映在版本1中学到的内容。因此，该过程并没有不同，只是它以不同的速度执行。 这很大程度上取决于实践。如DOD-STD-2167A（第4.1.1节）中所述，瀑布模型确实允许开发过程的各个阶段重叠和迭代（简而言之，有点敏捷）。但大多数实际操作错过了，直到项目结束才有学习。   敏捷专注于密切的客户协作。但瀑布也是这样做的。它只是因为瀑布具有更长的迭代时间，所以需要以合同形式列出的需求列表，以使所有人在很长一段时间内保持在同一页面上。但同样，这只是一个频率的工件。交货频率越高，合同需求越低。 再次依赖练习。我在上面引用的规范中没有看到很多客户责任，更不用说了。 正如Jerry Coffin在评论中指出的那样，瀑布确实是一个曾经支持敏捷的稻草人（事实上我现在正在使用它......），但是值得看一下这篇文章并思考它的含义以及它是如何实现的。已被应用。 该规范所表明的是对合同，计划和文件的交付和维护以及遵守计划的高度关注。我相信这确实已经付诸实践。 与敏捷的对比不是时间框，而是价值观的变化。 正如“敏捷宣言”所宣称：   我们正在发现更好的发展方式   通过这样做并帮助其他人做到的软件。   通过这项工作，我们开始重视：      个人和流程与工具之间的互动      通过综合文档工作软件      合同谈判中的客户协作      响应遵循计划的变更      也就是说，虽然物品上有价值   在右边，我们更重视左边的项目。 奇怪的是，这个价值陈述没有说明交付频率（尽管以下“原则”部分确实如此）。然而，它确实将价值体系从计划，文件和合同转移到实际交付工作软件的地方。 频繁发布是实现这些价值的机制。 如果你在“迷你瀑布”工作，它确实会比稻草人BDUF瀑布更敏捷。但交付频率肯定不是全部。     

一个不同之处在于透明度：在开发周期中，开发团队之外的人员是否能够了解流程，进度，障碍以及最终结果的样子。 瀑布并不意味着透明度。通常（虽然不一定），它被实现为“程序员进入他们的洞穴并在n周/几个月后出现'完成'产品”。业务专家预先编写规范，这可能是他们参与的结束 - 当程序员在实施过程中遇到问题时，他们可能不再可用。在循环结束之前，程序员可能不会向任何人显示任何可交付成果。 敏捷需要透明度 - 它是基本结构的一部分。团队外的人将（或至少可以）看到团队正在做什么。 （如果没有，团队就会说谎是敏捷的。）这可能是Scrum的每日站立会议，或大可见图表和信息辐射器，或迭代结束时的演示。可能是XP要求客户做出所有业务决策，而不是让程序员不顾一切，在需求不明确时盲目地选择一个选项。可能是测试人员 - 和客户 - 被视为团队的一部分，而不是单独的团队。 你当然可以透明地运行瀑布，在一个运行良好的瀑布商店，你可能会。但是对于敏捷，这是一个给定的。     

标记， 正如您所指出的，这两种方法都分享了应该在每个好项目中的“好东西”。例如，采取这两个：早期反馈和透明度。虽然敏捷有一个鼓励这种结构的结构，但这两个“好东西”也可以（并且应该）出现在任何瀑布项目中。 但是，我倾向于（恭敬地！）不同意释放频率是唯一的区别。一个重要的区别是：   瀑布花时间在设计上，   然后编写代码，然后测试   并最终释放。但敏捷确实如此   完全相同的一组步骤 - 它   只是每一个都更小。 我不这么认为。 在敏捷中，您尝试与多学科团队同时完成所有这些事情。 我说“尝试”因为不是可以轻易完成的事情......但至少尝试有帮助。 相反，在传统的瀑布上，你希望有不同的团队（研究/分析，质量保证，设计，营销等）和他们之间的交接。只有在特殊情况下，或者当您需要在复杂项目中进行探索性研究或风险分析时，您才会混合学科并形成一个特殊的团队。 只是我的两分钱......     

我真的很喜欢这个问题。 我曾经用大型瀑布项目的坏例子进行维护。初始开发人员的可交付成果是几组文档和一个代码库。一旦完成高级设计文档，它就会被交付，并且永远不会再次更新。同上SRS，详细设计等。有文件，所有这些都是不可靠和可疑的。 有了Agile，就有代码。长期以来的开发人员认为它是自我记录的，因为它们在编写时是最新的项目。 （你有没有校对自己的备忘录？它们总是对作者有意义。）我将尝试通过查看1500-2000模块来辨别架构。同样试图弄清楚高级设计。我会采取大量的笔记。也许甚至粘合剂都满了。查看“自我记录”代码将告诉我正在做什么（在该模块中），但不是为什么。哦，是的，与开发人员合作的工作人员得到提升（或害怕）并且不再可用。 糟糕的敏捷并不比糟糕的瀑布好。事实上，糟糕的敏捷可能比糟糕的瀑布更糟糕。好的敏捷比好瀑布好吗？ 宣言没有说明文件。这里真正的危险是“敏捷”对许多开发者和客户来说意味着快速廉价的英雄模型。您是否认为客户喜欢阅读高级设计的三个厚三环粘合剂？我们都在计算机科学100中听说软件的大部分成本是维护而不是开发。我认为维护方面在本次讨论中完全被忽略了吗？ 不同的可能是现代客户不能不指定“敏捷”，因为他们害怕被认为是落后的。