研发效能认证学员作品:概述规模化敏捷之SOS架构丨IDCF

2023-12-27 13:55:12

作者:黎朝添? 研发效能(DevOps)工程师(中级)认证 学员

社会进入工业4.0时代,众多企业从过去传统的 “制造能力” 转变成 “制造能力 + 数字化能力”。

一方面企业为了提高内部的管理运营效率及质量,从端到端全价值链进行相应的精益变革,提供信息化和数字化工具以支撑企业的高效运营活动。

另一方面企业的软件互联产品需要及时响应快速变化的市场需求,而市场竞争中,企业只有将自己的产品在性能上优于竞品,或者在产品性能类似的情况下,企业的生产成本低于对手的成本,才有可能在残酷的市场中生存。换言之,企业需要快速响应用户,创造用户价值,留存用户,并在产业链上引入精益思想,消除“端到端”过程中的作业浪费,才能从根本上提升企业的竞争力。

相比于传统的瀑布式软件开发,使用轻量级敏捷开发框架(如Scrum、XP、kanban等)开发在响应需求变化、快速交付价值方面有天然的优势,敏捷核心理念是客户价值驱动,拥抱变化,快速交付价值。轻量级的敏捷框架适用于十人以下的小型团队,这是为了快速响应,高效沟通,但是大于十人的团队使用敏捷框架作业,在沟通成本和沟通效率上并不占优势,而且随着敏捷团队成员的增加,团队的沟通成本呈几何式倍增,因此一个轻量型敏捷框架不适合支撑几十上百人的团队。但一款流行或拥有广泛用户的产品,往往是一款大型而复杂的产品,此类产品需要多个团队协同,几十甚至上百的人员支撑,显然单个敏捷框架在人员数量较多的团队中疲态尽显。

为应对大型产品,以及高昂的沟通成本,我们引入规模化敏捷的概念。规模化敏捷,简而言之就是由多个小型敏捷团队为了同一个目标而协同作战。规模化敏捷的底层逻辑仍然是轻量型敏捷框架,介绍规模化敏捷之前,先简单介绍Scrum框架。

图片

如上图所示,Scrum框架有三个重要角色,分别为:产品负责人(PO)、敏捷教练(Scrum Master)、敏捷团队,每个角色有分工明确又相互交互。

而Scrum框架的业务流程从左边流向右边,依次产生的会议有:产品梳理会,冲刺计划会(也称迭代冲刺会),每日站会,冲刺评审会(也称迭代评审会),冲刺回顾会(也称迭代回顾会)。

Scrum框架的基本流程介绍完毕,下面我们看规模化敏捷之SOS架构。

?SOS架构英文全称为Scrum of Scrums,旨在解决团队协作与沟通问题。底层逻辑基于Scrum框架,遵循Scrum的研发流程和敏捷开发的十二原则。其模型有四:

1+1+2N?模型

图片

如上图所示,1+1+2N 模型的释义为

  • 1:一名PO

  • 1:一份Product backlog

  • 2N: 给N个敏捷团队(团队成员5至9名)各自配备1名敏捷教练

一名PO维护一份Product Backlog,N个敏捷团队共用一份Product backlog,每位敏捷教练(Scrum Master)负责维护指导各自团队的敏捷实践,团队之间的信息同步由SOS会议完成(SOS会议,频次为一周2~3次,旨在解决团队之间的需求依赖,共享进度信息)。

业务流程:

  • 产品PBL梳理会

?此会议通常发生在一个Sprint中间或者一个全新项目启动之前,旨在梳理下一次冲刺迭代需要完成的需求,由PO牵头负责,各团队成员按需参与(团队成员参与的时长不超过本次迭代时间盒的10%),会议可能是一次会议,也有可能是多个零碎会议,会议输出一份已排好优先级的Product Backlog(简称PBL列表)。

此模型与单团队的产品梳理会之间的差异:

