敏捷项目的成功证据

标签: 项目 成功 证据 | 发表时间:2012-11-27 17:59 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

对敏捷开发实践效果的近期研究结果显示,工作效率及质量正在改善。QSM Associates公司的管理合伙人迈克尔·马(Michael Mah)在ProjectsAtWork网站上题为“ 哥伦布探索敏捷”一文中探讨了这些研究结果:

来自哥伦布地区 [1]参与者的近期研究结果显示,完成一个包含5万行代码的典型业务系统的速度要比从QSM公司已完成项目行业数据库中得出的行业平均值快31%(4.4个月对6.4个月的行业平均值)。更引人注目的是系统的缺陷率,该值比行业惯例低75%。

该结果来自于哥伦布市敏捷工作效率基准项目对位于美国俄亥俄州哥伦布市某编程社区敏捷实践所作的分析。此项目是由QSM Associates公司牵头负责,与俄亥俄州敏捷中央协会(COHAA)及哥伦布市执行官敏捷特别兴趣组协作开展的。该项目不仅为其参与者提供实事求是的信息,还帮助他们解答与处理开发项目进度及预算相关的问题:

调查的参与者能够看到他们自己与整个行业的对比结果;此外,还拿哥伦布社区的区域总体结果与全球数据相比较。

有必要指出的是,研究中的所有参与者并非都是这样——即使他们正致力于敏捷开发——可以达到如此极端的结果,因为所有的参与者都不会全部采用那些能带来成功的最佳实践。

此次对敏捷实践的研究不仅洞悉了外包的结果,而且强调了测量外包的重要性:

研究结果中的首要事实是,同地协作编程团队往往比那些从地理上划分专长的团队更有效。这也是导致重新评估外包软件开发的事实之一。

(……)缺乏在质量及工作效率方面的保证或共同预期,认识到这是导致外包存在这么大风险的主要原因之一有助于使外包变得更成功。也就是说,测量/基准评估有助于双方设置更切实可行的预期,并从而达成一致。

无独有偶,David F. Rico将其对敏捷项目的研究结果发表在题为“ 对新产品及新服务使用敏捷项目管理的商业价值”的论文中。

一份对敏捷项目管理的近期研究显示,在收益、质量、及周期三方面都分别得到了10%到20%的改善,而在成本方面则减少了54%。另一份近期研究显示,在上市时间及成本方面分别减少了50%到60%,同时开发灵活性也提高了10倍以上。

David所写的那篇论文涉及的数据来自若干对敏捷项目管理结果的研究:

敏捷项目管理的好处来自于诸多因素,可谓不胜枚举。对工作效率及质量的提升是其主要驱动因素。工作效率源于其精简的本质,而质量源于不妥协的纪律。然而,其真正力量源于对变化的适应性、协作本质、以及专注于最为关键市场业绩。

在“ 软件质量经经济学”一书中,Capers Jones与Olivier Bonsignour二位作者从以下三个方面着手调查了敏捷实践对软件质量所产生的结果:

  • 敏捷的嵌入式用户(Agile Embedded Users):团队中有用户代表
  • Scrum环节(Scrum Sessions):冲刺、每日站会、以及测试驱动开发
  • 敏捷测试(Agile Testing):使用黑盒测试用例的冲刺

他们写此书的目标是:

(……)为了量化那些影响软件质量的因素,并为读者提供充足的信息,以便他们可以预测并测量其项目及应用程序的质量级别。

InfoQ上的“ 敏捷实践如何带来最高投资回报”一文中给出了几个用于计算敏捷投资回报率(ROI)的例子,并讨论了敏捷实践的好处。

诸如“ 哥伦布探索敏捷”这类研究不仅有助于客观地衡量表现,还有助于确定目标及方向:

该研究(……)所提供的哥伦布敏捷社区具有与工作效率及质量相关的实事求是的宝贵信息,而非单纯的道听途说。此外,这些数据有助于解答与处理开发项目进度及预算相关的问题。

欲阅读全文请访问 Projects at Work网站,需免费注册一下。

 

译注

[1] 哥伦布地区(Columbus)是美国俄亥俄州(Ohio)的首府。详细内容请参阅 维基百科

查看英文原文: Evidence of Success of Agile Projects

译者 高翌翔 基于.NET平台进行Web应用程序设计、开发,关注敏捷开发和架构设计,及各种提高代码可维护性的最佳实践。

您可能也会喜欢

相关 [项目 成功 证据] 推荐:

敏捷项目的成功证据

