规模化敏捷框架SAFe，怎么玩才叫爽？ | 第6期 - 《践行者》

引发争议的SAFe究竟是一个怎样的存在？对于大规模组织来说，SAFe又有什么制胜法宝？本期《践行者》，让我们和徐陈飞老师一起，拨开SAFe身上的重重迷雾，揭开SAFe的神秘面纱！

一、《践行者》系列直播回放

《践行者》是一档主打实战落地的访谈栏目，旨在通过对研发实践、项目管理实践践行者的访谈，帮助大家了解到项目管理的实践及其实际应用场景；通过践行者本人的心路历程向大家展示更加生动真实的实践落地过程。

目前《践行者》已先后进行了六期直播，往期直播回放可以戳上方视频观看~

二、那些与SAFe一起走过的日子

徐陈飞老师首先从宏观层面对SAFe做出了解释：大家可以将SAFe看为一个融合诸多项目管理实践的实践库。作为一个规模化敏捷框架，SAFe能帮助大家从企业级的角度来看敏捷，通过研发敏捷、业务敏捷实现组织敏捷，最终实现业务增长与企业发展。

而SAFe的实践可以分为管理实践和工程实践，管理实践又分为团队级与组织级（多团队级）……好像看起来很复杂，但如果将SAFe平面化，就会发现SAFe涉及到的主要是团队级与多团队级的概念，多团队可以看作大型的产品级概念。

有了这个认知，大家会发现SAFe好像也没那么复杂。接下应该如何应用SAFe的实践呢？这取决于组织的复杂度：需要先分析清楚自己的组织要用到SAFe的哪一部分，然后再从SAFe中拿到适合自己组织的实践。虽然SAFe框架包含的内容很多，但大家可以灵活拿用，这就是SAFe灵活性的体现。

接着，徐老师又从“何时考虑使用SAFe”以及“如何应用SAFe的具体实践（PI Planning、敏捷发布火车）”入手，帮助大家深入了解了SAFe。

最后，徐老师给大家分享了应用SAFe的3个锦囊妙计：

清晰地识别团队：需要从价值流的角度来识别团队。如果我们没有做好团队的划分，可能出现多个划分好的敏捷团队之间耦合度很高的情况，导致团队实际运作的能效远低于你所期望的能效。
做好Pre-PI Planning：在做PI Planning之前，前置的准备工作一定要做扎实。明确定义好前置项的准入准出条件。
规范化：要想在组织内将SAFe快速跑起来，就要定义清楚团队、角色、流程、输出物以及标准，在整个流程中产出成文的内容，消除团队焦虑。

除此之外还有徐陈飞老师关于SAFe的其他干货分享，欢迎大家扫描上方二维码观看直播回放~

三、问答实录

话不多说，来看看这次的问答实录有没有解决大家的疑问呢？

Q1：考Leading SAFe有什么锦囊妙计吗？

A: 首先给大家推荐一个我常用的网站，可以通过各种卡片来进行学习：https://quizlet.com/713770746/leading-safe-flash-cards

其次，一般在正式SAFe的考试前会有practice test，我们需要在practice test中确保自己考到95分以上。再就是需要把整个SAFe框架全部看一遍，知道需要的内容在哪里，大概率就过了。

Q2：SPC（SAFe® Program Consultants）值得学吗？

A: SPC值得学。首先看出发点是什么，如果我们希望改变组织但目前缺乏工具箱的话，那SPC能为你提供一套比较完整的工具箱。另外，SPC内有很多新的认证、课程，我们通过自学也可以学到很多干货，尤其推荐大家学其中的《敏捷软件工程》课程，非常有用。

Q3：考Leading SAFe的价格是多少呢？

A: 官方价格是7000+，包含了考试费。如果没考过的话要交150美金重考，不过考试的通过率挺高的，大多数人会一次通过。

Q4：想自己学习了解一下SAFe，有没有相关学习资源？

A: SAFe官网里面的知识及相关文章非常全。还有一个小诀窍是看完其中的某篇文章后要拉到最底部，底部的reference中会标有相关参考资料、论文出处、书籍推荐。大家可以在里面去找真正的学术性的内容。

Q5：人少的话会推荐Essential SAFe吗？优势在哪里呢？

A: Essential SAFe也适配多团队运作。其实并不是因为人数的多少决定能否使用Essential SAFe，而是根据组织层级以及需求层级来决定需要哪一种实践。

Q6：什么情况下可以使用SAFe？

A: 如果组织想要快速落地并能运转起来，其实很推荐大家用SAFe，包括PI Planning可以作为流程中的一个必要环节而存在。

