logo标签列表

敏捷和瀑布模型的唯一真正区别是发布频率吗？

agilewaterfall
12
很明显，采用这两种方法对团队、客户、投资回报等产生的影响差异巨大，并成为许多书籍、无休止的讨论和会议的主题。
但是，我越想越觉得，我很难找到两者之间没有根源差异的区别，这个根源差异就是发布频率。
瀑布式开发会花时间进行设计，然后编写代码，再测试，最后发布。但是敏捷开发也完全遵循这一系列步骤——只不过每个步骤都更小。
敏捷方法的一个关键部分是从每次发布中学习，并利用这些知识使更大的设计逐渐浮现出来，而不是尝试在开始时预测它。
但瀑布式开发也是如此。只不过瀑布式团队每次学习的时间间隔为6或9个月，而不是每3或4个星期一次。但是瀑布式设计仍然会浮现出来。也就是说，瀑布式的第二次发布将反映在第一次发布中学到的东西上。因此，这个过程并没有什么不同，只是执行速度不同。
敏捷方法专注于与客户的紧密协作。但瀑布式开发也同样如此。只不过由于瀑布式有更长的迭代时间，需求清单以合同形式列出，以在漫长的时间内让每个人都保持一致。但同样，这只是频率造成的产物。发布频率越高，需要签订合同的必要性就越小。
还有其他我忽略的基本差异吗，或者真的只是频率的问题？
6
像这样的讨论主题应该是维基页面。 - Gert Grenander
3
谈论与瀑布模型的差异是愚蠢的——从一开始就是人们用来与他们所提倡的任何方法进行对比的稻草人。我相信瀑布模型的第一个描述出现在这里：http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf，该文仅将其描述为一种与作者所提倡的无可避免更优秀方法进行对比的方式。 - Jerry Coffin
不要重复自己的答案 - 你应该区分发布和准备发布：http://www.andybrandt.net/637/to-release-or-not-to-release - Andy
敏捷开发是一系列短暂的瀑布，每个瀑布都有一个回溅。 - user12817546
6个回答
8

瀑布模型:

  • 你设计产品
  • 你构建它
  • 你测试它
  • 你记录文档
  • 你在开发所有要求后发布它

敏捷开发:

  • 你首先设计最有价值的功能（或用户故事）
  • 你测试它（TDD ;)）
  • 你构建它
  • 你记录文档
  • 你重复这个过程，处理下一个最有价值的功能
  • 你可以随时发布它

（在完成每个功能或时间框定期之后（通常称为sprint或iteration））

对我来说，差异非常明显。

使用敏捷开发，您可以通过频繁交付小块软件来适应需要构建什么。当您拥有足够的东西时，您可以停止。

这是一个很好的观点 - 在敏捷开发中，当功能完成时就开始测试。而在瀑布模型中，你需要等到整个产品完成后才开始测试，这会导致更长的端到端周期。 - Joe White
2
如果我要挑剔的话，我可能会想要交换测试/构建的顺序 - 因为我是TDD的支持者 :-) 我也只会在必要时才进行文档记录。而且我会边设计边实现，而不是一开始就全部设计好 :-) - adrianh
+1 表示“当你满意时可以停止”。很多人都忽略了这一点。 - gbn
1
Adrian没有告诉你反向操作。 - user333306
@adrianh：好的，所以我们在实际层面上达成了一致。 :-) - Donal Fellows
显示剩余2条评论
6
更快的反馈-在所有规模上，而不仅仅是发布方面，显然是许多敏捷实践中的一个共同因素。但我认为这不是敏捷和瀑布之间的主要区别。例如：
瀑布团队倾向于建立在一组狭窄的专业化基础上。分析员/架构师/设计师/编码人员/测试人员往往是分开工作的独立群体。敏捷团队协同工作。
瀑布流程依赖于大量文档和交接。敏捷团队以工作代码/产品为导向。
我不同意瀑布流程侧重于客户协作。有一个联系点，与整个开发团队中的小团队在开始时一起工作。敏捷是建立在整个开发过程中持续协作的基础之上。非常不同。
瀑布流程建立在在开发开始之前您可以完全定义产品和架构的想法之上。敏捷流程建立在您在开发过程中发现产品/架构的想法之上。
3
瀑布模型花费时间在设计、编写代码、测试和最终发布上。但是，敏捷开发也执行同样的步骤 - 只是每个步骤更小。
敏捷开发不是单一实体，而是许多不同方法的总称。
至少在其中一些方法中，如其他人所指出的，这些“阶段”重叠得更多，并且顺序有所不同。
事实上，在XP中，顺序或多或少为：
- 测试（TDD /先测试） - 编码 - 设计（重构） - 重复并最终发布
这几乎颠倒了大部分顺序。
而测试、编码和设计的精度比发布要高。
敏捷方法的一个关键部分是从每次发布中学习，并使用它来让更大的设计出现，而不是试图在开始时预测它。
但是瀑布模型也是如此。只是瀑布团队每6到9个月才学习一次，而不是每3到4周学习一次。但是瀑布设计仍然会出现。也就是说，瀑布发布2将反映在瀑布发布1中学到的内容。因此，过程并没有不同，只是以不同的速度执行。
这在很大程度上取决于实践。正如DOD-STD-2167A（第4.1.1节）所述，瀑布模型确实允许开发过程的阶段重叠和迭代（简而言之，有点敏捷）。但是，大多数实际实践都错过了这一点，直到项目结束才开始学习。
敏捷方法专注于与客户紧密合作。但是瀑布模型也是如此。只是由于瀑布具有更长的迭代时间，因此需要一个以合同形式列出的需求清单，以在长时间内使每个人保持一致。但是，这再次只是频率的产物。交付频率越高，需要合同的需求就越低。
再次强调，这取决于实践。我在上面引用的规范中几乎没有提到客户责任，更不用说持续了。
正如Jerry Coffin在评论中指出的，瀑布模型确实是用来支持敏捷开发的稻草人（就像我现在正在使用它一样...），但是值得看看这个文档并考虑它意味着什么以及如何应用它。
该规范所显示的是对合同、交付和计划和文档的维护以及遵守计划的强烈关注。我相信这种情况确实发生了。
与敏捷方法的对比不是时间盒，而是价值观的变化。
正如《敏捷宣言》所宣布的那样：

