用 Safari 11+、Firefox 70+ 浏览效果最佳
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> 敏捷 > > 敏捷 >
在线/38 登录/0

敏捷的现状

阅读数:13.5K
基本历史


哪些企业敏捷了?


榜样的力量是无穷的。

记得 2005 年之前 CMM 热的时候,举国有一个榜样:

Motorola

大家都以高居 CMM L5 的 Motorola 公司为学习的楷模。可是,一些不识时务的居然还问:

微软是 CMM 几级?什么时候微软 CMM 了,我们就 CMM。

这回,轮到 CMMI 和敏捷了。

这几年,从媒体、社区和坊间的报道、消息看,领头搞敏捷的好像有这么几家:

IT 类

微软、IBM ...

google: Microsoft Agile

google: IBM Agile

互联网类

Google、Yahoo、eBay、腾讯 ...

通信类

BT(British Telecom,英电)、NSN(Nortel Siemens Networks,诺西)、Alcatel-Lucent(阿朗)、爱立信、华为 ...

google: British Telecom Agile

google: NSN Agile(有两篇 PPT 很不错)

(请大家补充)


这些企业可以说都是行业内一些最先进、最成熟的领导企业,可是为什么他们还会不满足,还要尝试敏捷改进呢?这值得我们思考。

显然,他们不是为了去拿一个什么证,以便向同行、客户和领导们汇报和展示,以便取得某种市场名义上的优势 ... 事实上,在技术、管理、创新等许多方面他们已经很成熟、很优秀了,甚至可以说卓越。同时,他们也已经在各自的领域里占据了很大的市场份额,已经是行业标准、标杆的树立者,足以成为各级各类尊贵证书的创立者和颁发者。

以上,您能看出一个明显的趋势。

这次敏捷过程改进,好像又是通信、互联网等企业领先一步。早在 2002 年我就听说了,国内先尝敏捷这只螃蟹的,主要还是一些外企、跨国和合资企业,大、中、小型的都有。而目前本土企业绝大部分可能还在观望、调研和等待中。

我预测 2020 年之前在中国一定会掀起一道巨大的敏捷过程改进浪潮。


如今,敏捷方法在国际上的应用情况如何,流行、火爆到何种程度?我向您推荐以下两个著名的敏捷应用调查报告。

这两份报告中都有不少值得解读的地方,待我们细细看来。

如果您是一名软件企业、研发机构的开发人员,建议您尽快把以下这些数据和分析结果告诉您的上司和领导;如果您是一名软件企业、研发机构的管理人员,建议您尽快想办法让自己上司和领导乃至公司的高级管理层(包括 CEO)阅读这份报告。

VersionOne 调查


The State of Agile Development, VersionOne (3rd Annual Survey: 2008)
www.versionone.com/AgileSurvey/
直接下载 PDF 文件

VersionOne, Inc. 是一家提供敏捷项目管理工具的知名厂商。

该调查的数据采集时间为 2008 年 6-7 月,可以说是最新的。收到了来自 80 多个国家和地区、共 2319/3061 份答卷,迄今为止我所看到的一份样本量最大、参与者最多、内容最为全面的一次敏捷应用情况调查。我觉得这份统计报告在许多方面,还是很有说服力的。

人们常常问,我们为什么要敏捷?回答当然是,因为敏捷能带来很多好处,众所周知的包括:提高生产率、提高质量、提高客户和员工满意度、缩短交付时间等等。统计数据证实了这一点。

Increased Productivity – 89% of respondents
Reduced Software Defects – 84% of respondents
Accelerated Time-to-Market – 82% of respondents
Reduced Cost – 66% of respondents

以上前三项结果都超过了 80%,可以说在被调查者中达成了高度的一致,大家都见证、认同了敏捷所带来的明显好处。

一个明显趋势,采用敏捷方法的团队规模(人数)正变得越来越大,更多地理上分布的团队开始实践敏捷:

32% of respondents are from development groups with over 250 people
76% of respondents are from development groups with over 20 people

居然团队人数大于 250 人的超过了 1/3,接近 2/3 的团队人数超过了 20 人。这说明敏捷方法只适用于 20 人以下小团队的观点是错误的。

我关注的其他几点:

敏捷带来了哪些好处

最流行的敏捷方法

常用的敏捷实践做法

常用的敏捷工具

敏捷能带来哪些好处?VersionOne 的《敏捷开发的现状 2008》报告对此进行了统计。

以下百分比是改善或显著改善的得票率(2319 人),改善或提高是指比以前提高了 10% 以上。

* 减少风险(约 65%)

* 提高项目的可见性(>82%)