(1)PO有可能同时和几个团队的队员讨论需求,而单团队的PO只需要和一个团队的成员讨论需求,因此,此模型的产品梳理会对PO的业务能力要求较高。

(2)此模型下的PO需要初步评估每个需求的大小,并对每个需求之间的依赖关系进行梳理,将有较强依赖关系的需求整合在一起,降低需求之间的依赖关系,方便各团队间协同作业。单团队的产品梳理会,由于所有的需求都是由同一个团队处理,需求之间的不存在外部团队的依赖关系,因此,需求的依赖关系可由团队成员整合。

  • 迭代计划会

此会议分为上下半场,旨在让各团队成员清晰本次迭代的目标,并让各团队从已排好优先级的Product Backlog中认领各自团队的需求任务。

上半场所有团队成员都需要参加,由PO讲解产品目标,明确需求的优先级和各需求之间的依赖关系,并确认验收标准。会后由各自的敏捷教练上前认领任务需求,也可由团队成员推举一位代表上前认领。

下半场由敏捷团队成员分解已认领的任务需求,明确已认领的需求与其他团队认领的需求之间的依赖关系,并与有需求依赖关系的团队明确SOS会议的时间、地点、频次;各团队同时要与PO约定好本次的迭代内容以及完成的标准。

此模型与单团队的迭代计划会之间的差异:

(1)规模不同。此模型下的迭代计划会议的参与人数是单团队的N倍。

(2)会议时长不同。单团队的迭代会议时长基本在一天以内,此模型下的会议时长,有可能持续2至3天,具体时长根据团队数量而定,团队数量越多,需求越多,会议议程也就越长。

(3)依赖关系不同,单团队的迭代计划会议主要是识别团队内部的需求依赖,而此模型下,不但要识别团队内部的需求依赖,还需要着重识别团队外部的需求依赖,并且要优先处理外部团队的依赖。

  • 迭代评审会

此会议旨在对产品交付的检查和调整,通常形式为演示+验收,在各团队演示期间,PO对交付的成果有一票否决权。会议发生在冲刺迭代结束后,参会者为全体团队成员,同时也可邀请各相关方与会。

此模型与单团队的迭代评审会之间的差异:

(1)规模不同。此模型下的迭代评审会的参与人数是单团队的N倍。

(2)会议时长不同。单团队的迭代会议时长基本在半天以内,在此模型下,PO需求对各团队的交付物进行验收,因此会议时长,有可能持续一整天,具体时长据团队规模、迭代周期而定。

  • 迭代回顾会

此会议分为两个,一个为团队内部的回顾会,另一个为各团队之间的回顾会。此会议旨在对迭代流程的检查和调整,梳理出团队优势以及改进点,好的方面持续保持,需改进之处,不断完善;持续调整整个团队的流程,让团队保持相当的战斗力。

其中内部回顾会,由团队成员全部参与,PO可选择参与,团队之间的回顾会,由团队代表或者敏捷教练参与。

此模型与单团队的迭代回顾会之间的差异:

(1)类型不同。单团队在每个迭代周期只召开一次迭代回顾会,此模型下,需要召开两次,一次是团队内部的回顾会,旨在提升队员的个人能力,团员之间的协调配合以及改进持续交付的流程;另一次是团队之间的回顾会,旨在改进团队之间的协调配合以及信息共享等问题。

(2)广度不同。单团队的知识技能仅来源于团队内部,但在此模型下,各团队的优良作风,技能技巧都可以通过迭代回顾会议进行共享,每个团队都能够引进其他团队的长处,弥补自己的不足,同时也能打破团队壁垒,促进团队之间交流,为企业营造浓厚的敏捷氛围。

此模型的规模化敏捷适用于企业的PO资源不充沛的情况下,并同时存在以下缺点:

1)此模型只能支撑50人以下的团队规模。一名PO能支撑3至5个团队,一旦团队数量过多,则PO乏力。