我们正在通过实践和帮助他人实践，揭示开发软件的更好方式。通过这项工作，我们开始重视：

个体和交互胜过流程和工具

可工作的软件胜过详尽的文档

与客户合作胜过合同谈判

响应变化胜过遵循计划

也就是说，虽然右边的项目有其价值，但我们更重视左边的项目。

有趣的是，这个价值观声明没有提及交付频率（尽管下面的“原则”部分有）。然而，它确实将价值体系从计划、文件和合同转移到了真正交付可工作的软件上。
频繁发布是实现这些价值的一种机制。
如果您在“微型瀑布”中工作，它确实比稻草人BDUF瀑布更加敏捷。但是，交付频率当然不是全部。
2
一个区别在于透明度：开发周期中团队外的人是否能够看到过程、进展、障碍以及最终结果。
瀑布模型并不意味着透明度。通常（但不一定）它被实现为“程序员进入他们的洞穴，n周/月后出现一个‘完成’的产品”。业务专家事先编写规格说明书，这可能是他们参与的结束——当程序员在实施过程中有问题时，他们可能不再提供帮助。程序员可能不会向任何人展示交付成果，直到周期结束。
敏捷方法要求透明度，这是其基本特征之一。团队外的人将会看到团队正在做什么（或至少可以看到）。这可能是Scrum的每日站立会议，大型可见图表和信息辐射器，或迭代结束时的演示。这可能是XP要求客户做出所有业务决策，而不是让程序员在需求不清楚时摸不着头脑地选择一个选项。这可能是测试人员和客户被视为团队的一部分，而不是单独的团队。
当然，你也可以用透明度来运行瀑布模型，在管理良好的瀑布模型商店中，你可能会这样做。但在敏捷方法中，透明度是必须的。
1

马克，

正如你所指出的那样，这两种方法都分享了应该在每个好项目中存在的“好东西”。例如，早期反馈和透明度。虽然敏捷确实有一种鼓励这种做法的结构，但这两个“好东西”也可以（而且应该）在任何瀑布流项目中存在。

然而，我倾向于（尊重地！）不同意发布频率是唯一的区别这个想法。一个实质性的区别是：

瀑布流花费时间在设计上， 然后编写代码，然后测试 最后发布。但敏捷也是 做完全相同的步骤 - 只是 每个步骤更小。

我不这么认为。 在敏捷中，您尝试使用多学科团队同时完成所有这些事情。 我说“尝试”，因为这不是一件容易的事情...但至少尝试有所帮助。

相反，在传统的瀑布流中，您希望拥有单独的团队（研究/分析、QA、设计、营销等），并在它们之间进行交接。您混合学科并在特殊情况下或需要在复杂项目中进行探索性研究或风险分析时组成一个特殊团队。

仅代表个人观点...

0

我真的很喜欢这个问题。

我曾经维护过一些糟糕的大型瀑布式项目，其中包含了不良示范。最初的开发人员需要交付几套文档和一份代码库。在高级设计文档完成后，它被交付并且再也没有更新过。同样适用于SRS、详细设计等。虽然有文档，但所有文档都是不可靠和可疑的。

使用敏捷开发的话，就有了代码。已经离开的开发人员认为它是自我记录的，因为当他们编写时，他们对项目是持续关注的。(你有没有读过你自己的备忘录？它们总是对作者来说很有意义。)我将尝试从1500-2000个模块中推断出架构。同样地，试图理解高级设计。我会做大量的笔记。甚至可能会装满夹子。查看“自我记录”的代码将告诉我正在执行什么操作(在该模块中)，但不知道为什么要这么做。噢，是的，与开发人员合作过的工作人员得到了晋升(或者被吓跑了)，现在无法联系到他们了。

糟糕的敏捷开发并不比糟糕的瀑布式开发更好。实际上，糟糕的敏捷开发可能比糟糕的瀑布式开发还要糟糕。那么，良好的敏捷开发是否比良好的瀑布式开发更好呢？

这份宣言没有提到文档。真正的危险在于，“敏捷”对许多开发人员和客户来说意味着快速、廉价、英雄式的模型的辩护。你认为客户喜欢阅读三个厚厚的三环活页夹的高级设计吗？我们都听过计算机科学100中的大部分软件成本是维护而不是开发。我是否错误地认为，在这个讨论中完全忽略了维护方面？

区别可能在于现代客户不能承受不指定“敏捷”，因为他们担心被认为落后。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接