低代码到底是不是行业毒瘤?一线大厂怎么做的?戳此了解>>> 了解详情
写点什么

敏捷简况:你是否已经落伍?

The state of agile adoption

2016 年 1 月 24 日

这篇白皮书的目的是为读者描绘出敏捷方法在世界范围内的采用情况。关于这一技术的优缺点已经有许多相关资料,不过关于敏捷方法采用的广泛性的数据目前仍鲜有披露。本文将通过从我们的公众消费数据库中提供数据改变这一现状。如图一所示,基于来自 330 个组织的数据,敏捷方法已经成为世界范围内占统治地位的软件开发模式。这其中的一些组织是我们获取数据的 120 个公司或政府组织的分支机构。图二汇总了不同的敏捷方法在这些组织中的使用情况。由于许多组织反馈他们正在使用混编的方式,即,将敏捷和传统的概念相结合,我们已经将他们的回复包含在统计中,并将其归类为混编或混编 / 精益(敏捷与精益相结合)。

图一:世界范围敏捷简况(组织数量)
图例

  • EA - 早期采用者(31)- 2004 至 2009 年就在公司范围内引入敏捷方法的组织
  • EM - 早期多数(166)- 2009 至 2014 期间在公司范围内引入敏捷方法
  • LM - 晚期多数(77)- 目前正在引入敏捷方法
  • 落伍者(46)- 正在考虑,但目前尚未使用敏捷方法的组织

我们使用由摩尔 1 开发的技术引入的生命周期模型来标识采用敏捷方法的公司所处的阶段。作为这一模型应用的一部分,基于 Riddle 和 Redwine2 的研究,我们假设像敏捷这类技术需要 18 年±3 才能够完全采用。技术采用的如下四个阶段,如图 3 所示:

  • 早期采用者——这一阶段的组织在敏捷仍处于早期时就已经将其应用于日常工作中,以获得最大的收益。他们会承担这些方法附带的一些风险并与供应商一道逐步优化它们。其主要挑战是方法的稳定性。
  • 早期多数——这一阶段的组织在敏捷方法开始收到好评时跟随潮流采用这一方法。值得一提的是,在这一阶段,早期采用者会在整个组织范围内推广并使用敏捷方法。这一阶段的首要动机仍然是收益。主要挑战则是推广。
  • 晚期多数——更多相对谨慎的组织在这一阶段开始跟随潮流采用敏捷方法。这些公司一直在等待直到它们认为一切都趋于稳定,之后就会加速以争取收益。大多数组织都会采用常规的变更管理流程,首先得到管理层的支持,之后进行培训、试用、采用并在供应商的帮助下形成方法论,最后逐渐优化产品以在组织范围内使用。

图 2:世界范围内敏捷方法的采用情况(组织的数量 +)

注:
+ 按照地理区域划分的组织分布比例:美国和加拿大(50%),欧洲(30%),亚洲(17%),澳大利亚(3%)

  • 落伍者——无论何种原因仍坚持现有方式的组织。大多数组织正在考虑迁移至敏捷方法。不过,可能出于各种各样的商业考虑,仍然坚持当前的做事方式。无论原因如何,他们目前仍未从敏捷方法的采用中受益。

图 3:技术采用的阶段 1

注:
1 Geoffrey Moore,Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers,Harper,1999。
其中的鸿沟指的是早期多数采用该技术所需花费的时间成本。这是相当困难的一段时间,因为在这段时间里需要投入大量的精力让大多数用户停止手头的工作,以全新的方式开展业务。

敏捷方法在政府和工业的采用情况对比

表 1 对比了敏捷方法在政府和工业上的采用情况。不出所料,政府的采用情况要比工业滞后。不过令人惊奇的是,欧洲的政府机构,主要是英国,拥抱敏捷方法的时间要比美国的政府机构早 5 到 8 年。从该表的数据中还可以得出如下结论:工业上的采用高峰已经成为过去时。政府机构的落后缺口大概在 5 到 7 年。此外还可以看出超过半数的工业组织已经远远超越技术引入生命周期的早期采用者阶段。
需要注意的是,目前所搜集到的数据还不足以完成针对所有地理区域的表格。例如,由于缺乏加拿大和巴西的相关数据,我们的图表中只包含了美国,而不是整个美洲。此外,为了突出英国在这一区域的敏捷采用领导地位,我们将其从欧洲数据中单独抽离出来。