* 提高生产率(>73%)
* 加速上市时间(约 65%)

* 提高质量(>68%)
* 增加软件的可维护性和可扩展性(约 56%)

* 简化开发过程(>67%)
* 加强工程的规范性和纪律性(Discipline)(约 60%)

* 提升团队士气(约 74%)

* 促进 IT 和业务部门的协调(>65%)

* 增强了管理优先级变更的能力(>92%)


以上这几项好处都得到了大多数投票者的肯定,最低的票数也超过了 50%。

当然,实施敏捷改进可能带来的好处应该还不只这些选项。

其中,只有两项获得改善的得票率较低(不到 50%):

* 减少成本(改善的占 38%,没好处的占 39.5%,更糟的占 6%)

* 更好地管理分布式团队(改善的占 29%,没好处的 >40%,更糟的 <5%)


Scrum 在 Yahoo!


以上是针对全球 80 个国家和地区的 2300 多名受访者的统计结果,下面我们再看一个世界知名大型互联网企业内部的统计调查结果。

The Scrum Primer (Pete Deemer et al) 的最后一节 Results from Scrum 中介绍了作者们在 Yahoo! 公司进行的统计结果。他们在 3 年多的时间里帮助 Yahoo! 公司的近 200 个团队完成了到 Scrum 的转换,涉及到 2000 多人,每年他们都要对该公司采用 Scrum 的所有人(2000)进行多次效果满意度的调查。

主要的结果数据(与传统方法相比实施 Scrum 后获得改善或显著改善的得票率)为:

生产率提升 68%
团队士气提升 52%
适应能力(Adaptability)提升 63%
责任性(Accountability)提升 62%
协作能力提升 81%


此外,根据产品负责人的估计,所有团队的生产率平均提高了 36%;近 85% 的团队成员表示,如果完全由他们自己决定,他们肯定还将继续选择采用 Scrum。

看到以上数据,我想您和我的感受是一样的。不论著名的 VersionOne 年度报告,还是 Yahoo! 公司内部的调查,受访对象均超过了 2000 人,而结果都是相当令人鼓舞的。(今后我还将对更多类似的统计数据,包括来自微软、IBM、Google、NSN 等企业的统计调查结果进行分析。)

我们有什么理由不敏捷呢?

Scrum 是目前最流行的敏捷方法


在 VersionOne 2008 的这份报告中我们看到,采用(Follow)Scrum 的比例高达 49%,Scrum/XP 联合采用的达到 22%,而单纯只采用 XP 的排在第三占 8%,其他各类方法一共占 29%。

其他几个选项得票率均在 8% 以下,排名依次为:Custom/hybrid, Don't know, AgileUP, Other, FDD, Lean, DSDM, OpenUP, Agile Modeling, Crystal 等。我觉得漏掉了 MSF For Agile,今后应该补上。

采用 Scrum 加 Scrum/XP 的超过了 70%,占绝对优势,可见 Scrum 和 XP 的知名度与影响力,而在普及程度上 Scrum 比 XP 更胜一筹。这说明,大家在实施敏捷改进的时候,Scrum 和 XP 是很好的参考框架和模型,不管最终能否用得上,都应当认真研究和学习,属于必修课。

Scrum 和 XP 都不全面

如何理解这些民调数据?实际上,作为过程方法 Scrum 和 XP 都是不完整、不全面的,在实际的软件项目管理和开发中不能单独采用。Scrum 是一个轻量级的敏捷项目管理框架,框架则意味着它本身是一个半成品(半熟的),在实践中我们还需要开动自己的大脑添加更多其他的东西,需要在敏捷价值观和原则的指导下,把 Scrum 与其他方法,包括行之有效的传统方法,结合起来运用。

对于国内的敏捷改进,我通常向客户推荐的一种方案是:IID + Scrum + UP + XP + X,也就是一种先打碎,然后混合、融合、集成的方案。作为太极敏捷思想方法的倡导者,我个人历来倾向于 process mashup, integration, synergy, unification 或 hybrid 方案,主张兼收并蓄、融汇贯通。相信很多人会和我有类似的看法,这么做有很多好处。其实没有哪一种方法、模型、标准能够包打天下,CMM/CMMI 不行,RUP 不行,Scrum、XP 当然也不行。

IID 代表迭代递增式开发,已有超过 40 多年的发展历史,是 Scrum、UP、XP 等当代敏捷方法所共有的前身和基础。我把 IID 单独拿出来,是为了引起大家的注意,敏捷改进最好先从 IID 做起。

为什么 Scrum 远比 XP 更流行?

