内容简介

本书基于规模化敏捷框架的完整结构，提纲挈领地介绍了其核心内容，同时给出了在企业环境中实施SAFe 的路线图。本书聚焦在提炼SAFe 4.0 版本的精粹，旨在帮助读者快速学习和了解理论，并掌握具体的实施步骤和方法，是指导SAFe 4.0 落地实施的****。　　本书适合IT 技术经理、项目经理、敏捷教练等阅读，以帮助他们成功进行SAFe 的实施；也适合企业中高层管理者阅读，以帮助他们成功构建基于SAFe 的精益- 敏捷企业。

作者简介

理查德·克纳斯特是SAFe 研究员、首席顾问、Scaled Agile 公司框架团队成员（该团队开发了SAFe 的新版本）。他在软件开发方面有超过25 年的工作经验，角色历经开发人员到高层领导，十多年来一直参与大规模敏捷转型。
迪恩·莱芬韦尔是全球公认的精益- 敏捷*佳实践**专家，他是一位作家、企业家，也是一位软件开发方法论专家。迪恩目前担任Scaled Agile 公司首席执行官和首席方法论专家，该公司于2011 年创立，他是联合创始人。
李建昊，企业级项目管理专家，敏捷教练，认证规模化敏捷培训师（SAFe Program Consultant），曾就职于朗讯科技(中国)有限公司贝尔实验室、诺基亚（中国）投资有限公司等，具备近10年大型通信工程、手机研发项目管理、过程改进的丰富项目经验。长期在大型跨国企业担任高级项目经理，基于战略层面进行多个研发项目、项目群管理、质量体系构建项目的管理工作。

目录

