有没有关于敏捷与瀑布的效率/效果的研究[关闭]


22

在前一天的一次会议上,有人声称与瀑布相比,敏捷的开发时间效率只有60%。我不希望验证或反驳此主张。我很想知道是否有任何研究比较这两种方法。

有没有比较这两者的研究?


4
敏捷并不意味着交付更好的软件。无论采用哪种方法,都可以交付高质量的软件。敏捷通常是指在响应客户不断变化的需求的同时,以更少的时间交付高质量的增值软件。
Thomas Owens

6
要求索赔的来源。
马丁·约克

好吧,如果原始人有资料,那么它可能会包含其他研究的链接。
马丁·约克

4
@Chad为什么不是你的地方?谁在说这个?如果是外部供应商,那么是在与他们合作之前了解他们的项目管理能力的好机会。
Thomas Owens

1
@CHad:说句道格拉斯·亚当斯.... I refuse to prove that Agile is more efficient,上帝说,for proof denies faith, and without faith Agile is nothing.
mattnz 2014年

Answers:


12

这本书“制作软件:真正起作用以及为什么我们认为,”对敏捷方法,包括XP,Scrum的,动态的软件开发,精益,具有良好的科研后盾某些章节。正如您对O'Reilly的期望一样,它的质量很高。其中一位编辑是杰出的Greg Wilson,他是一位可信赖的计算机科学作者,编辑和演示者。

该书本身总结了多项研究,包括许多关于敏捷的研究。一节总结了研究,包括戴伯(Tybå,T.)的“两个头脑比一个头脑好吗?关于结对编程的有效性”;Eris,Arisholm;DIJSjøberg;JE,汉娜;Shull,F .;以及ToreDybå和TorgeirDingsøyr撰写的“ 敏捷软件开发的经验研究:系统综述 ”。

一般的看法是,大多数敏捷实践都是有益的,但是结对编程和TDD以及其他敏捷租户的影响并不像人们希望的那样强大。甚至有一个令人不安的脚注,即TDD实际上可能会让人上瘾*。

这本书是访问很多已完成的研究的好方法,这些研究都是紧密结合的。网上有一些博客和其他网站都在对此书进行评论。


*这不一定是我的意见!


1
您是否有可能添加一些引号和参考?这可能有助于确定是否值得我的野生动物园书架位之一。* 8')
Mark Booth,

1
角落的版本太:)谢谢你会检查出来今晚。
SoylentGray 2011年

添加。让我知道您是否打算这样做。如果有人想编辑这篇文章并抄写本书的文字,那也将受到欢迎。
凯尔·霍奇森

谢谢Kyle,但我认为总结起来比看起来像屏幕抓取要好。在没有更多上下文的情况下,很难获得他们正在谈论的内容,例如,努力意味着什么?我们是否在谈论每个项目的开发人员时间?
Mark Booth

1
这本书回答了我应该问的问题,尽管我认为范围可能太广。谢谢你的链接。
SoylentGray 2012年

10

尽管我不喜欢这个标题,但我相信平衡敏捷与纪律:困惑的指南可能包含一些与您相关的信息。本书由两位软件工程过程和软件项目管理专家-Barry Boehm和Richard Turner撰写。本书探讨了敏捷和计划驱动方法的各个方面,对它们进行了比较和对比,还讨论了将它们集成以实现“两全其美”的情况。

平衡敏捷和纪律的附录E包含了大量有关各种敏捷和计划驱动方法的成本和收益的经验信息。但是,似乎没有任何有关时间有效性的数据。但是浏览一下数据,似乎(我怀疑)这不是一个选择,有些选择的项目在采用敏捷方法时会减少工作量,加快进度并减少缺陷。但是,使用了其他项目。本节讨论了不同行业中的许多不同项目,它们使用的过程类型以及他们在项目过程中的经历。

