瀑布 敏捷_为什么敏捷比瀑布成功得多？

瀑布 敏捷

敏捷继续席卷全球。 Standish Group混沌研究的最新报告提出了有趣的发现：基于敏捷原理的项目的成功率比基于瀑布方法的传统项目要高得多。

在本文中，我将尝试描述促成敏捷团队展示的这些高性能指标的一些因素。

敏捷获得更高成功率的原因是什么？

我参与过的几乎所有瀑布项目都强烈偏向于规避风险。 瀑布项目通常会考虑到宏大的目标，并且会围绕这些目标进行组织。 意思是，大量的资源（货币和人力）被组合并放入严格控制的渠道中。

一个瀑布式项目通常始于：“听着，我们对这项新计划寄予厚望；我们已聘请了不起的专家，投入了大量资金来确保这一计划顺利进行。失败是不可行的！”

正是在这个阶段，当我们进行测试时，有趣的发现开始出现。 事实往往常常是，早期，热切的承诺巩固了团队和产品基础架构，但最终只能使整个项目陷入困境。 后期（不可避免）的失败付出了高昂的代价。

我刚刚描述的过程通常称为“过早优化”。

敏捷颠覆了上述方法。 它包含风险，因为人们认识到尽我们所能避免风险是无法避免的。 敏捷专注于早期反馈（做出非常早期的反馈）。 敏捷取代了傲慢的“我们都知道”的态度，采取了谦虚的“我们沿途学习”的方法。

因此，敏捷没有坚决地巩固和巩固需求，而是拒绝冻结范围。 相反，敏捷方法对于任何示波器蠕变仍然完全开放。 换句话说，在敏捷项目中，没有诸如范围爬升之类的东西。

敏捷的范围是通过响应反馈来管理的。 但是，如何征求宝贵的反馈呢？

反馈总是很难获得。 每个人都很忙，没有人有时间自愿提供反馈。 同样，即使有人设法找到时间提供反馈，也常常本着“如果您没有正面的话要说，至少不要说负面的话”来提供。 因此，大多数自愿反馈最终都以不受欢迎的赞美形式出现。

但是，我们对发现真相更感兴趣。 因此，寻求有价值的反馈的唯一可靠方法是失败。 失败是巨大的动力。 它使所有有关方面都紧急采取措施。

在敏捷中，我们重视频繁且过早的失败。 我们希望尽早发现任何重大风险。 我们愿意接受残酷诚实的批评。

有了这种态度，敏捷就遵循了持续集成（CI）方法。 在构建解决方案时，我们必须尝试在每个代码转换中集成组成组件。 集成的测试紧随其后。

与瀑布法完全相反。 一旦对所有其他内容进行了过早的优化，固化和测试，集成就可以进行到最后一步。 然后才是发现重大风险的最后阶段（集成）。 此时，成功处理损害通常为时已晚。

如何经常和早期整合

瀑布方法之所以没有敏捷那么成功的原因似乎很清楚。 但是潜在的原因并不一定要归结为管理软件开发项目的鲁ck方法。 瀑布式方法不会傲慢地放弃早期和频繁的集成测试。 每个人都希望能够尽早发现重大风险。 问题在于无法集成尚未准备好进行测试的服务和组件（尚未）。

在进行项目时，我们更喜欢采用分而治之的方法。 自然，我们不喜欢按顺序进行开发和构建（一次做一件事），而是更喜欢通过并行执行尽可能多的事情来节省时间。 因此，我们将团队分为较小的单元，专门执行专门的任务。

但是，随着这些专业团队的工作，他们知道或正在发现各种依赖关系。 但是，正如Michael Nygard在“ 没有结束状态的体系结构”中所说：“依赖关系的问题是您不能依赖它们。” 因此，由于无法进行集成测试的各种依赖关系导致项目陷入困境，该项目开始变慢。

敏捷方法消除了任何障碍，并允许自治团队继续开发活动，而不必等待任何人。 这样，团队就可以开始迭代/冲刺，从而开始集成测试。 通过这种方式，敏捷对于IT组织而言是巨大的进步。

翻译自: https://opensource.com/article/20/3/agiles-vs-waterfall

瀑布 敏捷