第1部分　概述1
第1章　SAFe的业务需要2
1．1　为什么业务需要SAFe 2
1．2　系统开发的挑战 2
1．3　应用新知识体系 4
1．4　提升系统开发的产出 7
1．5　SAFe的业务收益 7
1．6　总结 11
第2章　规模化敏捷框架（SAFe）概览 12
2．1　全景图 12
2．2　层级 14
2．3　基础 19
2．4　跨层级面板20
2．5　总结 22
第2部分　SAFe基础 23
第3章　精益-敏捷思维 24
3．1　概述 24
3．2　精益思想 25
3．3　拥抱敏捷 27
3．4　在规模化场景中应用敏捷宣言 31
3．5　总结 33
第4章　精益-敏捷领导者 35
4．1　体现精益-敏捷思维 36
4．2　引领变革 36
4．3　知晓方法，强调终身学习 40
4．4　发展员工 42
4．5　鼓舞士气和遵循使命，最小化约束 45
4．6　去中心化的决策 46
4．7　释放知识工作者的内在动力 46
4．8　演进开发经理角色 47
4．9　总结 50
第5章　SAFe原则52
5．1　为什么要聚焦在原则上 52
5．2　原则1――采取经济视角 53
5．3　原则2――运用系统思考 60
5．4　原则3――接受变异性，保持可选项 63
5．5　原则4――通过快速集成学习环，进行增量式构建 65
5．6　原则5――基于对可工作系统的客观评价设立里程碑 68
5．7　原则6――可视化和限制在制品，减少批次规模，
管理队列长度 69
5．8　原则7――应用节奏，通过跨领域计划进行同步 72
5．9　原则8――释放知识工作者的内在动力 75
5．10　原则9――去中心化的决策 77
5．11　总结 79
第3部分　项目群层和团队层 81
第6章　敏捷发布火车 82
6．1　概述 82
6．2　敏捷发布火车组织 83
6．3　按节奏开发，随时发布 86
6．4　愿景 89
6．5　特性 89
6．6　项目群待办事项列表 90
6．7　路线图 90
6．8　敏捷团队为火车提供动力 91
6．9　用户故事和团队待办事项列表 93
6．10　总结 96
第7章　计划项目群增量 98
7．1　概述 98
7．2　准备PI计划活动 99
7．3　第一天――创建和评审计划草案 102
7．4　第二天――形成最终计划和承诺 108
7．5　总结 116
第8章　执行项目群增量 117
8．1　概述 117
8．2　迭代周期 118
8．3　内建质量 122
8．4　用看板提升团队流动 125
8．5　管理ART流动 128
8．6　系统演示 134
8．7　创新与计划 134
8．8　检视和调整 136
8．9　总结 136
第9章　检视和调整 138
9．1　概述 138
9．2　PI系统演示 139
9．3　量化度量 139
9．4　回顾和问题解决工作坊 141
9．5　价值流层的检视和调整 144
9．6　总结 145
第4部分　价值流层 147
第10章　价值流概述 148
10．1　概述 148
10．2　经济框架 150
10．3　能力和价值流待办事项列表 152
10．4　价值流史诗 153
10．5　定义和构建解决方案 154
10．6　价值流的流动 155
10．7　总结 156
第11章　定义大型复杂解决方案 157
11．1　概述 157
11．2　解决方案 158
11．3　解决方案意图 159
11．4　固定和可变的解决方案意图 160
11．5　开发解决方案意图 161
11．6　记录解决方案意图 164
11．7　解决方案上下文 165
11．8　总结 168
第12章　协调敏捷发布火车和供应商 170
12．1　概述 170
12．2　价值流PI计划前会议 171
12．3　ART PI计划会议 173
12．4　价值流PI计划后会议 174
12．5　频繁的解决方案集成 177
12．6　价值流同步 178
12．7　解决方案演示 178
12．8　价值流检视和调整 179
12．9　总结 179
第5部分　投资组合层 181
第13章　投资组合层概述 182
13．1　概述 182
13．2　连接投资组合与业务 183
13．3　定义投资组合的战略主题 184
13．4　战略主题的影响 184
13．5　依据战略主题度量进展 185
13．6　投资组合角色 186
13．7　精益-敏捷项目群投资组合管理 188
13．8　用投资组合史诗推进解决方案行为 190
13．9　建立企业价值流动 192
13．10　协调价值流 195
13．11　总结 198
第14章　精益-敏捷预算、预测与合同 199
14．1　概述 199
14．2　精益-敏捷预算 199
14．3　精益-敏捷计划和预测 202
14．4　精益-敏捷合同 204
14．5　敏捷资本化策略 210
14．6　总结 213
第6部分　实施SAFe 215
第15章　指导联盟 216
15．1　概述 216
15．2　实施路线图 216
15．3　达到引爆点 218
15．4　需要一个强有力的指导联盟 219
15．5　培训精益-敏捷变革驱动者 219
15．6　培训企业高管、经理和主管 220
15．7　构建精益-敏捷卓越中心 221
15．8　总结 222
第16章　设计实施 223
16．1　概述 223
16．2　创建实施计划 228
16．3　总结 231
第17章　实施敏捷发布火车 232
17．1　概述 232
17．2　准备ART的启动232
17．3　培训团队和启动ART 238
17．4　ART快速启动法241
17．5　辅导ART的执行242
17．6　在价值流中启动更多的ART 243
17．7　在投资组合中启动更多的价值流 244
17．8　总结 245
第18章　保持和提升 247
18．1　概述 247
18．2　推进组织的成熟度建设 247
18．3　实施敏捷人力资源实践 251
18．4　度量和采取行动 252
18．5　提升敏捷架构和技术实践 254
18．6　专注于DevOps和持续交付 255
18．7　用价值流图缩短上市时间 256
18．8　总结 ．257
第19章　SAFe 精髓．259
19．1　概述 ．259
19．2　精益-敏捷原则 260
19．3　敏捷团队和发布火车 263
19．4　节奏和同步 264
19．5　基本的团队和项目群角色 267
19．6　PI计划 268
19．7　系统演示 269
19．8　检视和调整 270
19．9　IP迭代 271
19．10　DevOps流水线 272
19．11　精益-敏捷领导力 273
19．12　总结 275

前言/序言

推荐序一

正如万事万物的发展规律那样，敏捷在中国也并非坦途！特别是近几年，敏捷的进一步发展面临着巨大的挑战。

众所周知，敏捷是因为互联网的高速发展而大行其道的。但互联网行业的特点是小团队作战，哪怕是一个很大的互联网公司，也可以拆分成许多小团队并行工作。因此，互联网的敏捷其实就是小团队敏捷。互联网业内广为流传的“两个比萨原则”，说的是“两个比萨喂不饱的团队，就不能高效工作！”这是小团队敏捷快速迭代的形象写照！

其实，敏捷并不只属于互联网行业！但是，当敏捷在国内向更广阔的方向扩展时，却困难重重、举步维艰。

首先，敏捷在互联网行业的风靡，给人们留下了根深蒂固的印象，学敏捷就要学“BAT”（百度、阿里巴巴、腾讯）那样的敏捷！当然，“JMD”（京东、小米、滴滴）的敏捷也是一样的。似乎从来就只有“小敏捷”这华山一条路。

其次，互联网行业是一出生就“敏捷”了，不用经历敏捷转型的阵痛。而在其他领域，越是管理成熟的企业，越是有一套成型的组织结构和管理体系；越是大企业，层级越复杂，跨部门的协作越多。这些都让传统企业嫁接敏捷困难重重，往往只是在几个小团队浅浅地尝试一下敏捷就止步不前。