EA* EM* LM* Laggards*Europe (38)+ - Industry (36) 22% 44% 25% 9%- Government (3) 33% 33% None 34%United States (108) - Industry (97) 19% 39% 25% 17%- Government (11) 36% 27% None 27%United Kingdom (48) - Industry (41) 12% 49% 22% 17%- Government (7) 29% 29% 13% 29%表 1:按照工业 / 政府和地理区域划分的处于各个技术采用阶段的采用者比例(括号内为绝对数量)

图例
+ 该数字中不包含英国 * 数字中包括我们拥有数据的组织
EA——早期采用者
EM——早期大多数
LM——晚期大多数
落伍者——正在考虑是否采用敏捷

早期大多数采用者的经验教训

来自于早期大多数采用者的经验为其他有兴趣将敏捷方法引入组织的人铺平了道路。这些经验是极具价值的,因为他们已经经历了整个转换过程,探索了相关的技术,并且在开发流程中将它们最终所采用的方法应用到工作当中。已经采用敏捷方法的组织认为在首次采用时,如下成功秘诀 3 是相当重要的:

  • 定义转化目标和期望,如,在某一组织中还是在整个企业范围内采用敏捷方法,并基于此制定成功的相关衡量标准。
  • 将敏捷转换的成果与公司的商业目标紧密联系在一起,并相应地定制成功的衡量标准。
  • 培训管理团队,如,从高管开始,由上至下;得到高管的支持;然后让他们参与其中,在整个开发过程中始终保持知情。
  • 培训整个组织,包括客户,让他们了解到为什么你会做出这些改变。
  • 选择将要采用的敏捷方法,在使用过程中培训团队成员,并在试点项目中使用敏捷方法时进行裁剪;举例来说,至少每个组织中有一个试点项目会使用敏捷方法。
  • 让试点团队定义一系列采用敏捷方法的规则、度量标准以及流程。确保这项额外的工作不会让团队负担太重,导致项目失败。
  • 作为试点项目的一部分,开发一个在推广过程中会使用的培训人员的培训计划。并确保在课件中使用真实的项目制品和项目经验作为示例。
  • 在当前及后续的项目中剪裁使用敏捷方法的同时不断优化它。
  • 在试点项目接近尾声时,制定相应的行动计划及里程碑,在组织范围内或者整个企业范围内推广敏捷方法。如果有必要,成立独立的团队为转型做准备,为争取成功提供基础和先决条件。
  • 试点项目结束时发表一篇回顾,确保其中的经验教训得以留存。

当我们在组织层面或企业层面推广这项技术时,下面这些工作可以帮助加速这一过程。

  • 始于小,成就大。逐步积累的小的胜利最终通常都会转变成大的成功。
  • 让试点项目中的敏捷老手和有经验的项目成员领导接下来的项目并培训其他员工。
  • 如果使用 Scrum4,建立一个 Scrum Master 团队,以便能够有效利用他们。
  • 与产品负责人合作并帮助他们理解他们的角色;例如,他们需要为任务设定优先级并且作为客户的代言人,而非仅仅作为项目经理。
  • 接受测试先行的理念,实现回归测试自动化;举例来说,尽可能地自动化那些你设定为基线并在每次迭代时用于重新验证部署包的测试用例。
  • 在每天的站立会议中发现风险,之后根据其可能带来的影响确定风险的优先级并有效管理这些风险。
  • 在寻找减少浪费的机会时,借助质量保证人员的帮助。理解当事态严重时,质量可以作为鉴别器提出反对意见。
  • 有效利用数字;譬如,根据所定义的指标和衡量标准进行管理。
  • 通过人际网络、即时通讯和宣传活动,在员工之间传播信息,从而形成变革的动力,公司和雇员均能从中受益,而且也十分有趣。