附录E中引用了许多案例研究,可以得出此数据。对于我来说,太多的事情无法开始随机命名,因为许多问题集中在特定行业甚至特定组织内。如果您要研究案例,我建议您找到性质与您的团队,项目,组织和行业相似的案例,以得出合理有效的结论。

在《快速开发:驯服野生软件计划》中,史蒂夫·麦康奈尔确定了选择生命周期方法时要考虑的许多因素:对要求的了解程度,对体系结构的了解程度,所需的可靠性,风险管理,计划约束,过程量间接费用,项目中期“路线修正”,向客户提供可见性的能力,向管理人员提供可见性的能力以及开发团队和管理人员的成熟度。还有其他一些东西,例如组织文化,因此,可能没有一个详尽的清单。

即使给出了完全相同的项目,也存在团队因素。如果您的团队使用计划驱动的螺旋方法始终如一地交付软件并将其投入Scrum,则他们将面临生产率下降、,动增加以及必须克服新流程模型的麻烦。周围成功。即使另一种方法可能更适合,但实际需要始终交付真正的软件。这就是为什么流程改进工作通常是长期的工作,而不是一夜之间的事情-重大更改使团队感到震惊,并且(即使该方法可能更适合书面使用)会导致生产率下降。

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


根据我阅读的内容,我将不得不不同意您的同事的评估。我敢肯定,您可以在某处案例研究中找到一些案例,在该案例中,就某种绩效指标而言,敏捷项目的效率比类似的计划驱动项目低60%。但是,也有研究表明,敏捷使产品的工作量减少了80%,时间减少了50%,并且客户对产品的满意度很高。


6

我没有学习,但我想交流一下我的经验。

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

当您拥有出色的产品所有者时,例如SCRUM肯定比不理想的瀑布式方法快。

拥有糟糕产品所有者的敏捷当然要比拥有出色规格的瀑布慢。

但是,我们常常不及早知道确切的要求,敏捷方法具有更快的反馈周期。这意味着,在不确定的地形中,敏捷性是一种以合理的成本交付高质量产品的更好方法。还有许多其他优点,例如,敏捷项目在无法解决时更容易取消,因此可以将损失降到最低。

可以说,敏捷方法可以降低风险,而瀑布瀑布(​​有时有时可能更快)可以算是一笔金钱。


4

敏捷开发效率只有60%

真正。

但是,这是一个me脚的测量。

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

瀑布只是按照时间表进行计划,而不管交付的是什么,并且在经过很长的时间跨度之前,通常不交付任何有价值的东西。

进一步。

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

敏捷通常包括测试。因此,它似乎较慢。

瀑布开发可以与测试完全分开。因此,代码“可以立即进行测试”。但是直到很久以后才“完成”。

所以。他们是完全正确的。对于他们的测量。


8
我不知道是否总是如此-这取决于您(在什么级别上)衡量效率。如果我花了两年时间来完成一个项目,那么我只是花了两年时间来开发所有东西。但是,如果我使用迭代/增量方法,则可能会了解到仅需要实现40%的需求,并且在15个月内实现了40%的产品积压后,项目就成功结束了。这是另一个项目的9个月开发时间。对我来说,这就是效率的提高-我不仅满足了一位客户的所有业务需求,而且已经支持了第二位客户。
Thomas Owens

3
另一种情况是“您得到测量的结果”。衡量错误的事情并没有帮助。
马丁·约克

3
以我的经验,当您拥有非常好的规格时,敏捷方法肯定会慢一些。但是,当您的规范糟透了(通常是这种情况)时,敏捷方法就可以保存项目。当您的产品所有者吸吮时,敏捷/ SCRUM吸人。因此几乎是相同的。如果您可以设想一个非常好的产品,那么这两种方法都可能很快。它对方法的依赖性要小于对分析人员的依赖性。
猎鹰

3
重新声明原始断言实际上并不能回答问题。除传闻外,您是否有其他证据证明该断言是正确的?
Mark Booth,

1
您得到了所要衡量的,这就是您承担的风险。
斯科特,
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.