最后，我们在实施敏捷转型中还经常会提到“自组织团队、去中心组织”。这些新颖的概念也让企业的高层管理者们困惑、踟蹰不前，仿佛敏捷转型就是要“革了自己的命”。有朝一日，敏捷转型成功了，自己在企业里也就没有位置了。

放眼欧美，近年来，敏捷已经远远超出了小团队的范畴，在制造业、金融、航空航天等众多行业中，敏捷在几百人甚至数千人的研发团队里如火如荼地实施着，并有大量成功案例。“大规模敏捷”已经被美国财富 100 强公司中的绝大多数公司所接受，并有效地践行着。

这是一场“大敏捷”的革命，SAFe 就是这场革命的主要推手！

我在2017 年初给《SAFe 4.0 参考指南》写的推荐序里说，“中国的敏捷，非常需要一盏指路明灯。SAFe，恰恰就是这盏指路明灯，照亮了敏捷的前路！”

SAFe 规模化敏捷框架，为企业的敏捷转型升级提供了思路、指明了方向。SAFe 体系的创立者Dean Leffingwell 大师在IBM 有数十年IT 管理和咨询的经历，对大型IT 开发组织有深刻的了解。因此他提出的这套体系，与其他规模化敏捷体系相比，更深刻也更务实。就连“SAFe”这个名字，也会让企业在进行敏捷转型时感觉安全，让企业高管们心情舒畅。这，就是大师的智慧了！

2017 年4 月，我曾与本书作者之一Richard Knaster 先生深入交流。我们有共识，SAFe 必须走理论与实践相结合的道路。而本书恰恰给出了在企业环境中实施 SAFe 的路线图，它能帮助敏捷实践者们掌握SAFe 的具体实施步骤和方法，是指导规模化敏捷转型、SAFe 落地实施的最佳参考指南。

2016 年11 月，在“2016 光环敏捷千人峰会”上，光环国际作为SAI 金牌伙伴，隆重发布了SAFe 规模化敏捷框架中文版；2017 年初，《SAFe 4.0 参考指南》中文版出版、SAFe 中国社群成立；2017 年底，光环国际给华为做的SAFe 咨询第一期圆满完成。一年多来，SAFe 在国内的发展非常迅速，其正在被越来越多的企业关注，并准备着手将SAFe 纳入2018 年的年度计划之中。

这次，李建昊老师领衔翻译《SAFe 4.0 精粹：运用规模化敏捷框架实现精益软件与系统工程》，这无疑又是SAFe 在中国的一件大事。

衷心祝愿SAFe 在中国落地生根、开花结果！

张泽晖

光环国际董事长、CEO

推荐序二

我最早接触SAFe，还是在2013 年底。那时华为公司正在实施版本级敏捷和“One Track”，几百人的团队尝试进行迭代开发，活动本身取得了较大成果。但由于受到客户诉求及竞争压力，领导进一步提出要求：大幅缩短版本交付周期30%~50% 以上。而当时我们真正开展的敏捷实践还主要聚焦在基层团队层面，宏观上整个版本火车仍基于IPD“阶段- 门限”的瀑布交付模式。不突破这个框架束缚，产品上市时间（TTM）根本不可能做到突破性改进。但如何突破呢？让人颇为头疼。恰巧此时我看到了SAFe 框架，匆忙浏览一番，不禁眼前一亮，这正是我们想要的东西，真是“踏破铁鞋无觅处，得来全不费工夫”！

带着希望，2014 年我们远赴美国寻找答案。在Boulder，我们系统学习了SAFe 的整体框架与知识体系。整整一周的“填鸭”式学习，收获是满满的，但我们依然有困惑。课间“开小灶”的时候，我们几个人围着Dean，“我们交付的产品是嵌入式软件和硬件，软硬件协同怎么快速交付？”“交付范围很大，是多个产品组成的解决方案，成百上千人，依赖关系复杂得很，该怎么办？”Dean先是深思状，然后很兴奋地对我们说，SAFe 的下一个版本会考虑这些问题。显然，当时的SAFe 3.0 还无法应对这些问题。随着2017 年的到来，展现在我们眼前的这本《SAFe 4.0 精粹： 运用规模化敏捷框架实现精益软件与系统工程》（注：网站上已更新到SAFe 4.5 了）就对上述问题进行了系统回答。SAFe 4.0 整合了软件、硬件和固件，从Team 到Portfolio 四个层级，对大型组织的真实交付场景给出了切实可行的实施方案。

在我看来，从十来个人的小团队敏捷推广到成百上千人整个IPD 层面的敏捷，最核心的是要提升以下两个方面维度的敏捷能力。