- - InfoQ cn
对敏捷开发实践效果的近期研究结果显示,工作效率及质量正在改善. QSM Associates公司的管理合伙人迈克尔·马(Michael Mah)在ProjectsAtWork网站上题为“ 哥伦布探索敏捷”一文中探讨了这些研究结果:. [1]参与者的近期研究结果显示,完成一个包含5万行代码的典型业务系统的速度要比从QSM公司已完成项目行业数据库中得出的行业平均值快31%(4.4个月对6.4个月的行业平均值).

如何让第一个试点Scrum项目成功

- - ITeye博客
如何让第一个试点Scrum项目成功. 当我们在尝试应用敏捷开发时,Scrum方法是最容易实施的. 但是如果要想使敏捷开发进行下去,第一个试点的Scrum项目要尽量成功,这样会得到管理层更多的支持. 以下是我们在实践中的一些具体做法:. 1)这个项目是对企业的business有一定影响(但不是最影响的),这样一方面可以得到管理层的支持,如果成功有很强的示范效应,同时由于新方法最初的采纳期间会出现各种各样的问题,有失败或者延期的风险,试点团队不会由于Business的压力重新回到以往熟悉的开发方式上以完成任务.

2012 年十大最成功开源项目

- - 开源中国社区最新新闻
2012年過去了,各開源項目的表現如何. NetworkWorld 的開源專家Alan Shimel總結了在2012年全球十個最為成功的開源項目,從而不難看出IT業界在2013年的新趨勢. 第一個是 Apache Hadoop,海量數據(Big Data)革命掀起的浪潮,帶動了數據分析行業的增長,要在網路上處理這種規模的資料,目前比較經常被使用的平台就是Hadoop,而Facebook就 是使用Hadoop下的HBase資料庫.

IBM百年庆典标志:20个成功的项目 10个失败的项目

- kejian635 - cnBeta全文版
六月IBM将庆祝100周年,eWEEK的决定浏览一下系统巨头也许是最好的产品和技术,以及一些已经有了技术,但没有为公司创造那么好的经济效果的技 术. 凭借IBM在研究和开发的丰富遗产,以及600亿美元的年度研发预算蓝色巨人开发了很多创新技术. 事实上,在1月,IBM宣布,它的发明者在2010 年获得创纪录的5896项美国专利,这标志着它已连续第18年荣登世界最具创意的公司名单.

reCAPTCHA项目

- - 四火的唠叨
文章系本人原创,转载请保持完整性并注明出自 《四火的唠叨》. 要说reCAPTCHA,就要先说一说CAPTCHA,全称是Completely Automated Public Turing test to tell Computers and Humans Apart,即全自动区分计算机和人类的图灵测试,也就是通常说的“验证码”,目的就是要把计算机和人区分开来.

项目集成项目管理之项目范围管理

- - CSDN博客系统运维推荐文章
7.1项目范围和项目范围管理.    项目范围:为完成具有规定特征和功能的产品、服务或结果,而必须完成的项目工作. 7.1.2项目范围管理的作用.    确定在项目内包括什么工作和不包括什么工作;由此界定的项目范围在项目的全生命周期内可能因某种原因而变化,项目范围管理也对这种变化进行管理. 7.1.3项目范围管理的主要过程.

项目的秘密——Programmers(29)

- allentranks - 西乔的九卦
载于《程序员》杂志2011年第9期. 从这一期起,开始在杂志上登出整P的大幅漫画,需要看大图的同学们,讯猛点击下图. 这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友,且以互联网开发背景为主. 如果你有什么可乐的关于程序员的故事、对话、代码,愿意通过漫画的形式分享,请给我发邮件.

绝望的项目——Programmers(21)

- leo - 西乔的九卦
载于《程序员》杂志2011年第1期. 这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友,且以互联网开发背景为主. 如果你有什么可乐的关于程序员的故事、对话、代码,愿意通过漫画的形式分享,请给我发邮件.

5种项目破坏者

- - InfoQ cn
Anders Abel是生活在瑞典斯德哥尔摩的一位软件开发者,他在自己的网站上撰写了一系列文章,箭头直指“项目破坏者”. 该系列的第二篇是《 项目破坏者分类》. Anders观察到的项目破坏者分五种:. 这种悲剧性的人物太没有安全感,一切都对他们充满了威胁. 为了克服他们的不安全感,这种破坏者会做出任何事,使出吃奶的力气,去强调一种特别难得的边界情况,因为他们正好就知道这种情况.

项目经理和Scrum Master

- - InfoQ cn
在博客上,大家对于Scrum Master和项目经理这两个角色依旧争论不休,许多评论员清晰地指出两者的不同,并表示两者不可并存,更不适合合二为一. Steve Hunton在Scrumalliance站点上发布了名为《 Scrum Master并不是项目经理的别名》的博文,他提到:. 与大众的认识相反,Scrum Master和项目经理这两个角色是完全不同的,也不应该混为一谈.