引子:
规模化敏捷转型从来不是一件容易的事情。当只有1-2个敏捷团队进行协同的时候,计划和工作同步是可控的。团队和产品负责人互相聊一聊,基本就能搞清楚需要做什么,一个简单的SOS架构(Scrum of Scrums)就能搞定。
但是,当
涉及到多个团队
的时候,事情将会变得十分痛苦:
特别是如何让各个团队向着同一个方向前进而不是成为互相的羁绊;
如何在跨多个迭代、多个团队、多个产品的情况下进行计划和安排优先级;
如何让所有团队保持同样的交付节奏;
如何实现跨团队的持续集成;
如何解决团队间工作的依赖;
如何消除项目整体的风险;
如何防止需求的紧急搭车;
如何防止局部优化;
如何选择适合的协调人;
如何提高团队间开会的效率。
……
这些问题都需要解决。
同时,
规模化敏捷转型影响巨大,不仅仅要保证转型的效果,还要降低转型的各种风险,也就是说规模化敏捷必须是SAFe(安全的)。
但如何做到这一点呢?我们采访了一位资深敏捷实践从业者,看看他的现身说法:
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/911f5145eacdc0190db589b3d14336d5.jpeg)
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按需发布能力”作为精益企业的五大核心能力之一!