在过去几年当中,国内 XP 的知名度可以说远高于 Scrum,某些媒体、企业和个人都对之大加赞赏、竭力宣传。谁都知道,XP 的背后有一家公司,有一位大师,还有一位鼓噪者。公司和大师起到的作用是正面、积极的,而鼓噪者起到的作用是消极的。人们在 XP 宣传上的投入也曾经远大于 Scrum,这导致很多人都误以为:敏捷 = XP。因此,可能很多人看到这些数据,会感到意外,怎么 Scrum 后来居上,XP 反而叫好不叫座,为什么会有这种反差?

这背后的原因,不同的人有不同的解读。我想,这可能与专家们的努力,相关企业和组织的 marketing,是否采用了认证方式等等外在因素与内在因素有关。

张恂认为,XP 的普及程度明显不如 Scrum,可以用太极敏捷思想的极限法则来解释:越极限、越极端的东西,其适用面往往越小,这大概就是 XP 不如 Scrum 的内在原因。实际上,我们发现成功采用 XP 的前提条件、适用条件比 Scrum 更严格,XP 对于某些工程做法的规定更具体,诸如 TDD(测试驱动开发)、PP(结对编程)、CI(持续集成)等做法的效果到底怎么样在国内外科学工程界也一直存在着不少争议,当然 TDD、PP、CI 等做法并不是成功的敏捷实施所必需的(尽管某些企业和个人,出于自身利益的考虑,强烈迫使您坚信这一点),这些因素都可能限制、约束了它的发展。

Scrum 只保留了敏捷项目开发的一个最小的 IID(迭代递增式开发)管理框架,没有对具体的工程做法(比方如何做设计,如何编程,如何测试等等)作硬性规定,这样就给它带来了很大的灵活性和可扩展性,便于和其他方法结合,这正是 Scrum 的聪明之处。

国内的情况又如何?

这两年,我们陆续看到了一些 Scrum 应用案例的报道,主要来自一些外企、合资企业以及个别互联网企业,真正的 XP 应用则很少听说,好像几乎没有。

在这些为数不多国内敏捷案例中,我们发现有许多是伪 Scrum、伪 XP 案例,根本违背了敏捷价值观和原则,其企业管理、团队文化也与敏捷文化的要求格格不入。所以,总体上,我们感觉国内的敏捷应用还是处于比较初级的、概念了解与学习阶段。概念不清、理解错误,不可能做到真正的敏捷。

我的判断是,由于市场环境、东西方文化、发展阶段等方面的差异,国内大部分软件企业、研发组织可能一时难以做到真正的 Scrum 或 XP,敏捷改进从做到较为容易的 IID 开始是一个可行的方案。

敏捷做法知多少?

从高到低依次为:

Iteration Planning
Unit Testing
Daily Standup(scrum)
Release Planning
Contiunous Integration
Automatated Builds
Burndown
Retrospectives
Refactoring
Coding Standards
Velocity
TDD
Open Work Area
Collective Code Ownership
Digital Taskboard
Analog Taskboard
Taskboard Combined
On-Site Customer
Pair Programming
BDD(行为驱动开发)
Kanban(看板,精益方法)

以上主要是一些 Scrum 和 XP(v1)做法的汇集。

有一些做法是敏捷方法共性的,必需的,比方发布计划、迭代计划、自动构建、回顾等等。

我更关心,哪些做法的采用率不高。除了 2008 年统计新添的 BDD 和看板,落在最后的是两个,结对编程和现场客户。

有哪些敏捷工具?

前几位厂家产品排名(7% 以上),从高到低依次为(这里主要是项目管理工具):

Microsoft Excel
Microsoft Project
Other
VersionOne
In-house/homegrown
JIRA
Bugzilla
IBM Rational

有趣的是,名列冠亚军的分别是微软的 Excel 和 Project,得票率分别达到了 36% 和 24%,合并超过了 60%,这可能让一些人感到意外,我觉得这其实也在意料之中。

其他常用的敏捷工具种类包括:

Wiki
Spreadsheet
Unit Test Tool
TaskBoard
Automated Build Tool
Index Cards
Bug Tracker
Automated Acceptance Tool
Requirements Management Tool
Kanban board
Agile Project Management Tool
Refactoring Tool
Continuous Integration Tool

Scott Ambler’s Agile Adoption Survey

642 份答卷

54.8% were developers, 29.4% were in management
41.6% had 10-20 years IT experience, 37.2% had 20+ years
37.7% worked in orgs of 1000+ people
71% worked in North America, 17% in Europe, 4.5% in Asia

<帮助> <全部评论> 共 0 个主题 0 条评论 (AgileSurvey)
首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2020 张恂 版权所有. 沪ICP备15017521号-2