其实讲PI Planning中背景信息的对齐与同步，我们可以不用想得太复杂。就比如我们每个季度，是不是应该停下来想一想，思考一下接下来我们怎么走。而在这个基础上，SAFe也能提供一些即拿即用的实践来帮大家做好项目管理。那这样何乐而不为呢？

Q7：SAFe有最佳实践吗？有没有国内国际比较好的案例？

A: SAFe最核心的内容是PI Planning。国内像上汽大众、沃尔沃、吉利、飞利浦都在搞SAFe，国外的汇丰银行也在跑SAFe。大家可以参加一下SAFe Day规模化敏捷大会，会专门介绍一些在做SAFe的公司案例。其中这些公司趋同的一点是组织都比较大。

现在我们组织内部也在追求最开始借鉴SAFe的框架，然后逐渐跑出自己的节奏感，形成自己的体系。

Q8：可以分享如何用系统思维推导SAFe的方法吗？有没有资料、书籍推荐呢？

A: 如果具有英语阅读能力的话，推荐通过直接搜索“系统思考”来阅读早期的相关论文。通过读论文来了解系统思考是什么、因果图是什么以及如何进行推论，然后逐渐代入自己的组织，看看组织的环境变量是什么，有没有必要跑PI Planning等等。这其实是一个比较好的学习思路。

Q9：SAFe落地过程中一般是完全套用还是根据实际来裁剪（当知识库工具箱来用）？

A: 曾经一位拥有SAFe Fellow头衔的专家来中国做了一次分享，其中的一个观点现在也分享给大家：裁剪可以，但如果将PI Planning也裁掉，那就不叫SAFe了。

Q10：想了解SAFe框架如何实现内建质量？

A: 首先推荐大家学一下相关课程。在SAFe中，是通过两部分来定义内建质量的：一个是在流水线上加入自动化测试工具、流水线节点，以及进行测试左移等等，来实现内建质量；第二个是通过DevOps来实现内建质量。

同时在SAFe官网中有一篇专门写内建质量的文章，大家可以了解一下。

Q11：企业本身的文化如果和敏捷或SAFe价值观差别比较大，会不会对现有项目产生很大影响？应该如何平衡呢？

A: 问题的关键在于你们是站在什么角度做敏捷。如果本身跟敏捷的理念差别很大的话，还要去跑规模化敏捷，这就是组织级的事情。需要反过来和领导确认，我们为什么要做敏捷。如果得到的答案是想做研发标准化，那这件事本身和敏捷无关，无非是套了SAFe的壳子做研发标准化。

导入SAFe应该是中高层先接受Leading SAFe的培训、工作坊，然后接着是团队级的导入。这样的话，所有人的对话方式、价值观是保持趋同的，这样我们再去做事情的时候，就不会产生巨大反差，这个非常关键。

Q12：在SAFe中，质量控制的重要控制点在哪里？

A: 首先SAFe并不是一个质量控制框架，但SAFe最大的优点就是集合行业内的优势力量，对于质量控制SAFe提供的方法论有(built-in quality)质量内建，在质量内建中提供了内建质量的5个维度（Flow，Architecture&Design Quality，Code Quality，System Quality，Release Quality）。

重要控制点我只能结合自己经验来说：一般我们应该在代码提交前就不断采用质量左移的策略来执行质量控制，要关注设计质量、代码质量，进入代码提交后，要关注pipeline质量检查（如果你的pipeline检查不到任何问题，这本身就会是一个问题），最后不得不提的是，质量是团队每个人的责任，一定不能归结于某一个团队没有把好关引发的缺陷逃逸。

Q13：感觉PM转SM更难。

A: PM与SM有一些本质上的不同：一个偏向于命令式管理，一个更偏向于引导和激发团队活力。

那么我们实际在实践的时候，通常会引导PM去逐步地采用一些SM的技巧做出一些改变。改变一定不是一瞬间的，潜移默化地做出一些改变，团队是能感觉到的。

在改变的过程中，PM转SM是不是更难本身这个问题就已经不那么难了。很多组织里，PM是一个岗位，但SM就是一个角色，成熟组织内SM是一个固定岗位。

Q14：老师推荐找哪一类潜质的Scrum Master呢？

A: 这个话题我很擅长。第一是硬核实力够不够，什么是硬核，硬核能力就是知识+经验。换句话说，实战过的行业经验（决定是否能和团队说同一种语言）、技术经验能否正确理解大家的想法、管理经验（能够抗压的能力）；第二就是软技能，是否有过说服别人改变某种习惯的经验/经历，是否在持续学习（近期读书、写博文、社区交流）；第三是健谈，对事物充满好奇心（我们并不完全需要SM是一个滔滔不绝的人，但我们需要SM是一个对事物充满好奇心的人，这足以证明此人有一定的求知欲）。

