2011年度敏捷软件开发调研结果发布

最近，VersionOne揭晓了2011年度敏捷软件开发调研结果，再一次向大家展示了敏捷应用和发展趋势的第一手资料。

今年，我们进一步确信敏捷并非一时风潮。我们过半的调查对象坦言他们已经亲身实践敏捷超过两年了，并且三分之一的人把敏捷从一家公司带到了另一家。大约有三分之二的调查对象谈到，他们公司的项目有超过半数在使用敏捷方法，有三个以上团队实施了敏捷实践。

如果你看到这段文字，说明您正使用RSS阅读或转自《一棵树-博客园》，原文地址：http://www.cnblogs.com/atree/archive/2012/03/02/2011_state_agile.html

Scrum依然是敏捷方法流行榜中当之为愧的状元，52%的受访者采用了Scrum（2010年则是58%）。

Matt Badgley在最近的博文中探讨了那些“不确定”方法：

我的第一感觉是培训……如果团队没有接受过敏捷概念以及相关方法和流程的培训，那么不难理解，当你问他们：“你们在搞敏捷吗？”……“是的。”“你们用了什么敏捷方法呢？”……“我不确定。”……我想人家回答“不确定”的另一个原因可能是他们正纠结于各个敏捷方法论五花八门的概念中——甚至还混杂着敏捷项目管理和传统项目管理……团队开始时用这个方法，接着糅合了另一种，在一些状况下，还要从每种方法中都取点精髓出来。这种做法有利有弊，它依赖于团队的成熟度和持续改进的能力。

关于敏捷技术，每日站立会议、迭代计划和单元测试名列前茅（保持着去年的态势）：

52%	Scrum
14%	Scrum/XP混合
9%	自定义混合
8%	不确定
17%	其它（包括看板 3%以及 XP 2%）

78%	每日站立会议
74%	迭代计划
70%	单元测试
65%	发布计划
64%	燃尽图
64%	回顾会议
54%	持续集成
53%	自动构建
52%	速率
51%	编码规范

Simon Baker在他名为“敏捷在行动”的博客里面剖析了述敏捷技术调查结果，他还特别分析了一些得票率较低的实践，如重构（48%）、测试驱动开发（38%）、自动化验收测试（25%）以及行为驱动开发（9%）：

由这些数据我可以推断，软件行业还是在开发很多糟糕的软件，还很过分地把敏捷称为流程。大家还记得个体胜过流程吗？不管怎样，我想知道，投资人花钱买单，但这些糟糕的软件实际上能给客户带来多少价值呢？但愿有一天更多的人能够意识到，做到敏捷其实是要做到快速、经济、低风险地响应不断变化的业务需求。

“项目失败的主要原因”的调查结果很有意思，其中有16%的调查对象反应他们的敏捷项目从没有失败过，位列榜首。下面援引了一些排名前列的失败原因：

11%	缺乏敏捷方法相关经验
11%	缺乏对必要的组织层面的变化的认识
9%	企业理念及文化与敏捷理念相冲突
8%	外部要求遵循瀑布模型的压力

进一步实施敏捷的障碍则有：

52%	改变组织文化的能力
40%	是否有足够的专业人士
39%	抗拒改变的惯性

就这些障碍，Dave Moran在Software Results上发表博文，分享了他的观点:

这些障碍和担忧映射出我们所熟知的道理：改变是艰难的。而敏捷开发就是一种改变。依照我对调查的解读，我们获得的这些实际收益，恰恰和我们在敏捷实践过程中所期望的是一致的。它们是更快、更易、坚实的每一步。团队士气提升则是实施敏捷能够获得的第四种益处，也是实施敏捷必然的结果。

调查还显示，75%的参与者认为运用敏捷方法完成项目的时间和用之前的方法差不多，或者更快些（比2010年度的83%降低了）。实施敏捷的主要好处有：

84%	管理变更优先级的能力
77%	项目可见性得以改进
75%	生产力得到提升
72%	团队士气有所提升
71%	更快地响应市场

在VersionOne站点上，你可以浏览到完整的调查结果（你同时可以找到2010年的结果）。今年的调查结果有哪些很突出吗，还是说明敏捷实施趋于稳定了？

查看英文原文：2011 State of Agile Survey Results Show Agile Adoption Stable

译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。