2)团队对未来的任务缺失方向感。团队不清楚未来的工作任务,只有将任务认领了才清楚将来的工作任务,因此不利于团队提前做知识储备。

1+3N模型

图片

如上图所示,1+3N 模型的释义为

  • 1:一名PO

  • 3N: 给N个敏捷团队(团队成员5至9名)各自配备1名敏捷教练,N份Product Backlog,一名PO为每个敏捷团队维护一份Product Backlog。

此模型的工作流程和性质与“1+1+2N”模型类似,不同点在于团队的任务需求是由PO直接下发,而非各自团队自愿认领;

此模型同样适用于企业的PO资源不充沛的情况,虽然解决了“1+1+2N”模型下敏捷团队方向感缺失问题,但同时也存在以下问题:

1)一名PO同时维护N份Product Backlog,PO在管理上的复杂度会大大增加,并且PO经常需要在各个团队之间流转,有时难免会分身乏力,团队的生产力就有可能出现“等待”的浪费。

2)在迭代计划会议中,PO需要对PBL逐份讲解,参会的团队需要耐心听PO讲解其他团队的PBL,因此会经常性出现“等待”的浪费。

1+4N模型

图片

如上图所示,1+4N 模型的释义为:

  • 1:新增配置一名APO,APO负责维护一份更宏观的Product Backlog,并将宏观的任务需求下发给每个团队的PO,同时由APO负责协调各团队之间的协同以及依赖关系。

  • 4N: 给N个敏捷团队(团队成员5至9名)各自配备1名敏捷教练和1名PO,每位PO各自维护1份Product Backlog。

此模型适用于企业的PO资源较充沛的情况下,既消除了团队的方向感问题,也大大减轻了PO的压力,而且每个团队都有三个名完整的角色(PO、SM、TEAM), “等待”的浪费问题也得到了改善。需要注意的是,在此模型下,各团队的PO应在迭代计划会召开之前,据情况召开一次PO会议,以明确各自团队之间的依赖,确认依赖的整合时间。

以上三种模型基本可以解决几十人的协同作业,假如需要协同上百人的协同作业,以上的三种模型并不能满足,此时需要第四种模型:多层SOS架构。

多层SOS架构

图片

多层SOS架构,可以解决上百人至数百人的协同作业问题。流程与前三种模型类似,需要注意的问题是,多层SOS架构的需求来源和优先级问题由各层级的PO协同解决;在需求实现上或者业务上,通常由SM或者团队代表去参加各层级之间的业务沟通,把业务上需要协调解决的依赖问题或者解决方案准确带回团队,再由团队一起执行。需要明确的是,组织层级越多,需求间依赖关系会越复杂,沟通出错率也会更高,一旦某个环节出现延误,造成的影响将是组织级的。因此,PO在需求层面要竭力进行解耦,极力降低各团队或者各层级之间的需求耦合度。

根据上述的四种模型,其实不难看出,规模化敏捷的底层逻辑还是基于轻量级敏捷框架,也由此得出:

1.企业想要在其内部推行规模化敏捷,成功与否取决于企业的整体敏捷水平,若企业的整体敏捷水平较低,强行推行规模化敏捷,其成功率必然不高,也有可能得不偿失。

2.规模化敏捷,有一个异常重要的会议——冲刺计划会议。此会议有几十上百号人同时参会,因此,如何高效,有序地召开冲刺计划会议是冲刺成功与否的前提。

参考:

[1]?什么是 Scrum?| https://www.scrum.org/learning-series/what-is-scrum/the-scrum-team

[2]?大规模敏捷团队,Sprint评审会怎么开?https://www.scrum.cn/scrum/35342.html

[3] SOS实践|?http://www.pmquanzi.com/articlDetails/1293.html

[4]《持续交付》(作者:Jez Humble / David Farley)

[5]《Scrum精髓》(作者:Kenneth S.Rubin)

文章来源:https://blog.csdn.net/m0_69584846/article/details/135239523
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。