规模化敏捷-SoS（Scrum of Scrums）在某中台产研团队的协作实践

1967年，计算机程序员梅尔文·康威提出了一个想法，被后人称为“康威定律”：“Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations”。

我试图用蹩脚的英文翻译一下康威定律，即：组织沟通结构决定了系统设计。换句话说：你想要什么样的系统，就搭建什么样的团队。

Scrum是供单个团队用于开发、交付和持续支持复杂产品的一个框架。但是我们知道，Scrum指南所建议的敏捷团队不超过9人。当然我们都知道小团队作战的绝对优势及其好处，但随着组织与产品研发规模的扩大，许多公司都面临需要多个小团队共同合作来完成一个产品的研发交付。规模化敏捷的各种框架应运而生。

规模化敏捷，主流的框架包括Scrum @Scale ，LeSS，SAFe和DAD等。各种规模化敏捷的基础知识这里不做展开，关于它们各自的特点及使用场景，大家如有兴趣可以自行查阅资料。总体而言，决定使用哪种框架可以结合文章开头笔者提到的“康威定律”做出判断，即优先确定以后的系统设计，由此调整公司组织结构，再根据组织结构选择适当的框架。

酷家乐是一家面向未来的大家居全案设计平台及生态解决方案提供商，致力于为数字化升级提供一站式的解决方案。作为以技术优势筑建产品护城河的一家公司，产研团队颇具规模。以业务领域划分产品线，一些产品线在Scrum基础上，不断实践更能提高跨多个组协同效率的一些规模化敏捷的框架。本文结合酷家乐施工图中台部门的实操案例，重点介绍规模化敏捷Scrum@Scale中Scrum of Scrums的协作经验。

先简单科普下Scrum@Scale，根据Scrum@Scale指南中的定义：在此框架内，许多个相互关联的Scrum团队的运行与Scrum指南保持一致，这些团队可以协作解决复杂的适应问题，同时创造性地交付尽可能最高价值的产品。

*来源：Scrum@Scale®指南

Scrum@Scale有两个职能圈，Scrum Master职能圈和Product Owner职能圈，前者解决“怎么做”的问题，后者回答“做什么”的问题。SoS（Scrum of Scrums）就是来协调“怎么做”。

SoS确保团队之间有效沟通，以使每个团队的软件输出与其他团队的输出很好地集成在一起并交付客户，尤其是在工作重叠或时间顺序很重要的地方；同时，SoS也便于多个团队共同讨论并做出决策。

目前，酷家乐各研发团队的敏捷小组总体可分为以下三种类型：

每种形式各有利弊：

文中将介绍的中台产研团队-施工图，面向公司多个前台业务部门，并承接某领域的所有业务需求，需求量非常大，每个业务部门在某些模块的需求不相同但是都希望系统上能尽早实现。要实现资源利用的最大化，第三种敏捷小组划分形式无疑是最合适的选择。

我们的施工图中台研发团队，规模约30人，目前划分成了四个敏捷小组，每个敏捷组由7-8名产研人员组成，配备专业的PO、SM和开发团队，每个敏捷组按照合理比例分配前后端人员和测试人员，开发人员则按照工作经验形成梯度分布。

该团队最直观的，四个敏捷小组之间的协作活动是SoS会议。由各Scrum团队中派出主要代表参加，总体目标是使团队工作保持顺畅，并使总体交付成果保持在正常状态。

以下是我们SoS会议的主要内容：(一般时长控制在60mins)

SoS会议上将大的Feature任务划分到对应的敏捷组，前后端任务尽量安排在同一个敏捷组，特殊原因根据各敏捷组人力情况，也会拆分到不同敏捷组；每个敏捷组不会专职负责某些模块的任务，Sprint开始后，如果有需要，敏捷组也会进行任务置换或者新增紧急任务。

SoS绝不仅仅是在纯粹的Scrum框架之上，额外增加一个SoS会议而已这么简单。而是通过将不同的迭代活动与各种工件，分别以“共享”与“独立”两种方式来实现各小团队之间既能协同一致，又能保持独立运转的最大效率。

Product Backlog、版本（发布计划）、Sprint review会议，所有敏捷组共享：

施工图SoS中的四个敏捷小组，每个迭代有相同的迭代时间盒。我们都以两周为一个迭代周期，迭代周期内同时开始，同时结束，以相同的冲刺节奏共同的冲刺目标。大家像极了一群一起冲浪的人，随着一层层的波浪一起踏浪而行。

每个人对完成的理解不统一，有人觉得开发完成工作就完成了；有人觉得开发完成后需要完成下自测看看有没有问题；有人觉得需要交给测试人员完成测试才行算功能完成了。为了避免此类不同的认识，敏捷开发中用Definition of Done来统一定义完成的标准。我们施工图SoS中的四个敏捷小组，共同承接相同的业务领域，所以他们维护共同的完成定义。

发布计划由测试团队维护，测试人员根据公司的发布日规则，制定周期性的发布计划。每个发布周期内，分别会有一名测试人员和开发人员负责发布的相关事项，由测试人员和 开发人员都会轮值。测试轮值人员负责确认哪些内容进入本次发布，开发轮值人员负责release分支的创建，代码的合入检查。代码合入后，会共同部署SIT环境中集成测试，以检查各敏捷组的代码集成后是否存在冲突和问题，确保所有敏捷组的发布代码集成后功能可用，并且对原有功能不造成衰退。

*目前酷家乐自研的项目管理工具Kaptain支持版本在多敏捷组中共享，也支持敏捷组单独创建版本

SoS各敏捷小组每个迭代的工作产物和价值均会集成在一起交付客户，他们有共同的交付目标，维护共同的客户群体，所以Sprint Review会议一起进行。

每个迭代固定时间，由PO轮值组织，邀请所有敏捷组成员和内外部用户参与Review会议，PO演示此迭代周期内所有敏捷组完成的功能。

以下就是施工图团队一次review meeting的完整示例：

以下迭代活动，SoS中的四个敏捷组均独立进行：

综上所述可以看出，敏捷组共同对一个产品负责的情况下，SoS有利于规划统一 ，优先级一致，处理依赖协同。同时每个组又有自己独立的日常迭代运作，有轻量化更有效率，减少较大规模敏捷组的沟通链路太多造成的问题。

当然以上很多实践操作并非一成不变的规制，每个团队可以根据自身团队的情况进行检视调整不断改进，打造属于自己团队的最佳SoS实践。