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

作者:黎朝添? 研发效能（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）