规模化敏捷必须SAFe

引子： 规模化敏捷转型从来不是一件容易的事情。当只有1-2个敏捷团队进行协同的时候，计划和工作同步是可控的。团队和产品负责人互相聊一聊，基本就能搞清楚需要做什么，一个简单的SOS架构（Scrum of Scrums）就能搞定。

但是，当 涉及到多个团队 的时候，事情将会变得十分痛苦：

• 特别是如何让各个团队向着同一个方向前进而不是成为互相的羁绊；

• 如何在跨多个迭代、多个团队、多个产品的情况下进行计划和安排优先级；

• 如何让所有团队保持同样的交付节奏；

• 如何实现跨团队的持续集成；

• 如何解决团队间工作的依赖；

• 如何消除项目整体的风险；

• 如何防止需求的紧急搭车；

• 如何防止局部优化；

• 如何选择适合的协调人；

• 如何提高团队间开会的效率。

• ……

这些问题都需要解决。

同时， 规模化敏捷转型影响巨大，不仅仅要保证转型的效果，还要降低转型的各种风险，也就是说规模化敏捷必须是SAFe（安全的）。

但如何做到这一点呢？我们采访了一位资深敏捷实践从业者，看看他的现身说法：

Even， 现任某公司技术产品经理 10年+研发经验 曾任某银行内部敏捷与DevOps教练 DevOps广州社区核心组织者 POPM@SAFe

专注敏捷与DevOps, 热爱技术，专研产品与创新，自带正能量，喜欢结交有上进心的志朋好友，热衷分享并积极参与社区活动。

背景： Even所在公司，一个敏捷发布火车(ART)有十几个团队，一个PO一般带2个团队，他现在是其中的一个PO（你知道吗？人家以前还担任过Scrum Master呢，这华丽转型，是典型的斜杠青年啊！！）；

给大家来几张照片，看看人家的SAFe 实际场景。

图1 十几个团队同时开早会的场景，好壮观啊！！

图2 是开PI planning会议的场景，十几个团队的人一起做计划，挑战的不仅仅是公司有没有这么大的会议室，更是如何同步多人进行高效会议，幸好SAFe有标准的建议日程与形式。

1、你们在实施SAFe之前组织中遇到了哪些痛点？ 

痛点1：加人后感觉并没有增加生产力

因为是新的部门，在最近的一年中，都不断有新人加入，至少增加了几十个人，目前部门大概300多人，研发占7到8成吧，我们实行了1年多的SAFe，感觉在增加研发人数的过程中，好像并没有对交付产生实质的增产，由于一些原因，不是很方便公布数据，这个是否和SAFe或者敏捷有关，不得而知。

痛点2：我们是在追求epic的完成率吗？

从开始到现在，已经是第9个PI（program increment)了，除了前3个PI是适应期之外，后面的PI里，每个PI的完成率并没有实质性的提高，甚至有降低的情况出现，我们是在追求epic的完成率吗？为什么提出这个问题，因为我们是做平台的，可以比如是做阿里云平台，对于大型的平台型产品来说，我们交付的东西不能在一个sprint甚至是一个PI完成，这个是非常正常的事情，所以我们在反问自己，我们是在追求epic的完成率吗？

痛点3：前端与测试团队的划分问题

我们还有一帮做前端的同事，尝试过把他们分到一个团队，也尝试过把他们分到项目组，两种方式都不是很成功。由于我们是做平台的，并不是每个团队都需要前端，所以把他们分到团队并不是很成功，把他们单独组队，他们因为不能独自接feature来做，也不是很成功。这也算是一个痛点吧。对于测试团队来说，也有这样的问题，这两个团队都是半实半虚的。

2、众多大型敏捷选择SAFe的原因？ 

在我加入之前就已经跑了3个PI了，这个我从前辈处听说的是，他们选择的时候看到SAFe比较适合平台型的产品，因为我们是做平台的，有scrum, 有PI（大迭代），有发布火车，有PO和Product Manager,这些角色，看起来蛮适合的，至于是否对比过Less,我的了解是没有。你就当是凑巧选中了吧，恰好我们的北欧文化还是比较适合敏捷的，Spotify和Henrik就是北欧那边的:)

3、实施这个给您这个角色带来的变化和益处？ 

我本人以前的角色是TL，就当是SM吧，以前我们是跑Scrum的，当然我的项目是有界面font-end 那种，跑起来很顺畅，现在跑了一年的SAFe后，感觉SAFe是大型敏捷的救星，真的，为什么这么说呢？

1) SAFe有详细的落地细则。

Scrum里面的东西太空泛了，基本上没有教练教的话，可以说是五花八门，主要是它对3个角色是如何落地的没有非常详细的指引，而SAFe呢，它对每一个角色都有明确的定义，都有sample如何去落地，如果你能通过考试的话，可以说基本能掌握一个角色是如何执行的，但是scrum呢，那个考试被我喻为全世界最水的认证。

2) SAFe适合大型的敏捷团队。

我们的产品线刚好是几百人的团队，这在IT企业里面，可以说是非常常见的，但是scrum却不行，而且它的一个PI的定义也是很适合大型产品的开发，一个PI是10周的时间。没有了解过Less,上过DAD的培训，感觉DAD的方法论很吹水啊。

3) SAFe并没有抛弃scrum。

SAFe里面的小迭代仍然是采取scrum的形式，为有敏捷基础的企业的过渡提供了非常顺滑的铺垫。

4) SAFe设立的RTE角色非常像传统的项目经理（PM)的角色。

这为PM是否在敏捷中存在开辟了一条新的道路。

5) SAFe里面的CoP的概念。

为敏捷的实施提供了落地的土壤和传承。我们有SA的CoP，有PO的CoP,有前端团队的CoP，都为产品的演进、技术的修炼、敏捷文化的落地提供了很好的流程支持。

感谢Even的分享，非常非常棒！让我们对SAFe的信心更近了一步！！

其实，在SAFe 最新发布的4.6版本中，与时俱进，新增加了对企业DevOps能力的支持，因为对于多团队协作而言，没有持续交付DevOps的支撑，协作将会是非常痛苦的，发布速度也很难提升上去！所以， SAFe把“DevOps按需发布能力”作为精益企业的五大核心能力之一！