2011年度敏捷软件开发调研结果发布作者 Craig Smith 译者 金毅 发布于 2012年3月1日 
最近，VersionOne揭晓了2011年度敏捷软件开发调研结果，再一次向大家展示了敏捷应用和发展趋势的第一手资料。 今年，我们进一步确信敏捷并非一时风潮。我们过半的调查对象坦言他们已经亲身实践敏捷超过两年了，并且三分之一的人把敏捷从一家公司带到了另一家。大约有三分之二的调查对象谈到，他们公司的项目有超过半数在使用敏捷方法，有三个以上团队实施了敏捷实践。 Scrum依然是敏捷方法流行榜中当之为愧的状元，52%的受访者采用了Scrum（2010年则是58%）。
Matt Badgley在最近的博文中探讨了那些“不确定”方法： 我的第一感觉是培训……如果团队没有接受过敏捷概念以及相关方法和流程的培训，那么不难理解，当你问他们：“你们在搞敏捷 吗？”……“是的。”“你们用了什么敏捷方法呢？”……“我不确定。”……我想人家回答“不确定”的另一个原因可能是他们正纠结于各个敏捷方法论五花八门 的概念中——甚至还混杂着敏捷项目管理和传统项目管理……团队开始时用这个方法，接着糅合了另一种，在一些状况下，还要从每种方法中都取点精髓出来。这种 做法有利有弊，它依赖于团队的成熟度和持续改进的能力。 关于敏捷技术，每日站立会议、迭代计划和单元测试名列前茅（保持着去年的态势）：
Simon Baker在他名为“敏捷在行动”的博客里面剖析了上述敏捷技术调查结果，他还特别分析了一些得票率较低的实践，如重构（48%）、测试驱动开发（38%）、自动化验收测试（25%）以及行为驱动开发（9%）： 由这些数据我可以推断，软件行业还是在开发很多糟糕的软件，还很过分地把敏捷称为流程。大家还记得个体胜过流程吗？不管怎样，我 想知道，投资人花钱买单，但这些糟糕的软件实际上能给客户带来多少价值呢？但愿有一天更多的人能够意识到，做到敏捷其实是要做到快速、经济、低风险地响应 不断变化的业务需求。 “项目失败的主要原因”的调查结果很有意思，其中有16%的调查对象反应他们的敏捷项目从没有失败过，位列榜首。下面援引了一些排名前列的失败原因：
进一步实施敏捷的障碍则有：
就这些障碍，Dave Moran在Software Results上发表博文，分享了他的观点: 这些障碍和担忧映射出我们所熟知的道理：改变是艰难的。而敏捷开发就是一种改变。依照我对调查的解读，我们获得的这些实际收益， 恰恰和我们在敏捷实践过程中所期望的是一致的。它们是更快、更易、坚实的每一步。团队士气提升则是实施敏捷能够获得的第四种益处，也是实施敏捷必然的结 果。 调查还显示，75%的参与者认为运用敏捷方法完成项目的时间和用之前的方法差不多，或者更快些（比2010年度的83%降低了）。实施敏捷的主要好处有：
在VersionOne站点上，你可以浏览到完整的调查结果（你同时可以找到2010年的结果）。今年的调查结果有哪些很突出吗，还是说明敏捷实施趋于稳定了？ |
|
|
