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

标签: 软件开发 结果 | 发表时间:2012-03-02 00:00 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

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

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

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

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

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

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

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

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 MoranSoftware Results上发表博文,分享了他的观点:

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

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

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

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

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

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

相关 [软件开发 结果] 推荐:

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

- - InfoQ cn
最近, VersionOne揭晓了2011年度敏捷软件开发调研结果,再一次向大家展示了敏捷应用和发展趋势的第一手资料. 今年,我们进一步确信敏捷并非一时风潮. 我们过半的调查对象坦言他们已经亲身实践敏捷超过两年了,并且三分之一的人把敏捷从一家公司带到了另一家. 大约有三分之二的调查对象谈到,他们公司的项目有超过半数在使用敏捷方法,有三个以上团队实施了敏捷实践.

软件开发的核心

- - 博客园_知识库
  「我们一直这样做开发,时间做久了,便忘了当初的本意.   有关软件系统开发,我们谈些什么.   我们谈过程,编码规范、开发流程、同行评审、结对编程、持续集成,从瀑布到敏捷再到极限编程.   我们谈架构,企业级、J2EE、容器化、SOA(面向服务架构)、Microservices(微服务化).   我们谈规模,大容量、高并发、大数据.

软件开发的“三重门”

- - 酷壳 - CoolShell.cn
自从上次写了“ 程序员技术练级攻略” 以来,就觉得似乎还有很多东西没有谈到,但当时没有继续思考了. 而春节前有人问我,是做底层技术,还是做业务. 这问题让我思考了很多,不由自主地回顾了一 下我这十多年的软件开发经历,并顺着整理分类了一下自己解决过的若干问题,还发散想了很多,经过了一个春节假期的发酵,产生了下面这篇文章.

软件开发的人文关怀

- - 博客园_知识库
  几年前,我从温伯格的《技术领导之路》中学到一点:技术人员往往更喜欢和机器打交道,因为他们“认为”自己更适合和机器打交道;但是,优秀的技术人员必须(也必然)具备好的沟通能力. 所以,温伯格鼓励各位技术人员多加练习和其他人打交道的能力. 温伯格的这个观点我是非常赞成的,好的技术人员一定需要“勇敢”面对他人,不能被“自实现的预言”局限在机器的世界里.

软件吞噬软件开发

- - PingWest中文网
软件蚕食世界,自互联网特别是移动互联网连接线上线下服务后,已成为不可逆的趋势. 每一项实用的服务可以由小团队来完成. 以WhatsApp为例,这款被高调收购的IM应用,拥有4.5亿月活跃用户,70%的日活跃率,至今还保持每天新增用户1000万的速度. 但这些服务居然由32名工程师支撑下来了,所以有了业界八卦“每位员工价值20亿”的说法.

软件开发中的两种态度

- - 外刊IT评论网
一种态度认为,应该对程序员在软件开发中的行为进行约束( DirectingAttitude). 持这种态度的人认为大部分的程序员水平都不高(谣传说有50%的人低于平均水平),所以应该对他们所做的事情进行管教约束. 要防止他们做一些可能会给他们正在开发的系统带来危害的事情. 通常,这种态度体现在一些系统设计和工具中时,你会发现它们会试图阻止程序员去做某些事情,限制程序员的一些做法,以此避免他们陷入过于复杂的境况.

软件开发的人文关怀

- - 极客公园-GeekPark
我是极客公园黑板报认证值日生. [核心提示]软件可以没有活力,而软件开发却不能没有活力;程序可以像机器一样,程序员却不能像机器一样. 要改变这种状态,就应当增添更多的人文关怀,把开发人员当成活生生的人,而不是视为程序或者工具. 编辑注记:本文来自余晟的博客 乱象,印记. 作者从自己的经验出发,提出了一些给软件开发人员提供人文关怀的可行措施.

软件开发模型综述

- - CSDN博客推荐文章
                     软件开发模型概述. 最早出现的软件开发模型是1970年W·Royce提出的瀑布模型. 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架. 软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段.

防火长城内的软件开发

- - Solidot
对于软件开发者来说,防火长城不只是屏蔽网站过滤流量这么简单——它是痛苦之源,尤其是如果你想开发针对中国市场之外的软件或想利用广泛使用的服务和软件库的话. 上海聊天机器人创业公司Rikai Labs的创始人DC Collier认为,中国的软件开发者写代码的时候一只手是绑在背后的. 防火长城的屏蔽范围日益扩大,这意味着越来越多的服务被永久性或不定期的屏蔽.

自上而下的软件开发和自下而上软件开发

- - 外刊IT评论网
自上而下(Top Down)开发模式是指从一个应用的最高点开始开发. 从最高点逐步往下层编码,直到开发完所有的任务. 一旦写完了最下层的代码,开发任务就完成了. 使用这种方式,你需要设计、编写出所有你需要的但还没有实现模拟接口、服务、伪代码. 自下而上(Bottom up)开发模式是指从一个应用的最底层开始开发.