规模化敏捷-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)
明确下一个Sprint可以做哪些内容，产品文档和技术文档都准备好了，如何分配给各个敏捷组，明确每个敏捷组的Sprint Goal（约40分钟）
提议下下个Sprint要做的内容，产品和研发都要进行议题，然后讨论确定要开始准备的内容 （约20分钟）
e.g. 产品提议5个内容，研发提议5个内容，一共10个，最终Battle到剩下6个排进去，其他的就进入Backlog中，所以产品和TO在周二的会上的一个会议议程就是准备好产品和研发的Backlog，好在SoS上进行讨论。
会议明确哪些内容需要准备产品设计文档并通过评审，哪些内容需要完成技术设计思路文档并通过评审。
SoS会议上将大的Feature任务划分到对应的敏捷组，前后端任务尽量安排在同一个敏捷组，特殊原因根据各敏捷组人力情况，也会拆分到不同敏捷组；每个敏捷组不会专职负责某些模块的任务，Sprint开始后，如果有需要，敏捷组也会进行任务置换或者新增紧急任务。
SoS绝不仅仅是在纯粹的Scrum框架之上，额外增加一个SoS会议而已这么简单。而是通过将不同的迭代活动与各种工件，分别以“共享”与“独立”两种方式来实现各小团队之间既能协同一致，又能保持独立运转的最大效率。
Product Backlog、版本（发布计划）、Sprint review会议，所有敏捷组共享：
同时冲刺—使用组织冲刺脉冲（Organizational Sprint Pulse），以相同的节奏和时间，同时迭代冲刺
举行共同的梳理产品待办列表（Product Backlog Refinement）活动
维护一份共同的完成定义（Definition of Done）
共同的Sprint Review会议
同时冲刺
施工图SoS中的四个敏捷小组，每个迭代有相同的迭代时间盒。我们都以两周为一个迭代周期，迭代周期内同时开始，同时结束，以相同的冲刺节奏共同的冲刺目标。大家像极了一群一起冲浪的人，随着一层层的波浪一起踏浪而行。
共同梳理产品待办列表（Product Backlog Refinement）
评审用户故事拆分的合理性
对当前列表的用户故事进行整体优先级排序，挑选出最高优需求，决定是否放入敏捷组下个迭代
讨论用户故事由哪个敏捷组承接
维护共同的完成定义（DoD）
每个人对完成的理解不统一，有人觉得开发完成工作就完成了；有人觉得开发完成后需要完成下自测看看有没有问题；有人觉得需要交给测试人员完成测试才行算功能完成了。为了避免此类不同的认识，敏捷开发中用Definition of Done来统一定义完成的标准。我们施工图SoS中的四个敏捷小组，共同承接相同的业务领域，所以他们维护共同的完成定义。
使用共同的发布计划（版本）
发布计划由测试团队维护，测试人员根据公司的发布日规则，制定周期性的发布计划。每个发布周期内，分别会有一名测试人员和开发人员负责发布的相关事项，由测试人员和 开发人员都会轮值。测试轮值人员负责确认哪些内容进入本次发布，开发轮值人员负责release分支的创建，代码的合入检查。代码合入后，会共同部署SIT环境中集成测试，以检查各敏捷组的代码集成后是否存在冲突和问题，确保所有敏捷组的发布代码集成后功能可用，并且对原有功能不造成衰退。
*目前酷家乐自研的项目管理工具Kaptain支持版本在多敏捷组中共享，也支持敏捷组单独创建版本
共同的Sprint Review会议
SoS各敏捷小组每个迭代的工作产物和价值均会集成在一起交付客户，他们有共同的交付目标，维护共同的客户群体，所以Sprint Review会议一起进行。
每个迭代固定时间，由PO轮值组织，邀请所有敏捷组成员和内外部用户参与Review会议，PO演示此迭代周期内所有敏捷组完成的功能。
以下就是施工图团队一次review meeting的完整示例：
以下迭代活动，SoS中的四个敏捷组均独立进行：
每日站会Daily Standup
迭代计划会议Planning
迭代回顾会议Retrospective
首先，这些活动本身具备在各个敏捷小组内独立运转的条件，与其他组的关联性与依赖性不大。
最重要的，主要目标还是为了提高效率，保持小团队战斗的高效。对Scrum了解的都知道，之所以提倡小团队作战，是因为当团队规模增大人数增加之后，其相应增加的沟通链路与信息传递路径是呈指数级上升的。而这种上升会极大程度上降低沟通效率，增加信息有效传递的壁垒。因此，SoS中各个敏捷小组保持主要日常迭代活动的独立性，也最大程度上保留了小团队独立运作的“轻便”与“敏捷”，提高了冲刺的爆发力。
综上所述可以看出，敏捷组共同对一个产品负责的情况下，SoS有利于规划统一 ，优先级一致，处理依赖协同。同时每个组又有自己独立的日常迭代运作，有轻量化更有效率，减少较大规模敏捷组的沟通链路太多造成的问题。
当然以上很多实践操作并非一成不变的规制，每个团队可以根据自身团队的情况进行检视调整不断改进，打造属于自己团队的最佳SoS实践。