是否有任何关于敏捷对抗瀑布的效率/有效性的研究？

Question

在前几天的一次会议上，有人声称与瀑布相比，敏捷在开发时间上的效率只有60%。我并不是想证实或反驳这一说法。我感兴趣的是，是否有任何研究比较这两种方法。

有没有比较这两种情况的研究？

Answer 1

虽然我不喜欢这个标题，但我相信平衡敏捷性与纪律性:困惑指南可能包含一些与您相关的信息。本书由两位软件工程过程和软件项目管理专家-巴里博姆和理查德特纳。本书着眼于敏捷和计划驱动方法的各个方面，对它们进行了比较和对比，并讨论了集成它们以实现“两个世界最佳”的情况。

平衡敏捷和纪律的附录E包含了大量关于各种敏捷和计划驱动方法的成本和收益的经验信息。然而，似乎没有任何关于时间有效性的数据。但是浏览一下数据，我想这似乎不是一种选择--在应用敏捷方法时，有些项目经历了减少的努力、更快的进度和更低的缺陷。然而，其他项目使用。本节讨论了不同行业中的许多不同项目，他们使用的过程类型，以及他们在项目过程中经历了什么。

附录E中引用了大量的案例研究，得出了这些数据。对我来说，有太多的名字不能随意命名，因为很多都集中在某个特定的行业，甚至是在一个特定的组织内。如果您要查看案例，我建议您找到那些在本质上与您的团队、项目、组织和行业相似的案例，从而得出合理有效的结论。

在快速发展:驯服野性软件计划中，Steve McConnell确定了在选择生命周期方法时需要考虑的许多因素:对需求的理解水平、对体系结构的理解水平、期望的可靠性、风险管理、进度限制、过程开销的数量、中期项目“过程修正”、向客户提供可见性的能力、向管理提供可见性的能力以及开发团队和管理的复杂性。还有其他的，例如组织文化，所以任何地方都可能没有详尽的清单。

即使给定了完全相同的项目，也存在团队因素。如果你带着一个使用计划驱动的螺旋式方法定期交付软件的团队，并将他们扔进Scrum，他们将经历生产力的下降，打击的增加，并且必须克服一个新的过程模型，才能成功。尽管另一种方法可能更适合，但始终有业务需要实际交付软件。这就是为什么流程改进工作往往是长期的努力，而不是一夜之间的重大变化会让团队感到震惊，而且(即使该方法可能更适合纸面)可能会导致生产率的下降。

不仅仅是过程的效率或有效性，而且您不能简单地查看在计划驱动环境和敏捷环境中工作的同一个团队的快照。在作出决策时，您需要考虑行业和组织环境、项目的属性、团队、客户等。

根据我所读到的，我将不得不不同意你的同事的评估。我相信，您可以在一些案例研究中发现，与类似的计划驱动项目相比，敏捷项目在某些性能指标方面的效率要低60%。然而，也有研究表明敏捷可以减少80%的工作量，减少50%的时间，并使客户对产品的满意度更高。

Answer 2

我没有学习，但我想交流我的经验。

上述任何方法的有效性在很大程度上取决于分析人员。

当您有了一个伟大的产品所有者，那么SCRUM当然比一个错误规范的瀑布式方法更快。

敏捷与糟糕的产品所有者当然比瀑布更慢一个伟大的规格。

然而，通常情况下，我们还没有足够早地知道确切的需求，而且敏捷方法具有更快的反馈周期。这意味着，在不确定领域，敏捷是在合理成本范围内交付高质量产品的更好方法。还有许多其他优点，例如，敏捷项目在不工作时更容易取消，因此可以将损失降到最低。

可以说敏捷方法降低了风险，而瀑布，即使有时更快，也可能是一场货币赌博。

Answer 3

敏捷在开发过程中效率只有60%。

是真的。

但是，这是一个蹩脚的测量。

敏捷方法通常会更快地交付实际价值。

瀑布只是坚持一个时间表，无论什么交付，往往交付任何有价值的，直到一个巨大的时间跨度已经过去。

再远一点。

您可以将“开发时间”与“开发和测试时间”分开来度量。

敏捷通常包括测试。所以看上去要慢一点。

瀑布开发可以从测试中分离出来。所以代码“准备好了”更快地进行测试。但直到很久以后才“完成”。

所以。他们是完全正确的。因为他们所测量的。