《2022中国企业敏捷实践白皮书》

2022
中国企业敏捷实践白皮书
STATE OF AGILE REPORT 2022
出品方：老布谈敏捷
联合出品：
CONTENTS
目录
01 序言附录 1 . 1 敏捷实践成熟度模型
02 白皮书目标及调研方法附录 1 . 2 模型评价标准
03 中国企业敏捷主流附录 2 . 1 编委会代表
04 关于调研附录 2 . 2 全国出品人
05 中国企业敏捷现状及分析参考内容及索引
06 中国企业敏捷实践八维度案例及分析关于
2022是剧烈动荡和变化的一年，全球企业都深受其影响，长达几个月的完美计划会经常被各
种意外干扰，例如：人员出差会遇到航班取消，组织会议会遇到场地失效，供应链管理会遇
01
到运输中断等等。在这样的背景下，让自己、团队和企业更加敏捷便成为了有效法则。所谓
日积跬步以越千里，如果团队能够按短周期持续迭代，受意外影响的概率就会大大降低，不
断取得切实进展。
《中国企业敏捷实践白皮书2022》同样不可避免被突发事件影响了一个多月，在执委会老师
序言和编委会的共同努力下，坚持一周一迭代终成此书，也让我们再次见证在这频繁变化的环境
下，中国企业是如何通过敏捷实践实现业务持续发展，最终引导团队取得成功。
FOREWORD
此次白皮书中引入了一些大兴善寺元素，同往年的大雁塔一样隶属于西安，是西安现存历史
最悠久的佛寺之一。大兴善寺作为“佛教八宗”之一“密宗”祖庭，是最后一个形成的全国性
大宗派，法系一直传承至今，在此借助大兴善寺祝愿敏捷不仅可以传至中国还能逐步演化，
更能传播到全球造福更多行业。
来源：中国企业敏捷实践白皮书编委会自主研究及绘制
01
© 2022 PingCode 和老布谈敏捷版权所有
目标
02
《中国企业敏捷实践白皮书2022》将数据化全景呈现中国企业敏捷现状，并从调研中挖掘出
10个年度优秀敏捷实践案例，洞察中国企业对敏捷的看法、敏捷研发中取得的收益，敏捷转
型中遇到的困难以及如何在敏捷成熟度模型上进行取舍，旨在帮助更多中国企业合理运用敏
捷实践并取得市场竞争优势。
调研方法
白皮书目标本次调查分为线上调研问卷收集及敏捷专家一对一访谈两部分，自2022年10月10日开始，截
至2023年02月23日，回收调研样本938份，有效样本644份，深度访谈78份。在有效渠道的
及调研方法协助下，调研触及最广泛的国内敏捷实践者，通过执委会20位行业敏捷专家的访谈与互动、
分析收集数据并结合专家的多年经验总结出白皮书内容。白皮书力争翔实客观地反映中国企
GOAlS & 业敏捷实践现状，为敏捷社区、敏捷教练和企业管理层提供真实可信的数据支撑。
METHODOLOGY
02
敏捷现状
最广泛使用的敏捷管理实践是每日站立晨会
03
Scrum和Lean（精益）仍为当前国内主流敏捷方法论
敏捷工程实践中的持续集成被多数国内企业所采用
敏捷迭代周期普遍为2周
Scrum of Scrums成为国内企业大规模敏捷框架首选
中国企业利益&挑战
国内企业选择敏捷的主要原因是加速软件交付
敏捷主流多数受访者者认为组织拒绝变化的阻力是当下大规模敏捷的主要障碍
发展趋势
MAINSTREAM
对比2021-2022调研数据，中国企业敏捷转型的主要障碍已从“缺乏敏捷实践经验”转变为
“组织拒绝变化的阻力”。说明敏捷虽然得到了从业者的广泛认可，但仍存在相当比例的中
国企业还在观望和犹豫
整体来看，中国企业在实施敏捷的过程中已呈现较强的规律性，也更重视团队生产效率的
提升，但仍需解决好传统组织文化与敏捷理念的冲突，并持续学习最佳敏捷实践，尽快摆
脱初级的状态
03
线上问卷调研
04
参与调研的受访者分布于全国43个城市，其中74%位于一线城市
受访者主要是专业技术人员以及IT业务负责人，兼顾外部顾问与内部成员，岗位涵盖了
产品经理、项目经理、敏捷教练、工程师及各层管理者等
受访者所在企业规模呈均匀分布，从10人的初创企业到5000人的大型集团，涵盖16个
主流行业
关于调研敏捷专家一对一访谈
本次调研得到受访者的大力配合，分享了敏捷知识和具有中国特色的敏捷实践案例，最
ABOUT RESEARCH 终形成白皮书敏捷实践八个维度分析和TOP10年度最佳敏捷实践。
再次感谢各位受访者对我们本次调研和访谈的支持和贡献!（名单请详见附录2.2）
04
受访者企业总部分布于全国各地，75%位于一线城市
644名受访者所在企业总部主要分布在中国一线城市或新一线城市，其中，北上广深四个城市占比75%。发达城市的企业更容易接纳先进的敏捷
方法，敏捷方法的应用实践也进一步促进企业的发展，大幅提升了企业的竞争力。
城市被调研人数比例
上海 281 44%
北京 103 16%
深圳 69 11%
北京 Beijing
杭州 25 4%
保定 baoding
广州 23 4%
南京 nanjing 保定 15 2%
苏州 suzhou 成都 13 2%
武汉 wuhan
武汉 11 2%
上海 shanghai
南京 11 2%
成都 chengdu 杭州 hangzhou
苏州 7 1%
广州 guangzhou
其它 86 13%
深圳 shenzhen
样本量：n=644 RegQ 01：您所在企业的总部在？（单选题）
南沙群岛
05
受访者主要由专业技术人员或IT业务负责人组成
受访者所在岗位占比TOP 3是开发团队成员、项目经理、产品经理/PO，由此可见企业敏捷落地对人员专业化的要求。其中，项目经理（20%）
相比Scrum Master（9%）有更高的占比，体现出大部分企业仍处在敏捷转型期。
40%
33%
30%
20%
20%
14%
11%
10% 9%
7%
3% 3%
0%
开发团队成员项目经理产品经理中层管理者 Scrum Master CXO 外部教练其他
Product Owner （总经理、总监等）（CEO/CTO/CIO等）敏捷顾问
样本量：n=644 Reg Q02：以下哪个岗位名称能够最恰当的描述您当前的岗位?（单选题）
06
敏捷实践已广泛覆盖多个行业以及不同规模企业和软件团队
受访者所在行业中，47%为IT/互联网，18%为金融/保险，6%汽车，4%企业服务，其它行业占据25%；受访者80%位于100人以上中大型企
业；企业的软件开发团队规模分布比较均匀，从10人以内小团队到1000人以上的大型团队不等。由此可见，敏捷思维模式的理念和实践已在
国内广泛应用，不再局限于单一行业或特定规模的组织。
2%
2%
2% 12%
2% 7% 20%
4%
2% 32%
7%
2%
2% 15%
7%
3%
3%
4% 14% 11% 14%
6%
47%
18% 11% 17%
16%
18%
IT/互联网金融/保险汽车企业服务先进制造 1~10 人 11~25 人 26~50 人 1~10 人 11~25 人 26~50 人
智能硬件通信芯片/半导体电商/零售人工智能 51~100 人 101~300 人 301~1000 人 51~100 人 101~300 人 301~1000 人
教育医药健康其他 1001~5000 人 5000+ 人 1000+ 人
样本量：n=644 Reg Q03：您所处的行业是？（单选题）样本量：n=644 Reg Q04：您所在企业规模是？（单选题）样本量：n=644 Reg Q05：您所在企业的软件开发团队规模是？（单选题）
07
Q6. 受访者所在企业敏捷团队的比例
Q7. 受访者所在企业采用的敏捷管理实践
05
5.1 敏捷⽅法论应⽤
Q8. 受访者所在企业采用的敏捷方法
Q9. 受访者所在企业敏捷实践年限
Q10.受访者所在企业采用的规模化敏捷框架
中国企业 5.2 敏捷实施

Q11.受访者所负责产品的迭代周期
Q12.受访者所在企业采用的敏捷工程实践
敏捷现状及分析 Q13.受访者所在企业使用的敏捷工具
ANALYSIS Q14.受访者所在企业采用敏捷的核心原因
5.3 收益与挑战 Q15.受访者认为敏捷项目成功的重要因素
Q16.受访者所在企业采用规模化敏捷面临的最大挑战
08
调查结果显示
5.1
通过2021-2022调研数据对比发现，受访者所在企业的敏捷团队占比从2021年的55%
提升至2022年的63%，说明越来越多的中国企业正在从传统研发模式转变为敏捷研发
模式，并不断扩大敏捷适用范围来促进企业整体敏捷转型
Scrum四大会议与发布计划，在众多敏捷实践中独占鳌头，说明大部分企业正通过这
些领先实践来规范团队迭代节奏，确保交付
敏捷方法论应用 2022年，Scrum和Kanban仍为最受欢迎的方法论，其中Lean（精益）成为新宠
2017-2021年，采用敏捷方法的中国企业数量正在逐年递增，越来越多的中国企业将
USE OF AGILE 敏捷从复选项逐步进化为必选项
METHODOLOGIES
09
63%中国企业中敏捷团队占⽐过半
对比2021年与2022年调研数据发现，在已经采用敏捷方法的中国企业中，有一半以上敏捷团队的企业占比从2021年的55%提升至2022年的
63%，只有敏捷试点团队的企业占比大幅降低，从2021年的21%下降至2022年的13%。由此可见，中国企业越来越多的团队采用敏捷方法，
并不断扩大敏捷适用范围来促进企业整体敏捷转型。
我们所有团队 22%
都在使用敏捷方法 24% 63% 受访者表示企业
中敏捷团队占⽐过半
我们大部分团队（50%以上） 41%
都使用敏捷方法 31%
我们小部分团队（50%以下） 25%
使用敏捷方法 24%
我们只有试点团队 13%
使用敏捷方法 21%
0% 13% 25% 38% 50%
2021（n=501） 2022（n=644） Reg Q06：您所在企业敏捷团队的比例最符合以下哪一项？（单选题）
10
过半数的企业在实施敏捷超过一年后，企业内部敏捷团队成为主流
随着企业敏捷实践年限的增加，企业会不断允许更大比例的团队采用敏捷方法。数据显示，过半数的企业在实施敏捷超过一年后，企业内部敏
捷团队的占比即能达到50%以上，相较于2021年，敏捷推广的速度变得更快、普及度更高。
试点敏捷团队敏捷团队未过半敏捷团队已过半全部为敏捷团队
70%
60% 59%
49%
50% 47%
43%
40% 36% 37%
33%
29% 40%
30% 38%
24% 23% 23%
31% 22%
19% 19% 19%
20% 16% 15% 17%
15%
14%
10% 9%
10% 6%
4% 5%
0%
不到一年 1~2年 2~3年 3~4年 4~5年 5~6年 6年以上
样本量：n=644 Reg Q06：您所在企业敏捷团队的比例最符合以下哪一项？（单选题） Reg Q09：您所在企业的敏捷实践了多少年？（单选题）
11
50-100人规模的软件团队更容易推行全员敏捷
对于具备不同软件团队规模的企业，能够更好地推行全员敏捷的是拥有50到100人软件团队的企业，占比32%，其次是拥有1到10人小规模软件
团队的企业，占比28%。但整体来看，中国能够推行全员敏捷的企业占比仍然较低。
40%
32%
30% 28%
20% 21% 20%