Q15：需要给Scrum Team成员培训SAFe敏捷框架，让他们了解团队运行机制吗？

A: 可以参考SAFe的转型路线图，当然回答是肯定的。让团队和中高层保持同一种对话方式，用同一种语言甚至词汇是非常有必要的。价值观一致是一个漫长的过程，敏捷转型中价值观最终应该趋同。

团队共同理解运行机制更是必要的，我们一般会定义playbook、框架流程、培训团队、考核流程机制，只有充分学习才能够齐头并进、共同进步。

另外，敏捷转型是一个集体学习的过程，很多初期的不适应、不理解，大多来源于“不知道、为什么”以及缺乏知识经验的积累导致的。所以培训是必不可少的。

Q16：PI Planning和大的里程碑是不是差不多？

A: SAFe的确在里程碑的问题上写了一篇文章，明确定义了一下SAFe对于以下三类里程碑的定义：

PI作为里程碑；
固定时间日期的里程碑，这个是说对于特定日期的里程碑定义（例如：外部系统对接、外部市场活动等等）；
学习反馈的里程碑。

Q17：一个季度做一次PI Planning，不可能每个迭代都能正常交付，如果出现对整个PI Planning的影响时，如何调整原PI Planning的方案呢？

A: 这个问题我做过很多次的统计，每个PI Planning结束后，我们都会产出一份报告来给各层级管理者呈现：我们在哪些功能模块的投入分布，一个PI Planning以后，实际完成的PI Objectives有多少，新增的（也就是你所提到的变化的部分）PI Objectives有多少……

一般一个季度下来，会有一定比率的之前PI Planning中定义的任务会产生变化，而变化率在各业务线的分布可以作为一个很好的参考，说明下一个季度应该做怎样的计划。

Q18：有的团队只是要配合做一部分工作，但是这个团队本身的工作任务也很重，在实际工作中如何保证该团队能按时完成配合工作？

A: 这个问题其实应该不属于SAFe框架管理的范畴，我结合我们实践可以分享给你我们是怎么做的。

我们让每个团队展示出来可以为其他团队提供的服务内容，那么谁要麻烦哪个团队做什么可以一目了然，且我们要求每个团队麻烦别人的话，请带着小卡片（任务或者故事）去明确地告知对方团队要支持什么，接受方团队也会对此给出估算，在计划会议当天给出排期计划。至于比例问题，这个是没有确定的，看各团队的实际可承接范围来定比较好。

Q19：多个火车会同时开PI Planning吗？会后，不同火车会开Post-PI Planning吗，一般会有哪些人参与？

A: 这个问题有点高度，我在这里抛开SAFe怎么定义的不说，直接说说实际我们是怎么实践的：我们目前的组织也是有名义上的solution train的，但是我们的PI Planning是根据ART分开做的，因为考虑ART与ART之间相关性的强弱不同，因此我们最多在PI Planning Day1时候，邀请到相关ART的负责人来参与到我们Day1讲解和Day2呈现中，一定程度上分治会更容易执行，对大家的适应力也会更好。

Q20：业务调研会调研完产生需求文档让业务签字吗，如何解决中途变化大且项目deadline临近的问题？

A: 签字这个问题也不是SAFe的范畴，但是我们的确也有，不够我们主推的形式从签字在做转变。

因为SAFe中间有提到过，feature的价值会随着时间的推移而递减，这个概念非常切合实际情况。因此我们实践中，是锁定一个需求文档的基线，然后允许在迭代中继续增减需求，从而达到最优化的效果。签字那种本质仍然属于计划驱动的范畴，因为需求可以被一定程度确定，但是越接近C端市场的需求，签字效用越小。小程序类型的话，签字这点来回的时间，活动都做了1-2个了。对于某些大型需求，类似于结算、订单、财务、软硬件部分等等类似的情况下，签字还是很有必要的。所以其实是要分段来讨论的。

再说回签字，我们用签字来锁定一个基线，同时留给业务空间，让他们可以继续增减需求，何乐不为呢？所谓的deadline可以用Release Plan来代替，对等于这次发布我们锁定哪些内容，其余的我们可以留给下一个发布窗口。是不是这样会更有条理一些呢？

规模化敏捷框架SAFe，怎么玩才叫爽？ | 第6期