本书基于规模化敏捷框架的完整结构,提纲挈领地介绍了其核心内容,同时给出了在企业环境中实施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
自从我开始接触组织转型的工作以来,我发现最大的阻力往往不是技术本身,而是思维模式的惯性。大家习惯于传统的瀑布式规划、固定的职能壁垒以及层层审批的流程,想要打破这种“路径依赖”,需要一个强有力的、被广泛认可的“新地图”。我阅读了市面上几本关于规模化敏捷的著作,但有些过于学术化,读起来像是在啃教科书,让人望而却步;另一些则过于偏向工具和技术栈的堆砌,缺乏对组织文化和领导力变革的深刻洞察。这本书的“精粹”二字,让我感受到了一种务实的承诺——它会直接告诉我“哪里是船的龙骨,哪里是风帆”。我尤其期待它在“系统工程”这个环节的阐述,因为在如今的产品中,软件与硬件、嵌入式系统和云服务的边界日益模糊,如何用敏捷的节奏去同步这些复杂的依赖关系,是决定项目成败的关键。如果这本书能提供一套清晰的跨层级、跨领域的集成和验证策略,那它对我们解决当前系统集成黑洞的帮助将是无可估量的。我希望它能揭示出,在规模化的场景下,如何保持精益创业的快速学习和适应能力,而不是陷入大型组织缓慢的决策泥潭。
评分坦白说,我对市面上所有标榜“全能解决方案”的书籍都抱有一丝谨慎的怀疑态度,因为现实世界的问题往往是复杂且充满变数的。然而,这本书的排版和视觉呈现方式给我留下了极佳的第一印象。全彩印刷,这一点在技术书籍中尤为重要,因为涉及流程图、依赖关系矩阵和价值流图时,清晰的颜色区分能够极大地降低认知负荷,帮助读者迅速抓住核心逻辑。我特别关注到书中关于“大规模敏捷发布计划(PI Planning)”的描述,这通常是组织转型中最具挑战性的环节,因为它要求所有相关方在短时间内达成共识并对未来十周的工作做出承诺。如果这本书能详细拆解出如何有效地引导这种高强度的协同会议,如何处理计划中的冲突和不确定性,并将其转化为可执行的Backlog,那么这本书的价值就远超一般理论读物了。我希望看到它如何将自顶向下的战略目标(如战略主题和能力)与自底向上的工程实践(如迭代开发和持续集成)进行有效的对齐和反馈循环,实现真正的上下贯通。
评分我最近参与了一个关于重构遗留系统的项目,深切体会到技术债务如果不及时处理,会如何扼杀组织未来的创新速度。因此,一本好的框架指南必须能够指导团队在追求速度的同时,不以牺牲质量为代价。我更倾向于那些强调“内在质量”和“持续改进文化”的敏捷实践。这本书的命名中包含了“精益软件与系统工程”,这让我相信它不会忽视工程卓越性的重要性。我期待书中能详细阐述在规模化下,如何确保持续集成/持续交付(CI/CD)管道的健壮性,以及如何通过DevOps文化来弥合开发与运维之间的鸿沟。在许多组织中,敏捷往往只停留在开发团队内部,而运维和基础设施的滞后成了最终交付的瓶颈。如果这本书能提供一个清晰的蓝图,说明如何将这些工程实践也纳入到敏捷发布增量(ART)的范畴内进行同步规划和度量,那么它将为我们解决“最后一英里”的交付难题提供至关重要的视角。这种对工程深度的坚持,是区分优秀敏捷框架与流于形式的敏捷实践的关键所在。
评分这本书的封面设计简洁有力,蓝白相间的色调给人一种专业而沉稳的感觉,尤其是封面上那一组精妙的流程图和架构示意,虽然只是预览,但已经让我对即将展开的系统化学习充满了期待。我一直在寻找一本能够清晰梳理出“大象是如何跳舞”的指南,尤其是在我们当前这种需要同时应对大规模复杂系统开发和快速市场响应需求的工程环境中。很多关于敏捷的探讨往往停留在团队层面,如何将这些原则有效地推广到跨职能、跨地域的数百人乃至上千人的组织中,始终是一个巨大的挑战。我希望这本书能提供一套可操作、可落地的框架,而不仅仅是高屋建瓴的理论口号。从这本书的标题来看,它似乎直指这个痛点,承诺提供一个“精粹”的视角,这意味着它应该剔除了冗余的叙述,直接聚焦于框架的核心价值流和组织结构调整的关键路径上。我特别关注它在如何平衡精益思想的“消除浪费”与规模化敏捷的“持续集成与交付”方面的论述,毕竟,在大型项目中,任何环节的微小效率损失都可能被放大成灾难性的延误。这本书的厚度和详尽的图示,预示着它不会仅仅停留在概念层面,而是会深入到具体的角色、会议和工件的管理细节中去,这对于我这种需要立即在实践中推行变革的管理者来说,是至关重要的参考价值所在。
评分我的团队目前正处于一个“摸着石头过河”的阶段,我们尝试吸收各种敏捷理念,但缺乏一个统一的“心智模型”来指导我们的决策。每当面临一个复杂的业务需求时,我们内部就会出现关于“优先级如何设定”、“依赖如何管理”、“风险如何评估”的争论,因为大家对框架的理解深度不同。我需要一本能够作为“事实标准”的参考书,让所有关键干系人——从高层管理者到一线工程师——都能在同一个术语体系下进行有效的沟通。这本书如果能够通过其清晰的结构和定义的工件,建立起这样一套共享的语言和流程,那么它的影响将是结构性的,而非局部的。我特别希望能深入理解它如何处理组织结构的转变——即从传统的职能部门转向以价值流为导向的跨职能团队。这种组织重塑涉及权力和责任的重新分配,需要非常谨慎和有力的指导。这本书的深度,应该能提供足够的信心,让我们在进行如此重大的组织架构调整时,有章可循,而不是盲目跟风。
评分精粹很不错,值得阅读
评分此用户未填写评价内容
评分买来学习用的
评分精粹很不错,值得阅读
评分买来学习用的
评分关于SAFe很不错的书!
评分买来学习用的
评分非常不错,值得收藏
评分非常不错,值得收藏
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 book.teaonline.club All Rights Reserved. 图书大百科 版权所有