2011年度敏捷软件开发调研结果发布
openkk 12年前
<div id="news_body"> <p> 最近，<a href="/misc/goto?guid=4958331409836779434">VersionOne</a> 揭晓了 2011 年度敏捷软件开发调研结果，再一次向大家展示了敏捷应用和发展趋势的第一手资料。</p> <blockquote> 今年，我们进一步确信敏捷并非一时风潮。我们过半的调查对象坦言他们已经亲身实践敏捷超过两年了，并且三分之一的人把敏捷从一家公司带到了另一家。大约有三分之二的调查对象谈到，他们公司的项目有超过半数在使用敏捷方法，有三个以上团队实施了敏捷实践。 </blockquote> <p> Scrum 依然是敏捷方法流行榜中当之为愧的状元，52% 的受访者采用了 Scrum（2010年则是 58%）。</p> <table class="ke-zeroborder" border="0"> <tbody> <tr> <td>52%</td> <td>Scrum</td> </tr> <tr> <td>14%</td> <td>Scrum/XP 混合</td> </tr> <tr> <td>9%</td> <td>自定义混合</td> </tr> <tr> <td>8%</td> <td>不确定</td> </tr> <tr> <td>17%</td> <td>其它（包括看板 3% 以及 XP 2%）</td> </tr> </tbody> </table> <p> <a href="/misc/goto?guid=4958331410630369451">Matt Badgley</a> 在最近的博文中<a href="/misc/goto?guid=4958331411430249277">探讨了那些“不确定”方法</a>：</p> <blockquote> 我的第一感觉是培训……如果团队没有接受过敏捷概念以及相关方法和流程的培训，那么不难理解，当你问他们：“你们在搞敏捷吗？”……“是的。”“你们用了什么敏捷方法呢？”……“我不确定。”……我想人家回答“不确定”的另一个原因可能是他们正纠结于各个敏捷方法论五花八门的概念中——甚至还混杂着敏捷项目管理和传统项目管理……团队开始时用这个方法，接着糅合了另一种，在一些状况下，还要从每种方法中都取点精髓出来。这种做法有利有弊，它依赖于团队的成熟度和持续改进的能力。 </blockquote> <p> 关于敏捷技术，每日站立会议、迭代计划和单元测试名列前茅（保持着去年的态势）：</p> <table class="ke-zeroborder"> <tbody> <tr> <td>78%</td> <td>每日站立会议</td> </tr> <tr> <td>74%</td> <td>迭代计划</td> </tr> <tr> <td>70%</td> <td>单元测试</td> </tr> <tr> <td>65%</td> <td>发布计划</td> </tr> <tr> <td>64%</td> <td>燃尽图</td> </tr> <tr> <td>64%</td> <td>回顾会议</td> </tr> <tr> <td>54%</td> <td>持续集成</td> </tr> <tr> <td>53%</td> <td>自动构建</td> </tr> <tr> <td>52%</td> <td>速率</td> </tr> <tr> <td>51%</td> <td>编码规范</td> </tr> </tbody> </table> <p> <a href="/misc/goto?guid=4958331412223597647">Simon Baker</a> 在<a href="/misc/goto?guid=4958331413030997137">他名为“敏捷在行动”的博客里面</a>剖析了上述敏捷技术调查结果，他还特别分析了一些得票率较低的实践，如重构（48%）、测试驱动开发（38%）、自动化验收测试（25%）以及行为驱动开发（9%）：</p> <blockquote> 由这些数据我可以推断，软件行业还是在开发很多糟糕的软件，还很过分地把敏捷称为流程。大家还记得个体胜过流程吗？不管怎样，我想知道，投资人花钱买单，但这些糟糕的软件实际上能给客户带来多少价值呢？但愿有一天更多的人能够意识到，做到敏捷其实是要做到快速、经济、低风险地响应不断变化的业务需求。 </blockquote> <p> “项目失败的主要原因”的调查结果很有意思，其中有 16% 的调查对象反应他们的敏捷项目从没有失败过，位列榜首。下面援引了一些排名前列的失败原因：</p> <table class="ke-zeroborder"> <tbody> <tr> <td>11%</td> <td>缺乏敏捷方法相关经验</td> </tr> <tr> <td>11%</td> <td>缺乏对必要的组织层面的变化的认识</td> </tr> <tr> <td>9%</td> <td>企业理念及文化与敏捷理念相冲突</td> </tr> <tr> <td>8%</td> <td>外部要求遵循瀑布模型的压力</td> </tr> </tbody> </table> <p> 进一步实施敏捷的障碍则有：</p> <table class="ke-zeroborder"> <tbody> <tr> <td>52%</td> <td>改变组织文化的能力</td> </tr> <tr> <td>40%</td> <td>是否有足够的专业人士</td> </tr> <tr> <td>39%</td> <td>抗拒改变的惯性</td> </tr> </tbody> </table> <p> 就这些障碍，<a href="/misc/goto?guid=4958331413829910265">Dave Moran</a> 在 <a href="/misc/goto?guid=4958331414620165111">Software Results 上发表博文</a>，分享了他的观点:</p> <blockquote> 这些障碍和担忧映射出我们所熟知的道理：改变是艰难的。而敏捷开发就是一种改变。依照我对调查的解读，我们获得的这些实际收益，恰恰和我们在敏捷实践过程中所期望的是一致的。它们是更快、更易、坚实的每一步。团队士气提升则是实施敏捷能够获得的第四种益处，也是实施敏捷必然的结果。 </blockquote> <p> 调查还显示，75% 的参与者认为运用敏捷方法完成项目的时间和用之前的方法差不多，或者更快些（比 2010 年度的 83% 降低了）。实施敏捷的主要好处有：</p> <table class="ke-zeroborder"> <tbody> <tr> <td>84%</td> <td>管理变更优先级的能力</td> </tr> <tr> <td>77%</td> <td>项目可见性得以改进</td> </tr> <tr> <td>75%</td> <td>生产力得到提升</td> </tr> <tr> <td>72%</td> <td>团队士气有所提升</td> </tr> <tr> <td>71%</td> <td>更快地响应市场</td> </tr> </tbody> </table> <p> 在 VersionOne 站点上，你可以浏览到<a href="/misc/goto?guid=4958331415422140130">完整的调查结果</a>（你同时可以找到<a href="/misc/goto?guid=4958331416224502492">2010年的结果</a>）。今年的调查结果有哪些很突出吗，还是说明敏捷实施趋于稳定了？</p> <p> 查看英文原文：<a href="/misc/goto?guid=4958331417037592625">2011 State of Agile Survey Results Show Agile Adoption Stable</a></p> <div id="come_from"> 来自: <a id="link_source2" href="/misc/goto?guid=4958331417837379390" target="_blank">InfoQ</a> </div> </div>