在成熟的敏捷流程开发操作当中,下面这些理念可能会有所帮助:

  • 持续不断地进行自身优化和改造。否则将会失去改革的动力,相关的倡议也将随之终结。将回顾作为一个学习的工具。改造可能很简单。勇于接受好的新鲜事物。例如,采用敏捷方法时,结合精益。二者既相互兼容又互为补充。
  • 对基础设施进行改造并将过程制度化。这并不意味着要像 CMMI®5 那样设置过程小组并指导评估。而是需要提供一本学习手册并进行相应的培训。为支持团队建立角色,同时为产品负责人和 Scrum Master 这些新的工作类型提供职业发展路径。此外,将质量保障人员的工作职责定义为让产品质量成为产品设计的一部分,而不仅仅是质量检查。
    最后,随着敏捷的规模逐渐扩大,要对项目管理的角色和职责优化时刻保持关注。让他们成为同步信息和协调工作的角色,而不是封建统治者。如果你认为将敏捷方法和传统方法相结合会更加有效,可以学习诸如规范敏捷交付(DAD)6 这类方法,以寻求实现二者之间平衡的启示。

落伍者如何奋起直追

落后并非一定是件坏事。如果足够聪明,我相信你可以节省进行敏捷转换所需的时间和精力。无需经历整个过程,你可以利用下面这些捷径在两三年内就迁移至敏捷方法,而不需要四五年的时间。

  • 通过购买一家公司并将其员工作为敏捷的主要劳动力的方式获取最初的敏捷能力,而不是从头组建。如果能够在你的业务当中快速地采用他们已经接受的方法,就可以省去大概一年的试点时间和大约 10 人年的工作量。要想漂亮地完成收购,关键人员条款和奖金是必不可少的。这些合同条款主要目的在于在并购当中挽留你所寻求的关键资源,即有经验的敏捷方面的人才。
  • 如果无法并购团队,考虑雇佣一个有资质的公司协助完成这项工作。当你正在按照合同开发产品并且可以用支付账单的方式将成本转嫁给第三方时,这是一个不错的策略。确保候选人会将你的最佳利益放在心上,而不是仅仅将合同看作是收入来源。采用双赢的条款确保合作各方均能从中受益。让对方提出一些希望得到的利益。例如,请他们考虑提供免费的培训和 / 或工具,以展现他们合作的诚意。作为你对他们承诺的一部分,可以为其提供推荐和客户评价。
  • 避免使用顾问。尽管某些情况下,顾问能够提供一些帮助,大多数情况下他们只会为了自身利益榨取他人。将敏捷顾问公司作为一个候选方案。如果他们能够提供解决方案,可以考虑并购或者成为其合作伙伴。
  • 集中精力在根本问题上。作为转换的一部分,不断收集数据,让批评家们闭嘴。用数字向拥护者和批评者展示敏捷是更好的方式。真实的数据总能帮助我在争论中占据上风。我确信这对你来说也同样有效。

总结

在本篇白皮书当中,向大家介绍了敏捷方法。上述数据表明,敏捷方法已经不再是一种新兴的技术。虽然目前政府部门有些落伍,但这并不意味着他们就应该等待。总而言之,那些刚刚启动它们的敏捷之路的企业已经落后于采用曲线。他们需要采取更强势地行动否则他们会发现工作难以完成。
为了提供一些帮助,我还为那些仍在敏捷采用的修炼旅途上的人们提供了经验和教训的总结。早期采用者和技术推广阶段的用户都会发现这些建议将会让他们少走一些弯路。
最后,对于那些正在考虑迁移到敏捷的读者,到底是什么让你仍然保持现状?你已经在竞争中落后,已经成为落伍者。现在必须要迎头赶上。否则,敏捷的列车要么将你抛下,要么从你身上碾过。此外,我还为读者提供了一些可能会被采纳的建议,帮助读者节省迎头赶上所需的时间和精力。所以,开始干吧!

参考文献

  1. Geoffrey Moore, Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, Harper, 1999.
  2. William Riddle, “The magic number eighteen plus or minus three: a study of software technology maturation,” ACM SIGSOFT Software Engineering Notes, Vol. 9, Issue 2, April 1984, pp. 21-37.
  3. Donald Reifer, Software Change Management: Case Studies and Practical Advice, Microsoft Press, 2011.
  4. Mike Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley, 2009.
  5. B. Chrissis, M. Konrad and S. Shrum, CMMI®: Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003.
  6. 关于 DAD 的描述,参考如下网站

关于作者

