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

Question

显然，应用这两种方法对团队、客户、ROI等的影响差异是巨大的，是许多书籍和无休止的讨论和会议的主题。

但随着我更多地思考，我很难找到这两者之间的任何差异，而不是最终映射到一个单一的根差异，即发布频率。

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

敏捷方法的一个关键部分是从每个版本中学习，并使用它来让更大的设计出现，而不是试图在一开始就预测它。

但是瀑布也是这样做的。只是瀑布团队不是每3或4周学习一次，而是每6或9个月学习一次。但是瀑布的设计仍然出现了。也就是说，瀑布版本2将反映在版本1中学到的东西，所以这个过程并没有什么不同，只是它的执行速度不同。

敏捷侧重于密切的客户协作。但是瀑布也是这样做的。只是因为瀑布有更长的迭代时间，所以更需要一个合同形式的枚举需求列表，以便让每个人在很长一段时间内都在同一个页面上。但再说一次，这只是频率的伪影。交付频率越高，对合同的需求就越低。

有没有我遗漏的其他原始差异--或者真的只是频率？

Answer 1

瀑布

• 你设计产品
• 你构建它
• 你测试它
• 你记录它<

>H111>当你开发完所有的代码后，你就会发布它

敏捷：

• 你设计最有价值的功能(或user story)首先
• 你测试它(TDD；)
• 你构建它
• 你记录它<代码>H225<代码>H126你用下一个最有价值的功能<代码>H227<代码>H128重复这个过程<代码>H229<代码>F230

(在您完成的每个功能之后或在时间段(通常称为sprint或iteration)之后)

对我来说，区别是非常明显的。

使用敏捷，您可以通过频繁交付小块软件来调整要构建的内容。当你有足够的时间时，你可以停下来。

Answer 2

更快的反馈-在所有规模，而不仅仅是发布，肯定是许多敏捷实践中的一个共同因素。但我真的不认为这是敏捷和瀑布之间的主要区别。例如：

• 瀑布团队往往是围绕着一组狭隘的专业而建立的。分析师/架构师/设计师/程序员/测试人员往往是单独工作的独立团队。敏捷团队工作together.
• Waterfall流程依赖于大量的文档和移交。敏捷团队是以工作为导向的，code/products.
• I'd不同意瀑布专注于客户协作。有一个单一的联系点，与整个开发团队的一个小组，通常只在过程的开始。敏捷是建立在整个开发过程中持续协作的基础上的。Very different.
• Waterfall流程是围绕这样一种想法构建的，即您可以在开发开始之前完全定义产品和体系结构。敏捷流程是围绕这样一种理念构建的，即您在进行过程中发现产品/体系结构。

Answer 3

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

敏捷不是一个单一的实体，而是许多不同方法的保护伞。

正如其他人所指出的，至少在其中的一些阶段中，这些“阶段”重叠得更多，并且在正常顺序上略有不同。

事实上，在XP中，顺序或多或少是：

测试first)

• code

• design (refactoring)

• repeat并最终发布
• 测试(测试

在某种程度上颠倒了大部分序列。

测试、代码和设计都是在比发行版更好的级别上完成的。

敏捷方法的一个关键部分是从每个版本中学习，并使用它来让更大的设计出现，而不是试图在一开始就预测它。

但是瀑布也是这样做的。只是瀑布团队不是每3或4周学习一次，而是每6或9个月学习一次。但是瀑布的设计仍然出现了。也就是说，瀑布版本2将反映在版本1中学到的东西，所以这个过程并没有什么不同，只是它的执行速度不同。

这在很大程度上依赖于实践。正如DOD-STD-2167A中所描述的(第4.1.1节)，瀑布模型确实允许开发过程的各个阶段重叠和迭代(简而言之，有点敏捷)。但大多数实际实践都忽略了这一点，并且直到项目结束才有任何学习。

敏捷专注于密切的客户协作。但是瀑布也是这样做的。只是因为瀑布有更长的迭代时间，所以更需要一个合同形式的枚举需求列表，以便让每个人在很长一段时间内都在同一个页面上。但再说一次，这只是频率的伪影。交付频率越高，对合同的需求就越低。

再一次依赖于练习。在上面提到的规范中，我根本看不到太多关于客户责任的内容，更不用说不断地提到了。

正如曾傑瑞·科芬在评论中指出的那样，瀑布确实是一个曾经支持敏捷的稻草人(我现在确实正在使用它……)，但值得看看这篇文档，思考它意味着什么以及它是如何应用的。

本规范所展示的是对合同、计划和文档的交付和维护以及对计划的的高度关注。我相信，确实带到了实践中。

与敏捷的对比不是时间限制，而是价值观的改变。

正如The Agile Manifesto所宣称的：

我们正在发现更好的开发软件的方法，通过实践和帮助他人来实现。通过这项工作，我们获得了价值：

流程和工具上的个人和交互

工作软件胜过全面的文档

客户协作重于合同谈判

响应变化而不是遵循计划

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

奇怪的是，这个values语句没有提到交付频率(尽管下面的“原则”部分提到了)。然而，It 确实将价值体系从计划、文档和合同转移到了属于它的地方，而是真正交付了可用的软件。

频繁发布是实现这些价值的一种机制。

如果你在“迷你瀑布”中工作，它确实会比稻草人BDUF瀑布更敏捷一点。但交付频率肯定不是问题的全部。