（1）价值流敏捷性：我们称之为敏捷的“水平拓展”能力。核心是在“客户-产品管理- 架构与系统设计- 开发- 测试- 服务- 客户”这个价值链中，把敏捷影响的范围从传统小团队内的“开发- 测试”向前后两边延伸，最终打通“从客户中来、到客户中去”的完整价值链。这个过程，要不断卷入新的角色，不断调整和优化现有流程和组织职责，用更短的链条、更高效的协同和反馈加速价值的流动。在这种情况下，仅仅单个小组运作好，甚至独立的多个小组也运作好，依然不能有效解决问题。大企业中的每个角色和职责都是环环相扣的，只要有某个环节和角色没有搞定，价值就无法顺畅地流动起来。

（2）组织敏捷性：我们称之为敏捷的“垂直压缩”能力，管理扁平化能力。其核心是在“个人- 团队- 主管- 经理- 部长- 总裁”这种多层级的汇报和决策链条背景下，构建一个高效、快速的决策机制，从战略到执行，透明高效；从基层向上反馈信息，通畅，快捷。这都需要企业做到分层决策，组织扁平化，适度自治，权力和“炮火”授权到一线作战团队。而这种变化，更涉及组织的调整，以及不同层级决策范围和决策方式的变化。

（华为IPD 针对上述两个维度的敏捷性都有改进。实践表明，组织的敏捷性难度更大，但改进获得的收益也更大。）

让人可喜的是，SAFe 4.0 对上述问题都有阐述。框架在Scrum 的基础上，结合企业实践，创新性地提出了4 层结构，每层结构都引入了新的组织和角色，赋予新的技能要求和职责。其保证在企业大规模团队的交付过程中，不同层级团队间的信息共享、高效协同，以及无间配合与交付同步对齐。更让人叫绝的是其博采各家所长，创造性地提炼、总结出不少针对大团队作战的优秀实践。比如PI Planning，第一次见到时我感觉这完全是“脑洞大开”的神来之笔。上百人一起开会，而且还连开两天，所有交付的团队成员和利益相关者面对面地沟通愿景，制定目标和计划，识别依赖和风险，再加上超高密度的思想和信息碰撞，全员信心投票，所有这些真正做到了最扁平、最充分、高质量的全员沟通和反馈，聚焦了所有成员的精力和承诺，在一个PI 周期内为同一个目标冲刺。所以我一直认为PI Planning 体现了SAFe 的灵魂和精髓，“无PI Planning，不SAFe”！

另外，我观察到的一个方面是，SAFe 在4 层中引入的新角色的设置，无形中给SAFe 在大型企业实施过程中起到了部分消除障碍、铺平道路的作用。为什么这么说呢？大家都知道敏捷对企业是一个变革，而变革管理表面是组织和流程的优化，背后的核心其实是利益的再分配。在敏捷实施中，不少实践触动到了很多人的“蛋糕”。比如角色融合、去中心化、扁平管理、团队自治。这些口号让传统企业中的各级经理和功能领域大佬们焦虑不安，因为他们找不到自己在变革中的位置，所以自然在变革过程中保持距离，消极应付，口头承诺。这也是我认为Scrum 在企业做了好几年，影响力还是拓展不出去的原因。试想，能够决定路标规划的产品管理、决定重大技术方案的架构师、决定资源投入和版本策略的PMO（项目群管理）都不在Scrum 团队中，其影响力能有多大？反观SAFe 的方案，特别强调精益- 敏捷领导者的作用，而且或有心或无意，传统大型企业中的“各路大神”都能在SAFe 框架中或多或少地找到自己的影子，他们自然也乐得支持敏捷转型。企业也是江湖，团结就是力量。

当然了，SAFe 也不是万灵丹。事实上，在敏捷圈内的争论就不少。最大的抱怨就是SAFe 太复杂，甚至说SAFe 自身已经不敏捷了。SAFe 复杂吗？要我说绝对复杂！ SAFe 完全就是一个庞大的知识体系，单是引入PI Planning 就要花费不少精力。但这是问题吗？还是要回归业务的基本面，看企业的挑战是什么，并深刻分析复杂性是业务本身的属性还是SAFe 带来的。爱因斯坦说“事情应该力求简单，但不能过于简单（Everything must be made as simple as possible, but not simpler)”。所以我建议跳出问题，客观看待，学术之争不是关键，关键是解决企业的问题。Linus 说“Talk is cheap. Show me the code”。我要说，停下争论，回归本源！你的企业有问题吗？请参考书上的原则和方法，勇敢尝试吧，现在就开启你的第一列敏捷火车，让高效流动的业务价值来应对各种怀疑和挑战！

徐琦海

华为技术有限公司

产品与解决方案首席系统工程专家

推荐序三

Be SA

彩色的，很好

关于SAFe很不错的书！

此用户未填写评价内容

非常不错，值得收藏

买来学习用的

彩色的，很好

精粹很不错，值得阅读

SAFe is really safe?...

SAFe is really safe?...