Donald Reifer是软件工程和管理领域的领军人物之一,在工业、政府和学术界拥有超过 40 年的先进经验。他成立过数家软件公司,开展业务,曾经是工业领域的项目和规划经理,并且在学术界担任过客座副教授,作为政府高级行政服务官员领导过国家级软件项目。他曾经担任世界范围内的财富 500 强企业和政府机构的管理、度量和变更领域的顾问。目前,作为 Reifer 顾问有限责任公司的董事长,Donald Reifer 在实际操作层面帮助客户实施敏捷方法。Reifer 拥有超过 200 篇出版物,其中包括 10 本图书。他所拥有的众多荣誉包括 AIAA 软件工程奖,美国国防部公共服务奖章和名人录成员。他持有新泽西理工学院的电子工程学士学位,南加州大学(USC)的运筹学硕士学位以及加州大学洛杉矶分校(UCLA)的商业管理(与 MBA 等效)证书。

查看英文原文: Agile Introduction: Are You a Laggard?

2016 年 1 月 24 日 18:251583
用户头像

发布了 75 篇内容, 共 58.6 次阅读, 收获喜欢 5 次。

关注

评论

发布
暂无评论
发现更多内容

公有云成本节省神器!京东云共享带宽包正式上线

京东科技开发者

公有云 带宽

装双系统?不需要!教你在iMac上流畅使用Windows

懒得勤快

Mac 虚拟机 苹果 crossover

华为帐号服务学习笔记(三):10分钟完成Authorization Code模式客户端Demo开发

Coding狙击

android HMS

线上服务 CPU 100% ?一键定位 so easy!

Java小咖秀

性能 cpu 服务器 负载 紧急问题

浪潮签约“数字基建”合作伙伴共促工业互联网创新发展

浪潮云

工业互联网

商圈户外广告:推动商圈年轻化,打造城市地标

󠀛Ferry

四月日更

Spark原理与实战之部署模式与运行机制

小舰

spark Spark调优 4月日更

一文带你剖析LiteOS互斥锁Mutex源代码

华为云开发者社区

mutex LiteOS 互斥锁 互斥锁结构体

派出所重点人员管控系统开发,建设智慧警务

13828808769

智慧组工

Linux rmdir 命令

一个大红包

linux命令 4月日更

更简的并发代码,更强的并发控制

Kevin Wan

go 并发 go-zero

SumSwap在市场上的强大突破是否会成为DEX领域最大的黑马?

币圈资讯

「 最佳内容评选 」—— InfoQ 写作平台【 1 周年盛典 】

InfoQ写作平台官方

1 周年盛典

云小课 | 不了解EIP带宽计费规则?看这里!

华为云开发者社区

带宽 弹性公网IP 带宽变更 计费模式

区块链电子合同技术方案,区块链电子合同存证

13828808769

区块链 区块链+

WebRTC基础知识详解

IT酷盖

签约计划

亿网嘉元是做什么的?

飞亚科技

AI数学基础之:确定图灵机和非确定图灵机

程序那些事

人工智能 AI 程序那些事 图灵机

从石器时代到田园牧歌:如何对 API 统一建模

李宇飞

API

「 主题征稿 」—— InfoQ 写作平台【 1 周年盛典 】

InfoQ写作平台官方

1 周年盛典

数据分析与数据增长核心逻辑杂谈

小飞象@木木自由

数据分析

创建索引,这些知识应该了解

Simon

MySQL 索引

Cloudreve 自建云盘实践,我说了没人能限得了我的容量和速度!

小傅哥

Java 小傅哥 Cloudreve 自建云盘

划重点丨详解Java流程控制语句知识点

华为云开发者社区

Java 流程控制语句

模块二作业

Geek_1cdcf6

架构实战营

MySQL多表查询详解

若尘

MySQL 查询

「免费开源」基于Vue和Quasar的前端SPA项目crudapi后台管理系统实战之业务数据增删改查(七)

crudapi

Vue API crud crudapi quasar

2D+1D | vivo官网Web 3D应用开发与实战

vivo互联网技术

WebGL web前端 3D数据可视化 Draco 3D

智慧公安情报综合研判平台开发,助推公安信息化发展

13828808769

智慧城市

Python变量作用域与LEGB规则

大奎

语法 Python Monad 作用域

Android中的图像格式

如浴春风

android 音视频 安卓 签约计划

2021 ThoughtWorks 技术雷达峰会

2021 ThoughtWorks 技术雷达峰会

敏捷简况:你是否已经落伍?-InfoQ