敏捷团队的典型规模一般在5～9人，然后一些传统企业的大型的软件，背后动辄需要上数百人协同开发，面对这样大型的项目，我们就不能使用敏捷了吗？今天给大家介绍一个轻量级的解决方案：Scrum Of Scrum（SoS）。它既可以保持小团队组织的灵活性；同时也可以在兼顾大型项目多团队在同一产品下的合作。

1.需求管理：

● 所有团队共享单一 Product Backlog

● PO 团队由于规模扩大，进行分层管理，采用 APO (Area PO) － OPO (Operational PO)方案

● 需求分层：Solution – Feature – Sub-Feature – User Story 四层结构（如果 feature 相对简单，没有Sub-Feature那一层） ，APO 负责 solution, feature 层， OPO 负责 feature, sub feature 与 user story

2.团队配置：

● 每个 Scrum 团队约7-9人，有1个 Scrum Master（兼任）。也有少数专职 Scrum Master 带2-3个团队

● 每个 OPO 专职对应2-3个 Scrum 团队

● SoS: 由于团队众多，因此在各个 Scrum 团队之上设置了 SoS. 通常在小规模组织中，我们只需要一个 SoS. 但在这个 case 中，我们事实上以 Area 为单位，设置了多个 SoS. 每个 Area 内的 Scrum 团队定期沟通

● 考虑到分布，尽量会由同一办公室的团队来共同开发某一 feature

● 为了协调管理，每个办公室设置了一名 Program Manager

3.会议与团队协作：

● 所有 OPO，APO 每周会有一个固定时间的会议，讨论需求的分配。在会议前，APO 之间会拆分大型的每个 PO 会同时处理多个 feature

● SoS 每周召开2~3次，原则上由 Program Manager 负责召集。同时有一个电子白板可视化各个团队的信息

4.技术实践

● 每个 Scrum 团队原则上可以修改任何代码。但是在实际操作过程中，这很难做到。我们的做法是每个团队会有 Primary，Secondary 的 domain. 一般是1-2个 Primary domain，2-3个 Secondary domain. 如果一个团队在某个 domain 是 primary，那么它可以自由修改这部分的代码。如果是 Secondary 的 domain，需要在修改前联络 Primary 的团队，进行方案的评审，并在修改提交前进行 code review

● 独立的 SWAT（Software Architecture Team）对总的架构负责，设计整体架构，对各个团队进行支持

● 分支策略经过了多次的调整，最后采用的是以下方案：

One Trunk + Toggle + Maintenance Trunk

同时鼓励每个团队每天进行持续集成（CI），不留代码过夜

● 自动化测试体系：包括单元测试，功能测试，集成测试，系统测试，UAT 等等，整体的自动化测试（除 UAT）外，超过了90%

● 其他技术实践包括代码走查，结对编程（少量团队尝试）等等 。这些实践可以明显提升产品质量，同时也加速团队学习