20% 17% 16%
10%
0%
1~10人（n=75） 11~25人（n=95） 26~50人（n=90） 51~100人（n=111） 101~300人（n=74） 301~1000人（n=73） 1000+人（n=129）
Reg Q05：您所在企业的软件开发团队规模是？（单选题） Reg Q06：您所在企业敏捷团队的比例最符合以下哪一项？（单选题）
12
Scrum四大会议与发布计划，在众多敏捷实践中独占鳌头
统计结果显示，“Scrum四大会议”和“发布计划”已成为敏捷管理实践中最受欢迎的TOP5实践。目前已有绝大部分企业正通过这5项实践来逐步
规范团队的敏捷交付节奏，但仍需一些时日企业才会采纳更高阶的敏捷实践，尤其是产品需求相关和提升质量相关实践方法的应用还有待加强。
每日站立晨会 59%
迭代计划会 57%
团队回顾会 51%
发布计划 35%
迭代展示会 33%
用户故事 26%
集体办公 21%
知识共享 19%
任务墙 17%
工时集体估算 14%
用户故事地图 12%
小于15人的混合角色全功能 10%
提倡质量内建 6%
测试左移及全程测试介入 5%
热心用户参与 3%
0% 10% 20% 30% 40% 50% 60% 60%
样本量：n=644 Reg Q07：您认为所在企业采用了如下敏捷管理实践?（复选题）
13
Scrum与Kanban仍为主流方法论，Lean（精益）成为新宠
82%的中国企业都在使用Scrum及其混合方法，64%的中国企业更倾向使用精益相关方法，其中“精益Kanban”占比37%，“Lean（精益）”
占比27%。由此可见，围绕需求和任务信号卡，运用Kanban开展可视化管理，从而减少浪费、提升效能，已经被中国企业所广泛接受。
Scrum 55%
82% 受访者所在企业使⽤
Scrum相关敏捷⽅法
混合Scrum和其他方法 27%
精益Kanban 37%
64% 受访者所在企业使⽤
精益相关敏捷⽅法
Lean（精益） 23%
Extreme Programming(极限编程) 13%
0% 10% 20% 30% 40% 50% 60%
样本量：n=644 Reg Q08：您认为所在企业使用哪个敏捷方法?（复选题）
14
2017-2021采用敏捷方法的中国企业正在逐年递增
调研发现，所采用敏捷方法的中国企业数量从2017年开始正在逐年递增，中国企业采用敏捷实践“1～2年”的占比高达23%。由此可见，越来
越多的中国企业采用和接纳敏捷，随着“数字中国”蓝图的推进，中国企业管理者正在面临着一场管理变革，而敏捷管理也正在从复选项逐步
进化为必选项。
30%
23%
20% 19% 18%
13%
12%
10%
9%
5%
0%
6年以上 5~6年 4~5年 3~4年 2~3年 1~2年不到1年
样本量：n=644 Reg Q09：您所在企业的敏捷实践了多少年？（单选题）
15
调查结果显示
5.2
81%中国企业选择使用规模化敏捷框架，较去年增长6个百分点
当前中国企业主流迭代周期在3周以内，从行业对比来看，互联网仍是迭代最快的行业
受访者所在企业首选的敏捷工程实践是持续集成，当然还有一些性价比较高的工程实践如接口自
动化测试、接口监控等，有待企业进一步应用
敏捷实施随着国产敏捷项目管理工具的迅速发展，市场份额逐年增加，中国企业敏捷项目管理工具采用率
已达到96%
IMPLEMENTATION
OF AGILE
16
2021-2022中国企业最受欢迎的规模化敏捷框架是Scrum of Scrums
2022年“Scrum of Scrums”和“SAFe”规模化敏捷框架仍为主流，并且受访者所在企业“没有应用大规模敏捷实践”的比例从2021年的25%下降
至19%，其他规模化敏捷框架如Enterprise Scrum（企业级Scrum）、Spotify Model（Spotify模式）在使用上均有提升。此外，对比企业规模和
规模化敏捷框架结果显示，企业规模越大，使用Scrum of Scrums来落地规模化敏捷的越多，而SAFe框架在100人以下规模企业中更受欢迎。
采用Scurm of Scrums随企业规模比例图
29%
Scrum of Scrums 31% 45%
36%
19%
36% 30%
没有应用规模化敏捷框架 24% 25% 25%
25%
27% 25%
19%
14% 18%
SAFe（规模化敏捷框架） 14%
9%
9% 0%
Exterprise Scrum（企业级Scrum） 5%
26
10 =93
10 =10
50 =20
1~
51
30 =14
~5
1~ )
01 6
00
~1
1~ 4
25
(n
(n
(n ⼈
（
(n
(n
~5 )
+⼈ 7)
0⼈）
30
⼈
00 )
10 )
=3
n=
n=
8%
LeSS（大规模Scrum）
0⼈
00
⼈
00
48
42
37
5%
0
⼈
）
7%
Spotify Model（Spotify模式） 2%
采用SAFe随企业规模比例图
7%
Disciplined Agile（规范敏捷） 3%
35%
7%
Lean Management（精益管理） 5% 27%
28%
21% 19%
14% 15%
0% 10% 20% 30% 40% 14% 12% 13%
8%
7%
2021（n=501） 2022（n=644） 0%
26
10 =93
10 =10
50 =20
1~ n=
51 =34
30 =14
~5
1~ )
01 6
00
~1 8
1~ 4
25 37
(n
(n
(n ⼈
（
(n
(n
Reg Q010：您所在企业采用如下哪个框架做规模化敏捷？（单选题） Reg Q04：您所在企业规模是？（单选题）
~5 )
+⼈ 7)
0⼈ 2）
30
⼈）
00 )
10 )
n=
0⼈
00
⼈
00
4
0
⼈
17
51%中国企业迭代周期在3周以内，互联⽹仍是迭代周期最短的⾏业
51%的受访者所在企业的迭代周期在3周以内，其中采用“2周”迭代的企业占比30%。得益于规模化敏捷框架的运用，49% 的“5000+人”大规
模企业迭代周期已控制在3周以内，实现了“大象起舞”。从行业对比来看，迭代周期在1-2周的互联网企业要高于其他企业,可见IT/互联网行业
更倾向短周期迭代。但仍有13%的受访者所在企业迭代周期超过“4周”，21%的企业还没有固定的迭代周期，说明敏捷还处于早期，暂未体会
到短周期迭代的必要性和价值所在。 5000+人企业
1周 9% 49%
51% 受访者所在企业的迭
2周 30%
代周期在3周以内
3周 12%
4周 14%
4周以上 13% 51%
根据产品不同而调整 21%
0% 5% 10% 15% 20% 25% 30% 35% 1~3周 4周以上或者不固定
样本量：n=644 样本量：n=207
敏捷实践周期行业对比
40% 33% IT/互联网企业（n=297）非互联网企业（n=343）

28%
30% 24%
18%
20%
12% 12% 14% 14% 14% Reg Q11：您负责的产品迭代周期是多长时间？（单选题）
11% 11%
10%
8%
Reg Q03：您所处的行业是？（单选题）
0%
1周 2周 3周 4周 4周以上根据产品不同
而调整
18
78% 中国企业⾸选⼯程实践为持续集成
受访者所在企业敏捷⼯程实践TOP 3为 “持续集成”、“单元测试” 、“持续部署”。“接口自动化测试”及“接口监控”作为性价比较高的工程
实践有待企业进一步应用，而采用 “测试驱动开发”和“结对编程”的企业占比最低，说明这两项敏捷⼯程实践在中国仍有很长的路要走。后续
章节选取的年度最佳敏捷实践案例中，有关于结对设计的充分说明，将很好体现这类工程实践的巨大价值。
Continuous Integration（持续集成） 78%

Unit Test（单元测试） 69%
Continuous Deploy（持续部署） 67%
Code Specification Scanning（代码规范扫描） 63%
Interface Auto Testing（接口自动化测试） 62%
Grayscale Release（灰度发布） 50%
Interfacce Monitoring（接口监控） 40%
Code Sharing（共享代码） 33%
Refactoring（重构） 29%
ABTest(AB测试) 29%
UI Auto Testing（UI自动化测试） 27%
Testing-Driven Development （测试驱动开发） 24%
Pair Programming （结对编程） 15%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
样本量：n=78 Reg Q12：您认为所在企业采用了如下敏捷工程实践?（复选题）
19
敏捷项目管理工具成为中国企业敏捷实践的必选项
优秀的敏捷项目管理工具将助力企业快速响应客户需求，更好更快地发布产品。随着国产工具的迅速发展，敏捷项目管理工具成为中国企业敏
捷实践的必选项，采用率达到96%。目前，Jira仍是国内企业敏捷工具首选，占比达41%，传统的Excel仍被广泛使用，占比从2021年的30%下
降为2022年的20%，主要原因是随着国产研发管理工具专业能力的提升、国产化替代趋势、本土化服务优势，国产工具应用越来越广泛，如：
PingCode、飞书（Lark）、禅道和TAPD等敏捷工具替代了不少之前的传统做法。
Jira 41%
Excel 20%
PingCode 18%
飞书（Lark） 16%
禅道 14%
TAPD 14%
Teambition 13%
自研 5%
Leangoo 5%
其他 11%
0% 10% 20% 30% 40% 50%
样本量：n=644 Reg Q13：您所在企业在使用如下哪个敏捷工具?（复选题）
20
调查结果显示
5.3
超4成企业采用敏捷的核心驱动力仍是提质增效，其中，“提升IT与业务匹配度”首次进
入企业选择的Top10，说明业研一体化开始受到中国企业的重点关注
用户满意度和交付的商业价值成为判断敏捷项目成功的重要因素，当然企业内不同管理
层级和角色对敏捷的收益的关注点也不尽相同
收益与挑战
近半数的受访者认为企业规模化敏捷的最大挑战来源于组织本身，引入敏捷专业经验赋
能团队对企业敏捷转型至关重要
BENEFITS&
CHALLENGES
21
超4成企业采⽤敏捷的核⼼驱动⼒仍是提质增效
2022年调查显示，加快软件交付、提升团队产能及应对变更仍是企业采用敏捷的3大主要原因，仅18%的受访者从企业战略层面思考如何通过
敏捷方法帮助组织在市场上取得成功，仍然处于较低水平；14%的受访者将“提升IT与业务匹配度”列入企业采用敏捷的核心原因，相较2021
年调查结果，这是最大的变化点，说明有不少企业开始关注如何将IT资源精准投放到高业务价值上，这可能与企业在疫情时期着重追求IT投产价
值最大化有关。
加速软件交付 63%
提升团队的生产力 51%
增强需求变更的管理能力 50%
提升软件质量 35%
加快应对客户反馈 33%
减少项目风险 28%
改善研发进度的透明度 26%
及时地应对市场变化 18%
提升IT与业务匹配度 14%
降低产品的成本 14%
增强软件可维护性 12%
提高团队士气 11%
加强分布式团队管理 9%
0% 10% 20% 30% 40% 50% 60% 70%
样本量：n=644 Reg Q14：您认为您所在企业采用敏捷的核心原因是?（复选题）
22
CXO及外部教练/敏捷顾问更能把握敏捷的实质
敏捷的实质是及时应对市场变化和加快应对客户反馈，在统计不同角色对采用敏捷的核心诉求时发现，无论何种角色，采用敏捷的核心诉求都
是为了加速软件交付以及提升团队生产力；增强需求变更的管理能力同样是企业内部的关注重点，相比之下，外部敏捷顾问则会更加关注如何
通过敏捷“加快应对客户反馈”；企业CXO还希望通过敏捷来“及时地应对市场变化”以及“加强分布式团队管理”。
产品经理/Product 中层管理者 CXO（CEO/

Scrum Master Owner 开发团队成员项目经理（总经理、总监等） CTO/CIO等）外部教练/敏捷顾问
（n=55）（n=93）（n=207）（n=127）（n=73）（n=20）（n=19）
加速软件交付 71% 61% 62% 69% 55% 50% 42%
提升团队的生产力 55% 51% 53% 43% 52% 65% 53%
增强需求变更的管理能力 51% 49% 53% 47% 53% 65% 26%
提升软件质量 49% 34% 34% 31% 32% 45% 32%
加快应对客户反馈 44% 26% 27% 36% 38% 45% 42%
减少项目风险 29% 17% 28% 35% 29% 30% 26%
改善研发进度的透明度 33% 24% 19% 29% 37% 45% 16%
及时地应对市场变化 29% 18% 11% 21% 19% 35% 32%
提升IT与业务匹配度 15% 13% 15% 19% 25% 10% 26%
降低产品的成本 11% 14% 13% 19% 25% 25% 5%

角色对影响因素角色对影响因素
增强软件可维护性 13% 17% 14% 11% 11% 20% 16% 的关注程度较低的关注程度较高
提高团队士气 16% 6% 7% 13% 15% 20% 16%
加强分布式团队管理 7% 6% 9% 12% 18% 35% 11%
样本量：n=644 Reg Q02：以下哪个岗位名称能够最恰当的描述您当前的岗位？（单选题） Reg Q14：您认为您所在企业采用敏捷的核心原因是？（复选题）
23
用户满意度和交付的商业价值是评价敏捷项目成功的最重要因素
78%的受访者认为应该用客户/用户满意度来评价一个敏捷项目是否成功，72%的受访者认为交付的商业价值也非常重要，当然还有多数受访
者认为研发速率和需求响应时长的改进，同样可以视为敏捷项目的成功。另有32%的受访者认为“成员开心工作”是敏捷项目成功的关键判断
因素，说明中国企业也逐渐开始关心团队中成员的身心健康。
客户/用户的满意程度 78%
交付的商业价值 72%
研发速率 47%
需求响应时长 46%
实际花费的成本 36%
按时发布 36%
成员开心工作 32%
平均每个迭代的工作量 31%
每个迭代的需求变更占比 28%
缺陷的数量和等级占比 27%
工时估算准确率 18%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
样本量：n=78 Reg Q15：您认为评价一个敏捷项目成功的重要因素？（复选题）
24
组织及文化冲突是中国企业敏捷转型的最大障碍
组织与文化是敏捷生根发芽和成长的土壤，但调查显示，50%的受访者认为企业规模化敏捷的最大挑战来源于组织本身，只有解决传统组织文化
与敏捷理念的冲突，企业才能更好地适应快速变化的市场环境。其次，缺少敏捷实践经验、专业人才或咨询培训，同样是企业规模化敏捷实施的
主要挑战，由此可见，引入敏捷专业经验赋能团队对企业敏捷转型来说至关重要。
组织拒绝变化的阻力 25.5% 50%受访者认为企业规模化

没有敏捷实践经验 25.3%
敏捷的挑战来源于组织本身
组织文化与敏捷的冲突 24.5%
缺乏合适的 Product Owner 或 Scrum Master 21.7%
缺少中层管理者的支持 20.7%
习惯了基于 PMP 的传统研发方法 20.0%
缺乏培训或咨询 19.6%
部门墙的阻碍 16.6%
缺少合适的工具 16.6%
不足的团队协作和分享 15.4%
缺乏CXO的支持 13.5%
制定新的绩效激励制度难度大 11.0%
与使用传统开发方法的团队合作 8.2%
难以雇佣或留住敏捷开发人员 5.1%
不愿意承认错误或缺少从失败中学习的能力 5.0%
0.0% 10.0% 20.0% 30.0%
样本量：n=644 RegQ16：您所在企业采用规模化敏捷最大的挑战是？（复选题）
25
不同岗位角色对规模化敏捷面临的挑战认知不同
对比2021年规模化敏捷的各种挑战及不同角色关注度排序发现，“组织文化与敏捷的冲突”以及“缺乏敏捷实践经验”仍是各角色公认的挑战；
SM及外部敏捷顾问认为挑战很大程度上来自“部门墙的阻碍”；CXO认为“缺少合适的工具”以及“缺少培训或咨询”也是规模化敏捷实施的主
要问题；对于产品经理PO以及项目经理来说，更担心由于“习惯了基于PMP的传统研发方法”而影响规模化敏捷的落地。
产品经理/Product 中层管理者 CXO（CEO/

Scrum Master Owner 开发团队成员项目经理（总经理、总监等） CTO/CIO等）外部教练/敏捷顾问
（n=55）（n=93）（n=207）（n=127）（n=73）（n=20）（n=19）
组织拒绝变化的阻力 27% 23% 24% 28% 29% 35% 21%
没有敏捷实践经验 18% 25% 24% 30% 26% 35% 11%
组织文化与敏捷的冲突 31% 24% 20% 27% 33% 15% 26%
缺乏合适的Product Owner或Scrum Master 20% 22% 19% 27% 19% 20% 26%
缺少管理层的支持 16% 25% 20% 24% 18% 10% 26%
习惯了基于PMP的传统研发方法 16% 33% 17% 28% 8% 10% 21%
缺乏培训或咨询 11% 22% 20% 23% 11% 30% 11%
缺少合适的工具 9% 14% 19% 20% 16% 30% 11%
部门墙的阻碍 29% 11% 10% 21% 21% 10% 32%
不足的团队协作和分享 7% 19% 15% 15% 15% 25% 11%
缺乏CXO的支持 18% 11% 13% 13% 16% 10% 21%
制定新的绩效激励制度难度大 9% 10% 8% 15% 11% 20% 21%

角色对影响因素角色对影响因素
与使用传统开发方法的团队合作 11% 9% 7% 9% 11% 0% 5% 的关注程度较低的关注程度较高
难以雇佣或留住敏捷开发人员 5% 5% 3% 6% 8% 10% 11%
不愿意承认错误或却缺少从失败中学习的能力 4% 9% 2% 6% 10% 10% 0%
样本量：n=644 Reg Q02：以下哪个岗位名称能够最恰当的描述您当前的岗位？（单选题） Reg Q16：您所在企业采用规模化敏捷最大的挑战是？（复选题）
26
关于TOP10
06
中国企业在推行敏捷过程中，根据行业特性、企业文化和团队经验等逐步演化出具有中
国特色的敏捷实践，经过20位敏捷专家与70位敏捷实践者的一对一深度访谈，选出本次
“TOP10年度最佳中国企业敏捷实践”。
核心目标
中国企业本章整体呈现中国企业对敏捷的期望，通过价值、领导力、团队、实践、工具、需求、质
量、学习与改进八个维度的实践现状及分析，帮助国内更多企业取得理想实践效果。
敏捷实践
八维度分析
CASE STUDY
27
价值：认准目标客户才能确保敏捷实践的结果是有价值的。
6.1
“价值”作为敏捷的核心，包括用户价值、商业价值和社会价值。在敏捷实践的过程中，
最重要的是明确各项价值所在并坚定执行，一旦出现了偏差，便是南辕北辙，而目标的
实现需要有正确的方向、客观的数据、明确的标准和果断的决策。
调研发现，仅有14%的企业部分实现价值管理闭环，8%的企业能够做到企业战略和业务
价值目标与价值管理紧密结合。这一现象说明了大部分中国企业还不能在敏捷实践中实现需
求价值的体系化及多维度价值度量，因此推广优秀的敏捷实践至关重要。
VALUE
本节所选实践，帮助国内企业了解如何通过ABTest中台化实现产品的业务目标与需求价
值的量化判断，从而缩短研发周期并节约成本，这种基于多维度度量数据做业务决策的
实践非常值得学习。那么如何“正确地做正确的事”，王艳茹专家基于调研结果与具体实
践，向大家说明了价值导向在敏捷实践中的重要意义。
28
69%中国企业尝试在不同层级实现产品价值管理
在企业的价值管理方面，有35%的企业能够按照价值进行优先级排期，仅有14%的企业能够部分实现价值闭环管理，13%的企业能够对价值进
行多维度量化，能够做到企业战略和业务目标与价值管理紧密结合的企业仅8%。目前仍有31%的团队没有严格做到高价值需求优先交付，这说
明了大部分中国企业在需求价值的体系化、多维度度量等方面还有巨大的提升空间，需持续学习优秀的敏捷实践。
团队会对需求价值进行简单评估，没有严格做到高价值需求有限交付 31%
团队会对需求价值进行评估对比，基本按价值排期和交付 35%
某些部门有完整的价值闭关管理过程 14% 69% 受访者所在企业尝试
在不同层级实现产品价值
团队有多维度且量化的价值评估规则，体系化的价值交付 13%
管理
企业战略和业务目标能够与价值管理保持紧密的联动 8%
0% 10% 20% 30% 40%
样本量：n=78 Reg Q17：您认为所在企业的价值管理方面的现状最符合以下哪一项？（单选题）
29
问题
由于产品特性的价值缺乏有效评判标准，导致经常出现无依据地回滚特性，从上线到全量推广节奏不可控且周期
过长，团队应对需求变更的态度也变得消极。
问题成因
IT/互联网
1. 产品设计的合理性缺乏有效的验证手段；
2. 多特性同时上线，互相干扰，无法判断特性的价值优劣；
价值维度实践案例 3. 以往通过渠道对比、时间对比等方式，都不能有效地进行价值评判，因此推广节奏不可控。
—— ABTest中台化
敏捷实践
1. 搭建系统：首先是搭建平台，以SDK的形式，对多特性同时进行ABtest 的开关控制，同时建设了基于用户ID
的百分控制的两级灰度发布；
2. 数据建模：抽取部分产品的特性数据，建立特性置信度区间的算法模型；
余知权（某互联网公司高管）

3. 评估标准：建立业务的不同阶段、不同时间和不同规模的评估标准，从而选择有价值的产品特性；
4. 产品验证：在一个产品上进行试用，取得一定的效果之后在其他产品上进行推广；
5. 制度先行：标杆示范的作用发挥出来之后，得到足够的信任度，通过管理方式下发制度，进行推广；
6. 统一接口：平台提供统一接入接口规范，要求全公司产品接入，形成中台化管理；
7. 全面推广：ABTest平台与灰度发布相结合，成为了公司的一个重要基础设施。
实践结果
1. 灰度放量周期缩短：产品特性从上线到全量推广花费的时间比不用平台缩短了50%以上；
2. 价值判断从主观到客观：回滚有了明确的数据依据，从此不再靠猜测，不用耗费大量时间讨论；
3. 价值判断有标准：产品的用户价值有明确判断标准，在应对变化时，团队也变得更加积极主动。
总结
AB test 中台化实践很好地诠释了敏捷原则第一条、第二条和第七条：
“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。”
“欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。”
来源：中国企业敏捷实践白皮书编委会自主研究及绘制 “可工作的软件是进度的首要度量标准。”
30
正确地做正确的事
专家观点 “在超级竞争的环境里，正确地做事很容易，始终如一地做正确地事情很困难。组织不怕效率低，组织最怕高效率地做
错误的事情。” ——彼得.德鲁克
王艳茹
2021年的白皮书中，陈忠专家在客户价值章节中给大家推荐了高价值的“用户画像”的敏捷实践。我们一旦明确了用户
画像，就会知道用户需要的是什么，即“正确的事”，那么如何正确地实现用户需求？如何快速响应需求变化？如何准
确及时地判断以提升效率？这是我们需要进一步思考的问题。
腾讯科技安全项目总监、敏捷教练
本节所选实践通过搭建ABtest与灰度发布结合平台，建立了产品ABtest各类模型以及产品管理评估规范，并通过产品
验证、推动制度先行、统一接口等一系列具体实践举措，在公司管理层和各产品团队达成共识，因此得以全面推广，
目前该平台已经成为公司的一个重要基础设施。
凭借ABtest中台这一价值交付利器，帮助企业的业务团队正确地做正确的事：
首先，通过AB Test识别有价值的产品需求，并通过迭代持续打磨让用户满意的产品；
其次，AB Test帮助团队在明确价值判断标准下，有效应对需求变化；
最后，AB Test给出团队价值反馈后，团队能够针对问题不断追求技术卓越和良好设计，敏捷能力也得到进一步加强。
31
领导力：激励敏捷人才并营造敏捷文化确保敏捷转型成功。
6.2
领导力是实现企业敏捷变革的基石，引领落地敏捷实践，并对其结果负责。在VUCA时
代，是否具备敏捷领导力往往是企业成败的关键。数字化转型或敏捷变革需要改变工作
方式，所以敏捷领导者必须理解敏捷的价值观、原则和实践，并躬身入局、影响和传授
给他人。领导者只有具备系统化思考的能力，才能全面进行组织、业务、技术的变革和
创新，培育和激励敏捷人才，营造真正的敏捷文化。
领导力通过对企业领导力现状的调研，我们很高兴地发现91%的企业领导者在不同程度上都践
行了敏捷领导力，而不具备敏捷领导力的企业仅占9%。在本节实践案例中，某财险公司
信息技术部高级工程师分享了组织级数字化转型中的优秀敏捷领导力实践，不仅解决了
LEADERSHIP 产品上市周期长、响应市场变化慢的难题，还打破了部门墙、提升了客户满意度，该案
例将为同类企业在组织层面进行有效敏捷实践打开思路。同时，张志华专家也基于调研
结果与具体实践，提出了“去中心化决策”的观点，帮助组织领导者把握如何授权赋能一
线团队。
32
91%中国企业在不同程度上践⾏了敏捷领导⼒
调研发现，绝大多数受访企业的领导者都具备敏捷思维，其中有27%的中国企业领导者会亲自做决定，有意识培训团队，通过不同渠道听取团
队的意见；29%的团队领导积极参与敏捷实践，系统化培养员工，能够听取员工意见并部分授权。目前敏捷领导力多体现在团队级，在部门级
和企业级仍有待加强，企业领导者能够充分利用敏捷加强应对市场变化才是最关键的。
全公司领导敏捷联动，均能信任团队且
10%
授权，业务能够应对及时市场变化
某些部门内领导带头践行敏捷价值观，积极发展
24%
团队且部分授权团队，主动适应市场变化 91% 中国企业在不同程度
团队领导积极参与敏捷实践，系统化培养上践⾏了敏捷领导⼒
29%
员工，能够听取员工意见并部分授权
团队领导亲自做决定，有意识培训团队，
27%
成员可以通过渠道提意见
团队领导置身事外，没有培养
9%
团队，管控团队为主
0% 10% 20% 30% 40%
样本量：n=78 Reg Q18：您所在企业的领导力现状更符合以下哪一项？（单选题）
33
问题
公司面临着来自内外部的双重挑战：
1. 外部挑战：现有数字化产品上市周期长，定制化程度低，不能快速响应市场变化和满足客户需求；
2. 内部挑战：公司有16个涵盖不同业务和技术的职能部门，跨部门协作效率低、成果少，彼此的信任度和满
意度堪忧。
金融/保险
问题成因
领导力维度实践案例
1. 该公司采用传统的职能型组织结构，各个部门利益和目标不同，存在固有的“部门墙”；
2. 业务部门和技术部门开发了客户不需要的产品或特性，并且相互指责。
—— 走动式激励敏捷实践
1. 引发高层管理者高度重视，从上至下推动数字化变革：
a. 2020年6月，公司对信息技术部进行组织架构调整，打破技术部门不同团队之间的“筒仓”，由职能型
转变为跨职能的全栈团队，实现技术敏捷；
侯先生（某财险公司高级工程师） b. 2021年5月至2022年2月期间，成立数字化改革领导小组，并下设数字化改革办公室，从整体上对业务
和业务部门进行调整和优化，开启业务敏捷的旅程。
2. 部门领导以身作则，践行敏捷价值观，设定业务和技术部门共享目标，通过走动式管理（Gamba Walk），
多去员工工作现场，进行充分授权，并通过季度绩效考核来激励员工, 培育敏捷文化。
实践结果
1. 实现高效高质的产品发布。在产品未变化的情况下，信息技术部在2020年总计发布产品300次， 2021年提
升至800次，2022年达到1000次，并完成高质量发布。
2. 客户满意度大幅度提升。该财险公司总部设有16个部门和16个省级分公司及计划单列中心支公司，每年各
部门会从服务能力、服务态度和服务效率三个维度互评满意度。2020年信息技术部门的总体满意度排名第
8，而在2022年跃升至第1名。
总结
该敏捷领导力实践体现了敏捷十二条原则中的第三条、第四条、第五条：
“经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期”
“在项目过程中，业务人员、开发人员必须每天在一起工作”
来源：中国企业敏捷实践白皮书编委会自主研究及绘制 “以受到激励的个体为核心构造项目，为他们提供所需的环境和支持，信任他们可以把工作做好”
34
赋能团队成员，提升决策效率和质量
专家观点如果说技术敏捷和业务敏捷构建了组织级敏捷的大厦，那么敏捷领导力就是这座大厦的地基。敏捷领导力本质上是一
种适应型领导力，需要与时俱进、灵活调整领导风格，主动适应不同的市场变化。
张志华本次调研中，绝大部分企业都践行了敏捷领导力，更可喜的是，有63%的企业领导者有意识地培养敏捷人才，并且在
不同程度上授权和赋能一线员工和团队。领导是一种责任，而不是职位或者特权。在领导力情境下，我们希望最大程
曼合普管理咨询公司咨询经理度去激发知识性工作者的内在动机，授权赋能，改变以往过度僵化、缓慢的集中化决策方式。本案例中侯先生推荐的
两种领导力实践：公司领导层从上至下推动数字化变革以及以身作则践行敏捷价值观，均有非常好的借鉴意义。
同时，也借此机会分享一个适用度很广的敏捷领导力实践：去中心化决策。
“去中心化决策”这种方式适用于频繁发生、时间紧迫、经济影响小的决策场景，通过最大程度的赋能给团队成员，
提升决策效率和质量，减少因为等待造成的不必要的浪费。而集中化决策方式，更适用于发生次数少、持续时间长，
经济规模影响大的场景。因此，企业在考虑选择哪种决策方式时，建议考虑三方面因素，即决策频率高低、持续时间
长短和经济影响大小，并通过量化的度量结果来判断和选择最佳决策方式，而能否采取合适的决策方式也是敏捷领导
优劣的一个重要体现。
35
团队：结合客户行业企业自身优势的自组织管理才是有效的。
6.3
团队需紧密围绕业务场景和任务目标，将业务价值链的核心功能提取出来，并据此构建
工作模式，不断促进团队之间的协作。通过OKR或关键业绩指标（KPI）对日常交付的绩
效进行监测，让团队成员积极并愿意承担责任，从而保证产品创新能力强且版本质量
高；并通过多个敏捷管理实践来促使每一个敏捷团队逐步形成自驱，例如：可视化管
理、数据驱动管理、北极星指标等等。
团队调研发现，绝大部分企业都能感受到敏捷带来的好处，并愿意主动运用敏捷实践来解决
团队问题。也有不少企业从业务价值链出发，构建生态型组织，建立共同的目标，在本
节的实践案例中，通过打造敏捷“绿洲”来缩短产品交付时间、提升产品质量的做法非常
Team 值得借鉴。基于调研结果和敏捷实践案例，Lyrin专家全面阐述了如何将敏捷部落与OKR
或KPI有机结合。
36
71%中国企业的团队已经从敏捷实践中获益
从统计结果来看，71%的受访者所在企业的团队能够体会到敏捷带来的好处，如主动解决团队问题、主动响应市场变化、彼此信任度增加等等，
但仍有近三成的中国企业以职能性或矩阵型团队为主。总体来看，中国敏捷团队也在根据业务价值或市场场景不断变化，去实现团队高效运作和
高质量交付。
职能型或矩阵型团队，开始尝试实践敏捷流程 29%
团队成员感受到敏捷的好处，透明化
28%
工作内容，主动运用敏捷实践解决团队问题
企业内实践大规模敏捷方法，主动响应
17% 71% 受访者所在企业的团
市场变化并不断提升效率和质量
队已经从敏捷实践中获益
团队成员彼此信任，对于敏捷价值观
15%
有共识，不断反思并主动调整敏捷实践
某些部门内所有团队对于敏捷价值观具有
10%
高度共识，互相补位且不断提升绩效
0% 10% 20% 30% 40%
样本量：n=78 Reg Q19：您认为所在企业的敏捷团队现状更符合以下哪一项？（单选题）
37
问题
1. 公司的智能驾驶项目涉及软硬件部门的跨团队协作，经常出现沟通不畅或效率低的问题；
2. 由于硬件的质量问题，导致交付时间长或车厂倒闭。
问题成因
IT/互联网
1. 敏捷团队未包含硬件团队，软硬件团队分散在不同的部门，在自治性、流程、沟通、需求受理和优先级方面
存在差异；
团队维度实践案例 2. 9人敏捷小分队不能适应目前多团队或百人规模的团队。
敏捷实践
——打造敏捷“绿洲” 1. 根据服务环节调整组织架构形成部落，设定部落长，并将硬件团队纳入敏捷部落以降低沟通成本；
2. 30人组成一个敏捷小组，成员组成包括：CTO，ScrumMaster，Product Owner，架构，算法，开发，测
试等；
3. 部落推行过程中，领导给予大力支持，在组织层级形成统一意见，采取如下措施：
魏冬（某互联网公司 CTO）
a.规范协助模式、协作职权，协作标准机制，如会在协作标准中约定好需求受理的优先级、交付时间、质量
要求和依赖关系等等；在协作职权中，明确由部落长负责部落内的整体资源分配和整合，部落重要事项和关
键决策，保障需求交付速度和交付质量；同时每个团队都有一个PO来负责团队的需求、进度、问题等；
b.通过管理思想工具化,做到精准决策、传达和有序执行，同时利用工具提高研发效能和产品质量，已使用的
有Jira、Confluence、Git、Maven和自研集成工具等；
c.优化效能度量和绩效管理,与员工发展计划进行关联，让团队清晰了解目标和任务，如使用“以客户为中心
的工具平台”作为KPI，度量指标包括用户需求响应时间、需求处理时间等。
d.在员工意识和管理方面，对员工的素质、沟通能力和价值观等提出相应的要求，并与人才引入及人才培养
相关联。
实践结果
产品交付时间缩短37%，产品质量提升超50%。
总结
实现共同事业需打造敏捷“绿洲”，非常适合诠释敏捷原则第五条：
“激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。”
38
打造敏捷“绿洲”—敏捷部落与OKR或KPI有机结合
专家观点企业随着业务的发展和规模的扩张，部门墙阻碍的加重使跨团队资源协调变得愈发困难，打破部门边界，重塑“部落组织”
显得尤为重要。
Lyrin林一荷敏捷部落的核心是“组织结构”的变革，也是敏捷小队之间的联盟。每个部落通常有40～150人，由部落长负责保障目标的
清晰可见，帮助协调不同的敏捷小队，严格把控质量、评审及决策，并鼓励他们互相合作，从而让团队间清楚了解彼此当前
某金融科技质量管理负责人的工作和优先级。当然，每个部落和敏捷小队都有其独特的使命，OKR或KPI可以帮助团队去定义完成使命的目标，在与员
工发展计划绑定后，可以有效提高员工的积极性和参与度，并能够进一步提升服务效率和客户体验，让公司管理层对部落或
敏捷小队仅需保持“双手放开、双眼紧盯”的状态。
根据本人多年实践经验，在此推荐一个高效的团队管理实践：关键指标看板。
通过管理看板的建立，让员工能够随时看到反馈结果，感觉到被关注。在具体实践中，团队首先要确定好指标，例如：需求
价值、需求处理时效、排期时效、开发时效、测试时效等。其次，管理者需要求团队定期更新指标，作为日常管理工作的重
要内容，同时需要及时给予团队赞扬和评价，作为每周例会或迭代回顾时的材料之一。看板的类型较为多样，有坚持性看板
（追时间）、比赛性看板（追伙伴）、目标型看板（追差距），团队无论选择哪种类型，都一定要简单、醒目和易懂，关键
指标能够一目了然的展示在物理看板或电视大屏上。
39
实践：提炼符合敏捷价值观和原则的方法帮助团队具体落地敏捷。
6.4
“实践”指某种可以让我们达成目标的技术、方法或过程，并通过明确的做法来降低过程
中的错误。有效的实践能够帮助团队在敏捷中快速获益，并为组织的规模化敏捷打下基
础。如果说敏捷代表着一种抽象价值，那么实践就是它具体落地的方式。实践作为追求
敏捷的起点和方向，往往是一组精炼后的做法，当面向不同的环境与团队时，总需要有
所适配，这样才能真正地发挥敏捷的价值。
实践通过此次的调研，可以发现86%的中国企业已经从敏捷中找到交付节奏，并且正往下一个
阶段过渡，这代表着敏捷已经不再是口号，它已融入我们的工作环境，成为我们努力的目
标。在本节案例中，透过把握敏捷的价值，成功将结对编程转变为制造业也能采用的结对
PRACTICE 设计，进而大幅地提升产品的效率与正确性，也再一次证明敏捷并非专属于软件行业，而
是一种追求企业最大价值的方法。卢建成专家不仅点评调研结果和敏捷实践案例，并提出
了“寻求反馈是裁剪实践的重要关键”的观点，说明了反馈在持续改善实践的过程中所扮
演的角色，唯有掌握反馈才能找到最适合自己的敏捷实践。
40
86%中国企业已经从敏捷中找到交付节奏
从调研结果来看，45% 的团队已经能够固定迭代开发周期，只有 14% 的团队仍处于敏捷实践的摸索阶段。值得关注的是，排名第二的选择显
示，19%的团队会根据行业及企业现状熟练裁剪敏捷实践，且开始建立度量指标，这可能成为企业提升敏捷成熟度的下一个重点，并且已经有
企业开始往此阶段过渡。
公司内大部分团队开始形成独特敏捷实践且
10%
建设系统化价值流
某些部门内团队都能按时交付，建立 12% 86% 受访者所在企

反馈闭环，主动追求价值输出
业的团队已经从敏
团队能够根据行业及企业现状熟练裁剪捷中找到交付节奏
敏捷实践，且开始建立度量指标
19%
团队能够固定迭代开发周期为1~4周
之一，针对短板尝试主动解决
45%
团队初步了解敏捷方法，按照某个方法论实施敏捷 14%
0% 10% 20% 30% 40% 50%
样本量：n=78 Reg Q20：您所在企业的敏捷实践现状更符合以下哪一项？（单选题）
41
问题
使用传统串型开发流程设计固件导致返工频繁甚至模具损毁，致使成本居高不下。
问题成因
先进制造 1. 结构设计的考虑方向与电子元件限制有冲突；
2. 结构工程师无法即时获得电子工程师的回馈；
3. 结构工程师的瀑布式一次性设计导致回工成本更高。
实践维度案例敏捷实践
—— 结对设计 1. 让结构工程师与电子工程师进行每周三次，每次两小时的协作(每周三次是基于磨合后得出的频次，主要是因
为固件设计会需要一些各自独立的时间进行设计与研究。因此，这类频次会因为产品不同而有些许差异)；
2. 结对时，让电子工程师即时提醒电子元件上的限制，也让结构工程师能与电子工程师沟通设计上的需要，以
便找到最佳的替代方案；
伍舜喜（某一线制造行业合资企业） 3. 团队组成仍以多技能人员为主。一方面降低团队人数，另一方面让团队更聚焦于特定产品；

4. 结对设计的落地在时间跨度上有一个月。过程中，组织针对敏捷意识和跨技能的认识提供持续地培训，也鼓
励团队进行技术交流；
5. 透过提升产品意识以及直接与客户交流，来促使成员主动学习。
实践结果
1. 模具修改次数从原先十次以上，降至二次；
2. 时间节省为原先做法的十分之一，甚至更低；
3. 模具损坏的可能性降至零。
总结
结对设计非常适合诠释敏捷的第六条、第七条与第十一条原则：
"不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。"
"可工作的软件是进度的首要度量标准。"
"最好的架构、需求和设计出自自组织团队。"
42
寻求反馈是裁剪实践的重要关键
专家观点响应变化是敏捷的核心价值，而寻求反馈正是直面变化取得先机的重要手段。不论是产品或专案，当我们开始实现目
标，回馈便会持续驱动产品或专案来逼近最大的用户价值。寻求回馈就像是数学归纳法里证明 n+1 为真的过程。
卢建成因此，当我们着手裁剪实践时，除了确立改善的目的之外，第一要务便是寻求客观的反馈指标来协助我们了解裁剪的
效果与方向，而这个客观的反馈方式便是建立度量指标。这也呼应了问卷同时把实践裁剪和度量建立放在一个选项的
靖本行策创办人兼执行长原因，也是已经熟练既有最佳实践的团队应该追求的方向。
我们从案例中可以更进一步了解反馈的威力！他们发现固件设计的传统串型开发需要一棒接过一棒，但每一棒不仅有
各自的考量，同时这些考量又都需要相当长的时间才能够被检视，进而导致修改成本过高。因此，他们从工作的情境
中找寻能够更快取得反馈的地方，并且调整人员之间的协作方式来尽早获得开发回馈。最终透过模具修改次数、设计
总时长与损坏次数的客观指标，确认了实践裁剪的成效，而这也再一次让我们了解反馈的重要性。
敏捷实践能够让你体验敏捷，但想要获得敏捷的最大好处则需要熟练并且持续改善这些实践，而改善的关键就在于寻
求反馈。你是否正在思索如何提升团队的敏捷能力？试着从反馈的形式、目标、对象、频次与做法开始着手，相信最
终你也能找到最适合你的敏捷实践，就像案例中的团队成功地将敏捷软体开发实践转变为敏捷固件开发实践一样！
43
需求：高质量需求直接确保团队价值的持续输出和减少浪费。
6.5
“价值”作为敏捷的核心，包括用户价值、商业价值和社会价值。在敏捷实践的过程中，
最重要的是明确各项价值所在并坚定执行，一旦出现了偏差，便是南辕北辙，而目标的
实现需要有正确的方向、客观的数据、明确的标准和果断的决策。
需求管理是敏捷实践价值输出的关键点，而需求是所有研发工作的起点，如果需求质量
需求不高，后续环节的质量无从谈起。迭代间的需求要保持探索性，既要有计划也要灵活，
这样才能及时应对市场的变化，提供客户需要的价值。迭代内的需求要保持聚焦性，既
要重点特性突出也要保持不变，才能让团队集中精力，高效工作。
REQUIREMENT
本节所选用的“一周需求响应”实践案例，能够有效帮助大家掌握如何参考Scrum框架建
立短周期迭代，从而主动响应外部需求，快速完成产品交付。黄浩专家也在点评中强调
了需求管理的重要性，并根据经验推荐了“实例化验收条件”管理实践，来帮助团队更好
地完善用户故事。
44
82%中国企业在不同程度上采⽤⽤户故事描述需求
调查显示，仅18%的中国企业团队尚未以用户故事的形式编写需求，其余团队甚至组织已采用用户故事和产品Backlog开展需求管理。同时，
产品经理或PO已逐渐认识到减少每个迭代内的需求变更，可确保团队的专注度，有利于提升团队的工作效率。
企业内大部分团队善于运用敏捷需求管理实践
及时应对市场变化
6%
某些部门的所有团队能够熟练运用
15% 82% 受访者所在企业的团
敏捷需求规划完成产品间协同
队在不同程度上采⽤⽤户
团队全职产品经理管理迭代Backlog，运用
49% 故事描述需求
用户故事且减少迭代内需求变更
团队PO建设产品Backlog，用户故事遵循INVEST
且除了生产事故外无迭代内需求变更
12%
团队有成员负责整理产品需求，还未采纳用户故事 18%
0% 10% 20% 30% 40% 50% 60%
样本量：n=78 Reg Q21：您所在企业的需求管理现状最符合以下哪一项？（单选题）
45
问题
1. 作为ToB安全软件平台，信息安全威胁瞬息万变，需快速应对外部挑战；
2. 从原型产品交付到实体产品交付，团队交付压力持续增大。
问题成因
通信行业
1. 需求开发周期长短不一且缺少发布规划，经常在出现生产问题后被动发布；
2. 缺乏有效的需求交付管理机制，开发团队多工作并行但实际产出不及预期；
需求维度实践案例 3. 需求交付工作进度不透明，项目经理疲于跟踪项目各项细节。
—— 一周需求响应
敏捷实践
参考Scrum框架，对团队活动开展如下优化：
1. 为快速主动响应需求，团队基于已有的软件基础设施，建立固定交付周期，坚持每周小版本，每月大版本的
交付节奏，有效管理业务部门的期望值；
（中国电信研究院安全技术研究所
殷铭云原生及应用安全团队副总监）
2. 采用轻量化的文档用户故事来组织产品Backlog，依据安全威胁严重程度和工作量大小估算等因素，拆分用
户故事至不同的周版本或月版本，按既定规划源源不断地输出产品；
3. 建立敏捷看板和站会，可视化团队成员工作进度，实现日日有进展，事事有更新，团队成员共享项目进度等
4. 细节信息；
定期开展迭代回顾，检视并持续优化已有实践活动，促进团队提升工作效率。
实践结果
1. 需求响应平均时长从30天降低至1周；
2. 需求交付平均数量从每月10+提升至50+ 。
总结
以Scrum为框架，短周期快速迭代交付非常适合诠释敏捷的第一条与第三条原则：
“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。”
“经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。”
46
高质量需求确保团队价值的持续输出
专家观点需求管理是整个敏捷工作的火车头，良好的需求管理能够帮助团队聚焦在最有价值的工作上。
黄浩看到本次调研中，82%的中国企业及其团队已采用用户故事和产品Backlog开展需求管理，可见产品经理或PO已逐渐
认识到减少每个迭代内的需求变更至关重要，能够在确保团队专注度的同时提升团队工作效率。本节所采用的实践案
例能有效帮助企业掌握如何活用敏捷框架，采用轻量化的文档用户故事来组织产品Backlog，建立适合自身实际情况
某制造业公司数字化产品敏捷教练的需求交付节奏，满足业务部门的期望值。
随着用户故事广泛应用，在此推荐一个帮助完善用户故事的有效实践：实例化验收条件。
在实际工作中，我们时常可以听到团队成员抱怨用户故事欠缺业务细节，其中一个潜在原因就是没有妥善运用用户故
事的验收条件。实例化验收条件中，如描述应用系统处于边界值或者特殊值的响应行为，可以使团队成员更容易理解
所要实现的业务功能。此外，一些异常情况的处理也可以作为例子，添加在验收条件，使用户故事更加完整并且方便
成员理解。
47
工具：解决高频发生的应用工具低效问题从而释放团队的创造性。
6.6
合适的工具可以更好的可视化和流程化敏捷软件开发全生命周期，快速识别价值流动过
程中的卡点，提高不同职能、团队之间的协作效率。同时,也能帮助企业制定产品开发计
划，实现从需求到发布的全流程可追溯，提高产品质量，快速满足市场和用户的需求。
从调研数据来看，绝大多数中国企业在敏捷转型和落地实践中开始使用工具，也反映了
工具中国企业对于工具的认可和依赖。那么如何构建适合自己团队的工具，以及如何利用工
具提升需求和产品质量，减少测试资源投入，将在本节的两个敏捷实践案例中为大家阐
述。梁堃专家在点评中提出了“如何通过工具先行推动敏捷转型”的观点，强调了落地有
TOOL 效工具可以帮助企业进行敏捷转型的优势。
48
88%中国企业将⼯具引⼊到敏捷实践中
从管理工具的调研结果来看，已经有88%的企业将工具引入到具体的敏捷实践中，其中，有26%的企业能够做到将管理工具结合绩效指标，帮助
团队整体持续改进。这些数据均说明了敏捷工具的重要性和普适性，但目前工具运用情况从团队级、部门级再到公司级逐次降低，说明组织内管
理工具的统一和高效使用还需进一步发展。
公司内大部分团队均能依赖工具平台且
12%
团队主动优化工具平台适应业务发展
某些部门内团队不仅依赖工具平台完成工作
26%
且提供度量指标支持绩效改进 88% 受访者所在企业将⼯
具引⼊到敏捷实践中
团队能够有完整的工具平台覆盖关键活动 19%
团队中部分关键活动开始采用工具自动化提升效率或质量 32%
团队绝大多数关键活动仍然是手动完成
12%
且能配合计划
0% 10% 20% 30% 30%
样本量：n=78 Reg Q22：您所在企业使用的管理工具，支撑敏捷的程度情况，最符合以下哪一项? （单选题）
49
问题
由于需求完成情况未能可视化，团队间需求排期及资源投入情况不同步，时常发生需求插入。
问题成因
企业服务 1. 产品需求来自全集团多个部门，沟通成本高且目标不一致，导致产品优先级不清晰；
2. 研发团队资源不透明，无法按承诺完成工作；
3. 产品需求缺乏理性评估，并存在很多插入式需求变更。
工具维度实践案例敏捷实践
—— 自研行云平台自主研发效能工具“行云”来提供战略管理，通过在项目立项时关联战略目标，促进各个体系及部门的战略透明
化，并沉淀战略落地过程数据（如工时、收益等），用于度量、分析和持续改进。
1. 使用共享视图查看迭代需求详情。从“迭代看板” 、“迭代概览”、“项目视图” 、“风险分布”等不同角度

管理进行中及排队中的项目，根据迭代需求的关联性、需求各个状态交付的趋势、成本超支情况进行必要的
李鹏飞（京东科技数字化效能团队PO） 2. 项目风险管理；

通过“团队空间”从产品经理的角度查看包括业务需求、用户需求、技术需求等不同类型的需求来源和分布情
3. 况。根据需求价值、需求个数与产品经理团队人员配比、需求产生的工时等，判断需求的合理性；
通过“资源视图”实现个人（资源）工作饱和度的透明化，再根据实际工作安排，评估工时的合理性。通过制
4. 度规范和工时自动化填写来保障资源日历中信息的准确性；
通过CI/CD实现测试用例、测试包、需求和代码的联动。在“团队空间”使用自动和手工两种方式配置工作流
及相应的约束条件，如产品需求与任务联动，出现多个任务时，在最后一个任务完成后，需求可自动上线。
实践结果
1. 通过“行云”的使用，业务方能够清晰了解自己所提需求的进展以及产研团队的资源投入情况，降低团队沟通
成本；
2. 从战略项目落地情况来看，横向拉通的共享视图实现了相似需求的整合，减少了17%的需求插入，有效节省
人力成本。
总结
研发效能工具的自研和使用，很好的践行了敏捷第九条及第十条原则：
“坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。”
“以简洁为本，它是极力减少不必要工作量的艺术。” 50
适合的工具是敏捷实践提升效率的关键
专家观点
目前，越来越多的企业认识到适合的工具能够促进敏捷实践成熟度的进程，在企业敏捷转型或敏捷实践过程中，团队
王抒音
需要结合实际情况使用相应的管理工具。
2022年调研显示，有32%的企业已采用自动化工具来完成绝大多数关键活动，并实现了效率提升或质量提升，有26%
京东科技组织效能提升负责人的企业不仅依赖工具完成效率和质量的双重提升，还通过工具中的度量指标来支持企业绩效的改进。这些统计数据也
充分说明了越来越多的中国企业开始重视工具在敏捷实践中的运用。
本节实践案例中，企业自研的“行云”平台为我们带来全新的视角，不同于市面上其他的管理工具，“行云”更贴近真
实业务场景，能够从战略视角将落地的项目进行可视化，从价值、成本和收益层面给管理层提供可靠的数据支撑，帮
助管理层做决策。对于敏捷转型中使用到的各项实践，也都能够在“行云”中展现出来，从需求插入的无序，到协助战
略落地并最终沉淀过程数据，团队可以根据实际情况自定义度量指标，通过有效数据帮助团队实现持续改进。市面上
的工具种类繁多，任何企业都应该首先对自己的业务、流程和需求有充分调研及了解，再去选择适合的工具，这样才
能帮助企业实现敏捷，交付真正的价值。
51
问题
1. 产品需求质量低，功能文档不规范，导致研发和测试返工浪费；
2. 缺少版本规划，开发人员和测试人员之间存在障碍，被测代码容易失去控制。
问题成因
通信行业
1. 缺少有效工具建立测试用例到需求的可追溯性，无法保证功能测试覆盖率；
2. 没有自动化测试来保证每日构建质量，很多低级问题靠发版前的人工测试识别；
工具维度实践案例
3. 原有Jira工具由测试中心来控制，后台设置流程漫长。
敏捷实践
—— 落地工具提升研发质量 1. 引入TDD和自动化测试方法，通过开发代码和自动化测试代码同时入库确保每日构建版本冒烟测试通过。
从代码静态监测-动态监测-规范监测，再到接口自动化以及迭代中的测试，每天会有一轮简单的测试；
2. 将持续集成与项目的版本规划相结合，包括发布版本规划，内部迭代版本规划；
3. 研发管理工具替换。质量负责人推动落地PingCode工具管理需求-开发-测试的全生命周期，建立测试用
王波（某研究院质量负责人）
例到产品需求的可回溯性；通过PingCode进行产品需求规范化管理，对需求进行“史诗-特性-用户故
事”三级划分，使得用户故事需求粒度达到了每轮迭代（双周）可实现的合理水平，同时通过测试结果追
溯具体需求条目来提升产品需求质量；
4. 利用工具来完全覆盖开发及DevOps：让团队能够有完整的工具平台覆盖关键活动,以测试管理为例，摒
弃传统Word写用例集的方式，通过PingCode直接在用例上标注，包括版本号，不同发布能快速使用不
同用例集，并在工具中做缺陷的追溯和流转，整体效率提升明显。
实践结果
1. 引入TDD之后，利用自动化测试节省测试人力，接口测试从原来的10人天减少到5人天；
2. 借助PingCode管理测试用例，将项目整体故事级别需求的测试覆盖从40%提升到了100%；
3. 通过对产品的需求规范管理，用户故事需求粒度平均控制在2人天左右完成；
4. 测试用例的更新及时率提升，由原来的滞后4天减少到滞后1天。
总结
落地工具提升研发质量非常适合诠释敏捷第三条及第十二条原则：
“经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。”
来源：中国企业敏捷实践白皮书编委会自主研究及绘制 “团队定期地反思如何能提高成效，并依此调整自身的举止表现。”
52
工具先行推动敏捷转型
专家观点有效的工具可以更好的支持企业产品研发过程的可视化和流程化，提升软件研发效率和质量。
梁堃通过本次调研结果发现，绝大部分企业都较为重视工具链在软件开发过程的效能提升作用。本节所选用的实践案例中，
利用工具来覆盖开发及DevOps全流程并实现需求和测试的双向追溯，有效提升了研发全生命周期质量并减少测试资源
投入，这对ToB企业或内部IT部门都具备很好的借鉴意义。
某新势力造车企业敏捷教练
依据此实践并结合个人经验，推荐一种“工具先行推动敏捷转型”的实践方法。
这个方法主要是用于在企业敏捷转型初期，团队的敏捷成熟度无法很好的支持敏捷实践落地，如Scrum, SAFe, TDD/
XP等，我们可以选择引入一些软件研发、测试、质量管理等工具，并附以部分预先定义好的研发过程指标，通过统一
和规范团队在研发过程中的动作，减少不同团队或个人由于对敏捷实践的理解不一致带来的效率损失，快速赢得领导层
的支持，进而推进深层次敏捷转型。
53
质量：过程性预防性全面性的质量控制方法不仅输出价值还能减少浪费。
6.7
把组织的质量政策应用于规划、管理、监控项目和产品质量，以满足相关方目标及过程
要求。敏捷开发的质量管理内建在每一种活动中，例如基于INVEST原则的用户故事形式
的需求定义，持续集成、持续交付、测试驱动(TDD)、行为驱动(BDD)的软件开发，基于
工具的自动化测试，用户参与和反馈的合作理念等等，都是确保软件质量的前沿思想。
质量在2022年筛选的Top实践案例中，可以看到企业或团队在敏捷质量管理上的创新,包括场
景化测试、迭代T+1自动化覆盖、一套自动用例到处运行、用例持续运行可视化等，而这
也进一步促进了价值流动。
QUALITY
54
45%中国企业重点放在迭代内的质量管理
调研发现，受访者所在企业在践行敏捷实践的过程中，对质量均保持了良好的认知和应用。调研问题背后是按照成熟度进行5级区分，其中有
45%的团队已具备了一定的质量意识，能够并行研发与测试；有17%的团队能够度量和确保业务全流程实施质量，并有8%的团队定义了独特
的敏捷质量管理实践。整体来看，敏捷质量管理实践同样多围绕在团队级，部门级和企业级开展仍不充分，需持续推广。
企业内有敏捷团队具备输出独特的
质量管理实践，质量管理成为行业标杆
8%
某些部门内所有团队具备对
业务全流程实施质量度量和确保 9%
团队全角色具备敏捷指质量意识，实现
17%
质量左移或右移
团队有敏捷质量意识，能够并行研发
与测试，迭代内质量逐步提升 45%
团队主要依赖测试岗位单方面确保
22%
质量，关键环节有质量标准要求
0% 10% 20% 30% 40% 50%
样本量：n=78 Reg Q23：您所在企业的质量管理现状更符合以下哪一项（单选题）
55
问题
汽车主机厂面向终端用户体验更频繁的提供创新服务，传统的汽车零部件供应商质量管理体系难以满足更短周
期的交付要求。
问题成因
汽车电子
1. 软件定义汽车背景下，主机厂已经不满足于供应商仅在量产阶段一次性交付标准的硬件产品；
2. 在差异化竞争的驱使下，主机厂对零配件供应商也提出了更多的个性化要求；
质量维度实践案例
3. 在传统管理模式下，从提出问题到解决问题至少需要2-3个月的时间，经历漫长的验证周期，无法适配功能
的创新速度。
—— 软硬一体持续交付敏捷实践
1. 自顶向下推动变革：
a. 业务管能够理解敏捷的价值并积极传递决心；
b. 质量部门在制度层面进行创新，在不牺牲行业质量体系和产品安全要求的前提下，针对软件特征优化研发
李敏（跨国汽车零部件供应商 PMO）阶段的检查标准，重视风险的评估和监控，调整了研发质量的监控指标体系；

c. 团队基于客户能够提供的阶段性变更内容形成工作包；
d. 测试团队根据客户使用的场景进行裁剪，提升了测试的灵活性。
2. 重构质量体系提升客户响应速度：
a. 在思维层面，团队从内部质量视角更多的转向了外部的客户视角；
b. 由独立的质量工程师参与到日常的敏捷开发跨部门横向协同；
c. 跨部门共享项目Dashboard，实时更新质量的达成情况，数字化所带来的透明性使矩阵团队转换为平台团
队，让团队可以保持全局的掌控甚至预测问题的规模，使协作发生了本质的改变。
3. 中国实践全球化改善价值流动：
a. 中国团队主动通过改进项目持续的打通工具，连接数据孤岛，突破了集团全球部署的工具支撑不足的问题；
b. 工具的精细化使用也大量的减少了交付的检查工作，改善了流程长、跨部门合作响应慢的问题。
实践结果
1. 引入敏捷最重要的是支撑了公司产品销售模式的改变，从软件嵌入在硬件中交付，变为软件可持续的迭代交付。
2. 引入敏捷后样件交付的频率提升了1倍，量产节点后软件依然可持续交付，远程刷新。
总结
来源：中国企业敏捷实践白皮书编委会自主研究及绘制本实践案例很好的体现了敏捷软件开发宣言中 “响应变化高于遵循计划”。

56
让质量成为每个人的工作
专家观点在敏捷的十二项基本原则中，每一项都直接或间接的提到了质量。在具体的实践领域，伴随着敏捷方法论的持续迭代，
质量内建已经覆盖了架构和设计质量、代码质量、发布质量、系统质量和Flow的质量，系统性的质量管理进一步降低
瞿博文
了召回、返工和修复缺陷带来的延迟成本，保障了开发价值流的快速流动，让质量成为每个人的工作。
本节所采用的“软硬一体持续交付”的实践案例中，企业通过自顶向下的敏捷转型，进行制度创新、体系创新，又经历
Shaping future leadership，数年持续的变革重塑了文化和思维，让团队视角从内部转向外部；通过数字化的工具、电子看板、Dashboard的运用
新能源汽车数智化团队PMO专家改善信息的透明性，促进了矩阵团队向平台团队的转型。
在2022年的敏捷实践调查中，我们欣慰的发现近20%的团队在质量实践中已经不仅仅局限于对项目/产品/服务的需求
满足、产品功能层面，而是能够更多的从收益的实现、价值的创造层面去思考和践行质量管理。即使是传统制造业下的
软件团队，也开始将质量管理更敏捷的应用在面向客户的价值交付和价值保障上，进而促进企业与客户间的价值流动。
57
问题
版本持续迭代，关键路径上的场景持续增加，导致回归测试时长无法收敛，产品质量难以控制，挤压迭代交付容量。
问题成因
IT/互联网 1. 手工测试占比太高，测试不够高效；
2. 过度追求交付速率，对技术架构治理投入不足；
3. 过度依赖测试阶段控制质量，上游研发缺乏早期看护。
质量维度实践案例敏捷实践
—— 接口级自动化测试 1. 自动化测试体系搭建：减少功能测试人力，置换原人数30%的专职人员进行自动化测试建设，并增加产研自测流
程，按迭代T+1实现自动化覆盖。
a. 适配范围：因当前项目轻前端重后台，场景化接口测试为主，单元测试为辅；
b. 工具选型：使用公司内成熟用例编写框架，后期快速接入DevOps做为质量门禁和卡点；
查俊腾讯高级研发项目经理 c. 编写规范：考虑测试资源和数据的独立性，便于后期可以快速在多环境执行，真正做到一套自动用例到处运行；
d. 用例维护：用例持续运行数据可视化，底层异常信息标准化错误聚类，大幅减少分析维护成本。
2. 区分特性团队和技术域团队：特性团队面向交付，技术域面向技术架构，提供公共服务、看护架构质量。
a. 人才培养：每个技术域设置专门的值守人（兼职），日常参与迭代交付，纵深看护领域内技术架构；
b. 公共服务：迭代技术方案横向Review，抽象公共服务解决方案，监督研发遵循执行&技术债消除；
c. 稳定性建设：从性能排查、研发规范、灰度策略、监控告警、资损对账等维度，持续搭建质量稳定体系。
实践结果
1. 通过自动化测试建设，测试人力降低为原来30%左右，结合技术债的消除和对技术域的值守保证了稳定的产品质量；
2. 自动化能力的提升，使得冲刺周期中回归测试的时间从3天缩减为1天，提升了需求和价值的实际交付量。
总结
质量管理是高速持续迭代的基石，通过测试自动化技术体系的搭建，才能规模化提效；测试不应该是质量管理的“保
护伞”，质量应该前移到架构规范、服务标准化，从源头就开始治理。本案例体现了敏捷第七条和第九条原则：
“可工作的软件是进度的首要度量标准。”
“坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。”
58
主动消除技术欠债，在源头处保证质量
专家观点敏捷倡导迭代开发和增量交付，以便更多、更快地支撑产品和服务的尝试性实验，及早获得来自于用户和数据上的反
馈，帮助企业在高度不确定的BANI时代和激烈竞争的市场环境中获得成功。在这种短周期交付的节奏中，测试和验证
林伟丹
的周期相当有限，如何保证研发质量和安全、又好又快地交付，面临着巨大的挑战。解决这个挑战的秘方例如：基于
更小的需求粒度进行跨职能协作，拉动需求流动减少阻碍和停滞，提升代码签入后部署价值流的自动化程度，促进敏
捷团队内部的技能备份和基于瓶颈的互相补位协作，等等。在这些方面，在腾讯查俊经理带领的团队案例中，有着良
好的实践和成果。
旭势教练深圳合伙人
敏捷变革专家内建质量（Build-in Quality）是当下企业中重要的质量理念，也称为在源头处保证质量（Quality at the Source），
与丰田精益五原则中的尽善尽美（Perfection）也有很强关联。对于软件开发来说，这种理念与以往以“阶段-门径”为
特征的软件工程过程有显著不同，对于产品的质量，不再寄望于一个或多个单独的、长周期的后置测试阶段来保证质
量，而是更积极的将质量前置（Shift Left），力图在代码写好的那一刻（或在几分钟或几小时之后），就能符合上线
的质量标准，达到潜在可交付的程度。DevOps与持续交付相关的各种工程技术实践应运而生，在近些年越来越多地普
及开来。
主动消除技术欠债也是持续保证系统质量的另一个重要视角。技术欠债通过日常非最优的技术选择（迫于项目压力或
工程师的能力、惰性因素）而形成，属于看不见而又产生消极影响的一类东西，需要在平时的工作过程中持续“还
债”，最好通过有意识的“产能分配”，给技术类的改进留出一定百分比的研发资源；否则会逐步拖累、拖慢研发的步
伐，并且对系统质量产生更大的压力。在查俊的案例中，对于每个技术域的专人值守、对于技术方案的横向review，
也都有助于减少欠债、提升效能。
59
学习与改进：自组织团队能够定期反思并采取针对性行动来提升人效。
6.8
团队需要定期反思如何提高效率，并相应地调整其行为，“学习与改进”作为敏捷的十二
条原则之一，始终扮演着重要角色。通常团队会采用回顾会的方式来反思哪里做的比较
好，哪里可以改进，以确保不断检查和适应他们的工作方式。敏捷的核心在于让个人、
团队乃至整个组织变得更加灵活，且有能力根据实际需求以及客观条件来采纳这种思
想。
学习与改进调研发现，70%的中国企业在学习和改进方面仍停留在团队级，但随着敏捷转型的深入，
定会逐渐从团队级向部门级甚至企业级慢慢转移。本节实践案例中“会诊式培养敏捷教
练”的具体做法，突出了敏捷以人为本的学习和改进，王用涛专家也在点评中强调了通过
LEARNING & 人员成长来提高研发效能的重要作用。
IMPROVEMENT
60
70%中国企业重视团队成员的学习与改进
从团队的角度出发，70%的受访者所在企业会定期基于问题进行复盘，其中有半数团队愿意参与改进并主动学习；从部门的角度出发，有10%
的企业可以进行有创造性的改进；从企业的角度出发，有9%的企业可以形成持续改进的文化。从调研结果来看，中国企业的学习和改进仍停留
在团队级，但随着敏捷转型的深入，定会逐渐从团队级向部门级甚至企业级慢慢转移。
企业内形成持续改进的文化
9%
并且针对业务价值流不断改进
某些部门内所有团队有创造性的改进方案
促进高绩效团队 10%
团队定期对工作方式进行系统性回顾，有意愿
参与改进，主动学习新知识 35%
70% 受访者所在企业重视
团队会基于问题进行复盘，提出团队成员的学习与改进
建议并落实改进 35%
团队有一些改进行为，没有形成习惯 12%
0% 10% 20% 30% 40%
样本量：n=78 Reg Q24：您所在企业的学习与改进现状更符合以下哪一项？（单选题）
61
问题
产品交付时间长，外部故障率高且内部缺少敏捷教练。
问题成因
通信行业 1. 缺少适合企业内部的教练团队；
2. 缺少如何培养内部教练的方法；
3. 缺少对内部敏捷教练的职能定位。
学习与改进维度实践案例敏捷实践
——会诊式培养敏捷教练在敏捷转型中，中兴通讯逐步形成了会诊式培养内部敏捷教练的方法，并使得他们成为排头兵和赋能者。
1. 划分公司内部敏捷教练的职能、定位和培养方式。团队级采用结对培养工作方式；项目级负责开发，测试
相关部分；产品级负责前端、市场、运维等多个维度；
2. 培养内部的敏捷教练团队。从内部选择新的敏捷教练，通过赋能来帮助其快速成长，并充分利用公共项目
小武（中兴通讯敏捷教练）提供锻炼机会，包括平台级项目、DevOps 工具或资源管理类工具等等；
3. 利用会诊培养内部教练，提高效能。组建专家教练团队，在被邀请的项目中进行会诊，包括但不限于工
具、需求实例化、TDD、 BDD等一系列敏捷实践，然后提出具体的改进意见，半年之后再重新审视改进
效果。
实践结果
1. 内部教练人数显著提高：从不到10人的团队到现在200人左右；
2. 质量不断提高，原来的外部严重故障缺陷率大概10%，经过这5-6 年的努力，严重缺陷率已经降至0，鲜有
严重的外部故障；
3. 原来的产品发布周期大概是1年一个版本，现在是半个月一个版本，3个月一个交付。
总结
会诊式培养敏捷教练的实践方式非常适合诠释敏捷中“响应变化高于遵循计划”这一价值观，以及敏捷第五条、
第八条、第十二条原则：
“激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。“
“敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。”
来源：中国企业敏捷实践白皮书编委会自主研究及绘制 “团队定期地反思如何能提高成效，并依此调整自身的举止表现。”
62
没有最好，只有更好
专家观点古有云，“知错能改，善莫大焉”。当我们发现自身、团队或组织出现问题时，能够及时修正，就有机会逐渐走上一条
在当时的认知条件下，所能选到的最好的路。现有云，“没有最好，只有更好”。很多企业认为自己已足够强大，维持
王用涛
现状即可，所有这些都成为了停滞不前的理由，给未来留下了隐患。
“学习与改进”不仅仅指回顾时用来修正自身的偏差，也需要在舒适区时刻起到警示作用，这样才有机会在激烈的市场
富达国际敏捷教练环境中不断地发展。团队在敏捷项目中会遇到很多不确定因素，例如市场竞争、客户需求、产品设计和团队的现状。
基于学习与改进的思想，团队可以从现有情况出发，重新判断事物的有效性，并在必要时快速纠正。
本节所选用的敏捷实践是关于“内部敏捷教练团队培养”这个话题，对大型企业或在敏捷转型初期的组织都有很好的借
鉴意义，通过上述实践方法能够有效地解决以下问题，即当外部教练离开之后，组织内部如何一步一步培养自己内部
的敏捷教练，该敏捷实践不但使成员得到培养，被赋能，还帮助团队及组织继续保持原来外部教练在时的状态，继续
遵循敏捷的流程，拥抱敏捷的文化和价值观。定期的组织敏捷教练团队对单独的项目团队进行会诊，不但直接提高了
团队的敏捷成熟度，而且还通过会诊，相互交流，帮助内部敏捷教练成长。
63
附录
1.1 自 2001 年《敏捷宣言》发布之后，敏捷及其管理方法在国内的采用率已有大幅提高，敏
捷思维模式的理念和实践不再局限于特定规模的组织或一些仅专注于信息技术的企业，
而是被广泛应用并取得了显著成效。但是，无论企业还是团队，在敏捷实践过程中都会
敏捷实践有一定程度的顾虑，并希望得到敏捷实践方面的指导，或有一个框架性的模型作为指
南，来帮助自身查漏补缺，日臻完善。经过执委会二十位敏捷专家的沟通和协商，为业
成熟度模型界奉上“敏捷实践成熟度模型”，模型围绕敏捷实践八大维度，并给出一星到五星评价标
准，旨在帮助各组织评估和讨论当下敏捷实践现状。（本模型是基于“敏捷术语表”内容
作出，无法照顾到所有敏捷实践分支，请大家见谅）
MATURITY MODEL
此次白皮书中的“敏捷实践成熟度模型”只是一个开始，期待大家积极参与评估，提供反
馈建议，我们将在后续的模型迭代中持续优化改进。
—— 中国企业敏捷实践白皮书执行委员会
64
附录敏捷实践成熟度模型
1.2
1星 2星 3星 4星 5星
有价值方面的基本定义，有价值的目标设定、评估基于多维度价值评估，有大部分团队形成端到端的企业形成动态的价值改进

产研过程中也会有相应的规则，根据价值对需求优相应的组织机制确保高价价值交付闭环，涵盖价值体系与企业战略、业务发
价值
简单分析先级进行排期，指导工作值能够优先交付，量化评假设、价值评估、价值交展及产品策略等始终保持
开展价交付价值付、价值验证等紧密联动
团队领导通过管控成员影团队领导参与项目，采用团队领导以身作则践行敏大部分团队领导不仅以身企业内各部门领导层联动，

响项目，没有主动培养团非正式地培养团队成员。捷原则，能明确的识别人作则践行敏捷原则，通过带头推动变革。培养团队
队成员成员发表意见由领导决策才并主动培养。有意识授社区筛选等自下而上方法各岗位专家，支持对外分
领导力
权员工做决定而不仅仅听培养人员。授权团队成员享。信任团队完全授权。
模型
取汇报做决定，与团队无障碍沟具备内观觉察应对团队的
通，并充分听取反馈动态变化
团队以职能型、矩阵型、敏捷团队初具规模，团队敏捷团队成员稳定，逐步大部分敏捷团队运转良好企业内形成大规模级敏捷

项目型存在，具备潜在敏成员12人以内，成员运用形成自组织，对敏捷的价形成自组织，不断迭代进形态，能够根据价值度量
评价标准
捷团队雏形，团队有意愿敏捷实践解决问题，有工值有所共识，运用敏捷实化，对价值制定度量标指导实际工作，熟悉并掌
团队
尝试敏捷转型具能将敏捷工作透明化，践并不断迭代，协作流程准，开始创造敏捷实践解握敏捷原则，熟练运用敏
团队成员沟通顺畅和工具运用熟练决自身问题，团队成员彼捷实践，不断调优成为高
此信任和互相补位度自组织的团队
了解敏捷实践，并尝试一主动采取合适的敏捷实践，建立度量指标，有意识采大部分团队熟练运用大量企业内形成系统的敏捷实
EVALUATION 实践
些敏捷实践按照迭代组织各项工作取各种敏捷实践调整优化
后解决问题，迭代周期能
够固化在1-4周
敏捷实践并能创造适合自
身的独特敏捷实践，尤其
是建立反馈闭环，有效管
践机制，不仅帮助企业解
决问题还能对外输出，帮
助敏捷社区丰富敏捷实践
CRITERIA 理创新的浪费
1. 价值：认准目标客户才能确保敏捷实践的结果是有价值的。 3. 领导力：激励敏捷人才并营造敏捷文化确保敏捷转型成功。
2. 团队：结合客户行业企业自身优势的自组织管理才是有效的。 4. 实践：提炼符合敏捷价值观和原则的方法帮助团队具体落地敏捷。
65
附录敏捷实践成熟度模型
1.2
1星 2星 3星 4星 5星
被动采纳一些工具，支撑主动采纳各类工具，帮助团队建立工具链，获得度大部分团队从工具层面支企业内基于工具平台形成

团队完成产品开发生命周团队提升产品开发生命周量指标，对产品开发生命撑各阶段的度量指标需系统的工具体系，有效促
工具
期期各个环节的效率和质量周期各阶段的目标提供有要，进而促进敏捷流程和进企业成为生态型组织，
效支撑工具的优化响应市场变化
团队中有成员兼职收集并团队中有成员，如产品负团队开始以用户故事管理大部分团队的用户故事遵循企业内产品管理团队基于

管理产品需求进行产品规责人PO，专职生成并管理需求，建立产品需求列 INVEST原则，产品规划能够企业业务价值管理多团队
需求划需求，能够按照需求优先表，每个迭代规划合理形按迭代有序的根据用户反馈需求优先级，交付产品级
级进行迭代规划成产品节奏逐步优化，并能协调各方的解决方案
模型
需求优先级
对质量有基础管理，例如每个项目有质量标准和规团队全角色具备质量意大部分团队具备全角色质量企业内敏捷质量管理不断

测试用例，测试执行和测范，受管理层重视，各岗识，开始质量左移实践，意识，结合行业属性实现提得到优化和提升，具备输
试报告，质量主要依赖测位有相应质量控制，开始项目各阶段有流程、工具质降本的目标，实现质量左出能力和成为行业标杆，
质量
评价标准
试团队确保尝试自动化测试和发布和度量、针对不同交付场移和右移双重保证，质量管为业务发展突破助力
景的质量标准和质量门理工具实现全流程全生命周
禁，关键接口实现自动化期应用
测试
有初步的改进行为，还未团队基于已发生问题进行团队定期对工作方式进行大部分团队持续改进的活动随时随处改进的文化渗透
EVALUATION 学习
与
形成改进的习惯复盘，提出防范和改进措
施，并不断提升问题解决
的技能
回顾和调整，有定性和定
量的信息输入，有具体可
落地的改进行动项，并纳
致力于促进业务价值流动、
打造高绩效自驱团队，团队
成员共创有创造性的提升方
到企业内大部分团队的日
常工作中，有明确的导向
和机制加速团队自身的学
CRITERIA 改进入团队的工作列表进行跟
踪
案，主动承担和推进改进工
作
习和成长，员工有充足的
时间和空间进行知识分
享、创新共创和集体学习
5. 工具：解决高频发生的应用工具低效问题从而释放团队的创造性。 7. 质量：过程性预防性全面性的质量控制方法不仅输出价值还能减少浪费。
6. 需求：高质量需求直接确保团队价值的持续输出和减少浪费。 8. 学习与改进：自组织团队能够定期反思并采取针对性行动来提升人效。
66
附录执行委员会
2.1
以下人员是受邀敏捷专家（以姓名字母为序），负责本次敏捷实践白皮书的深度访谈并提供宝贵建议。
陈忠龚明杰黄浩李晖李宇航林伟丹林一荷卢建成梁堃孟美伶
瞿博文申健王立杰王伟王用涛王艳茹王抒音徐毅姚冬张志华
编委会代表编辑委员会
以下人员负责本次敏捷实践白皮书的拟定、审查和设计。
COMMITTEE 薛军 | 执行指导鑫茹 | 设计师
李乔 | 执行指导孙宇 | 出版编辑
张羽葶 | 策划
出品方老布谈敏捷联合出品
67
附录感谢为本次白皮书提供真实有效数据的受访者，在征求受访者同意后公布以下名单，以接受访谈时
2.2
间为序，期待更多的敏捷实践者参与到白皮书的建设中：
陈浩刘泉殷铭李綦睿倪晓闹张锋查俊
李进迪钟永林谢峥嵘 Lee.c 刘波曾忠群余知权Leo
尹建平韩正山李敏张良高英鑫王翔宇李鹏飞
全国出品人丁星明
爱华
肖鑫
方胜
罗月霞
骆蓓
陈亮
郑武军
侯明
王波
Molly
孙西华
马传佳
汤蓉
陈雨卿魏冬曹凯伍舜喜吴言包鹏飞夏语

CO-PRODUCER 陈军刘汐波王纳伟钱一鸣金棋樊彬琰王志峰
金可栋徐俊轩赵爽张俊赵苏宁苏湘伦李颖
侯守立李景鑫韩振峰唐文晟曾艳童飞穆晶晶
郑海源胡强刘晓峰李敏 Michelle 代燚朱博帆
68
参考内容参考内容
本白皮书用到的敏捷术语主要参考敏捷宣言，Scrum指南，Agile Subway Map等。
REFERENCE & 敏捷宣言：
https://agilemanifesto.org/iso/zhchs/manifesto.html
GLOSSARY Scrum指南：
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Chinese-Simplified.pdf
敏捷地铁图：
https://www.agilealliance.org/agile101/subway-map-to-agile-practices/
69
序号实践名称实践者八维度页码
1 ABTest中台化余知权价值 30
敏捷实践索引 2
3
走动式激励
去中心化决策
侯先生
张志华
领导力
领导力
34
35
INDEX OF 4 打造敏捷“绿洲” 魏冬团队 38
AGILE PRACTICE 5 关键指标看板 Lyrin 团队 39
6 结对设计伍舜喜实践 42
7 一周需求响应殷铭需求 46
8 实例化验收条件黄浩需求 47
9 自研行云平台李鹏飞工具 50
10 落地工具提升研发质量王波工具 52
11 工具先行推动敏捷转型梁堃工具 53
12 软硬一体持续交付李敏质量 56
13 接口级自动化测试查俊质量 58
14 会诊式培养敏捷教练小武学习与改进 62
70
关于北京易成时代科技有限公司自2012年成立以来，已服务 70万＋团队用户和 6000+ 付费客户，旗下智能化
研发管理工具 PingCode 是国内领先的软件研发与协作平台。PingCode 基于敏捷研发与高效协作理念，为
不同规模研发团队提供产品管理、项目管理、知识管理、测试管理、效能度量、协作空间、自动化、目录服
务等全生命周期企业级研发管理能力，同时满足非研发团队的流程规划、跨项目管理和在线办公需要，让研
发管理自动化、数据化、智能化，帮助企业提升研发效能。
协作空间第三方系统
话题讨论代码托管
产品管理项目管理测试管理 CI/CD
自动化测试
IM工具
测试报告
身份认证服务
知识管理自动化效能度量
OPEN API
多人协同编辑即时规则
关注公众号访问官网工单系统
目录服务
……
71
法律声明
版权声明
本白皮书版权归PingCode（北京易成时代科技有限公司）和薛军（老布谈敏捷）所有，并受法律保护。此文稿中含有专有信息，任何个人或是
组织在未得到PingCode（北京易成时代科技有限公司）和薛军（老布谈敏捷）书面授权之前，不得对此文稿中信息进行复制及电子化的任何形
式传播，否则将违反中国有关知识产权的相关法律和法规，对此本公司有权追究其法律和商业道德之职责。转载、摘编或利用其它方式使用本
白皮书文字或者观点的，应注明“来源：中国企业敏捷实践白皮书”。违反上述声明者，本公司将追究其相关法律责任。
免责条款
本白皮书中发布的调研数据采用样本调研方法，其数据结果受到样本的影响。企业数据主要为访谈获得，PingCode（北京易成时代科技有限公
司）和薛军（老布谈敏捷）对该等信息的准确性、完整性或可靠性作尽最大努力的追求，但不作任何保证，在任何情况下，本白皮书中的信息
或所表述的观点均不构成任何建议。由于调研方法及样本的限制，调查资料收集范围的限制，该数据仅代表调研时间和人群的基本状况，仅服
务于当前的调研目的，为市场和客户提供基本参考。受研究方法和数据获取资源的限制，本白皮书只提供给用户作为市场参考资料，本公司对
该报告的数据和观点不承担法律责任。
72
2022
中国企业敏捷实践白皮书
STATE OF AGILE REPORT 2022
Thanks
对于此次调研有任何疑问请联系我们：
薛军：7279171@qq.com 400-800-1024

《2022中国企业敏捷实践白皮书》

Uploaded by

Copyright:

Available Formats

You might also like

《2022中国企业敏捷实践白皮书》

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

《2022中国企业敏捷实践白皮书》

Uploaded by

Copyright:

Available Formats

2022

GOAlS & 业敏捷实践现状，为敏捷社区、敏捷教练和企业管理层提供真实可信的数据支撑。

ABOUT RESEARCH 终形成白皮书敏捷实践八个维度分析和TOP10年度最佳敏捷实践。

样本量：n=644 Reg Q02：以下哪个岗位名称能够最恰当的描述您当前的岗位?（单选题）

教育 医药健康 其他 1001~5000 人 5000+ 人 1000+ 人

样本量：n=644 Reg Q03：您所处的行业是？（单选题） 样本量：n=644 Reg Q04：您所在企业规模是？（单选题） 样本量：n=644 Reg Q05：您所在企业的软件开发团队规模是？（单选题）

中国企业 5.2 敏捷实施

5.3 收益与挑战 Q15.受访者认为敏捷项目成功的重要因素

0% 13% 25% 38% 50%

2021（n=501） 2022（n=644） Reg Q06：您所在企业敏捷团队的比例最符合以下哪一项？（单选题）

试点敏捷团队 敏捷团队未过半 敏捷团队已过半 全部为敏捷团队

不到一年 1~2年 2~3年 3~4年 4~5年 5~6年 6年以上

样本量：n=644 Reg Q06：您所在企业敏捷团队的比例最符合以下哪一项？（单选题） Reg Q09：您所在企业的敏捷实践了多少年？（单选题）

20% 21% 20%

Reg Q05：您所在企业的软件开发团队规模是？（单选题） Reg Q06：您所在企业敏捷团队的比例最符合以下哪一项？（单选题）

0% 10% 20% 30% 40% 50% 60% 60%

样本量：n=644 Reg Q07：您认为所在企业采用了如下敏捷管理实践?（复选题）

Extreme Programming(极限编程) 13%

0% 10% 20% 30% 40% 50% 60%

样本量：n=644 Reg Q08：您认为所在企业使用哪个敏捷方法?（复选题）

20% 19% 18%

样本量：n=644 Reg Q09：您所在企业的敏捷实践了多少年？（单选题）

至19%，其他规模化敏捷框架如Enterprise Scrum（企业级Scrum）、Spotify Model（Spotify模式）在使用上均有提升。此外，对比企业规模和

0% 5% 10% 15% 20% 25% 30% 35% 1~3周 4周以上或者不固定

40% 33% IT/互联网企业（n=297） 非互联网企业（n=343）

Continuous Integration（持续集成） 78%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

样本量：n=78 Reg Q12：您认为所在企业采用了如下敏捷工程实践?（复选题）

0% 10% 20% 30% 40% 50%

样本量：n=644 Reg Q13：您所在企业在使用如下哪个敏捷工具?（复选题）

0% 10% 20% 30% 40% 50% 60% 70%

样本量：n=644 Reg Q14：您认为您所在企业采用敏捷的核心原因是?（复选题）

产品经理/Product 中层管理者 CXO（CEO/

加速软件交付 71% 61% 62% 69% 55% 50% 42%

提升团队的生产力 55% 51% 53% 43% 52% 65% 53%

增强需求变更的管理能力 51% 49% 53% 47% 53% 65% 26%

提升软件质量 49% 34% 34% 31% 32% 45% 32%

加快应对客户反馈 44% 26% 27% 36% 38% 45% 42%

减少项目风险 29% 17% 28% 35% 29% 30% 26%

改善研发进度的透明度 33% 24% 19% 29% 37% 45% 16%

及时地应对市场变化 29% 18% 11% 21% 19% 35% 32%

提升IT与业务匹配度 15% 13% 15% 19% 25% 10% 26%

降低产品的成本 11% 14% 13% 19% 25% 25% 5%

提高团队士气 16% 6% 7% 13% 15% 20% 16%

加强分布式团队管理 7% 6% 9% 12% 18% 35% 11%

样本量：n=644 Reg Q02：以下哪个岗位名称能够最恰当的描述您当前的岗位？（单选题） Reg Q14：您认为您所在企业采用敏捷的核心原因是？（复选题）

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

样本量：n=78 Reg Q15：您认为评价一个敏捷项目成功的重要因素？（复选题）

组织拒绝变化的阻力 25.5% 50%受访者认为企业规模化

0.0% 10.0% 20.0% 30.0%

产品经理/Product 中层管理者 CXO（CEO/

组织拒绝变化的阻力 27% 23% 24% 28% 29% 35% 21%

没有敏捷实践经验 18% 25% 24% 30% 26% 35% 11%

组织文化与敏捷的冲突 31% 24% 20% 27% 33% 15% 26%

缺少管理层的支持 16% 25% 20% 24% 18% 10% 26%

习惯了基于PMP的传统研发方法 16% 33% 17% 28% 8% 10% 21%

缺乏培训或咨询 11% 22% 20% 23% 11% 30% 11%

缺少合适的工具 9% 14% 19% 20% 16% 30% 11%

部门墙的阻碍 29% 11% 10% 21% 21% 10% 32%

教育医药健康其他 1001~5000 人 5000+ 人 1000+ 人

样本量：n=644 Reg Q03：您所处的行业是？（单选题）样本量：n=644 Reg Q04：您所在企业规模是？（单选题）样本量：n=644 Reg Q05：您所在企业的软件开发团队规模是？（单选题）

试点敏捷团队敏捷团队未过半敏捷团队已过半全部为敏捷团队

40% 33% IT/互联网企业（n=297）非互联网企业（n=343）

余知权（某互联网公司高管）

曼合普管理咨询公司咨询经理度去激发知识性工作者的内在动机，授权赋能，改变以往过度僵化、缓慢的集中化决策方式。本案例中侯先生推荐的

某金融科技质量管理负责人的工作和优先级。当然，每个部落和敏捷小队都有其独特的使命，OKR或KPI可以帮助团队去定义完成使命的目标，在与员

伍舜喜（某一线制造行业合资企业） 3. 团队组成仍以多技能人员为主。一方面降低团队人数，另一方面让团队更聚焦于特定产品；

某制造业公司数字化产品敏捷教练的需求交付节奏，满足业务部门的期望值。

李鹏飞（京东科技数字化效能团队PO） 2. 项目风险管理；

京东科技组织效能提升负责人的企业不仅依赖工具完成效率和质量的双重提升，还通过工具中的度量指标来支持企业绩效的改进。这些统计数据也

李敏（跨国汽车零部件供应商 PMO）阶段的检查标准，重视风险的评估和监控，调整了研发质量的监控指标体系；

来源：中国企业敏捷实践白皮书编委会自主研究及绘制本实践案例很好的体现了敏捷软件开发宣言中 “响应变化高于遵循计划”。

Shaping future leadership，数年持续的变革重塑了文化和思维，让团队视角从内部转向外部；通过数字化的工具、电子看板、Dashboard的运用

富达国际敏捷教练环境中不断地发展。团队在敏捷项目中会遇到很多不确定因素，例如市场竞争、客户需求、产品设计和团队的现状。

有价值方面的基本定义，有价值的目标设定、评估基于多维度价值评估，有大部分团队形成端到端的企业形成动态的价值改进

团队领导通过管控成员影团队领导参与项目，采用团队领导以身作则践行敏大部分团队领导不仅以身企业内各部门领导层联动，

团队以职能型、矩阵型、敏捷团队初具规模，团队敏捷团队成员稳定，逐步大部分敏捷团队运转良好企业内形成大规模级敏捷

了解敏捷实践，并尝试一主动采取合适的敏捷实践，建立度量指标，有意识采大部分团队熟练运用大量企业内形成系统的敏捷实

被动采纳一些工具，支撑主动采纳各类工具，帮助团队建立工具链，获得度大部分团队从工具层面支企业内基于工具平台形成

团队中有成员兼职收集并团队中有成员，如产品负团队开始以用户故事管理大部分团队的用户故事遵循企业内产品管理团队基于

对质量有基础管理，例如每个项目有质量标准和规团队全角色具备质量意大部分团队具备全角色质量企业内敏捷质量管理不断

有初步的改进行为，还未团队基于已发生问题进行团队定期对工作方式进行大部分团队持续改进的活动随时随处改进的文化渗透

陈忠龚明杰黄浩李晖李宇航林伟丹林一荷卢建成梁堃孟美伶

瞿博文申健王立杰王伟王用涛王艳茹王抒音徐毅姚冬张志华

出品方老布谈敏捷联合出品

李进迪钟永林谢峥嵘 Lee.c 刘波曾忠群余知权Leo

尹建平韩正山李敏张良高英鑫王翔宇李鹏飞

陈雨卿魏冬曹凯伍舜喜吴言包鹏飞夏语

金可栋徐俊轩赵爽张俊赵苏宁苏湘伦李颖

侯守立李景鑫韩振峰唐文晟曾艳童飞穆晶晶

郑海源胡强刘晓峰李敏 Michelle 代燚朱博帆

产品管理项目管理测试管理 CI/CD