---

如何扩展 Scrum 框架（分布式与大型 Scrum 项目）？答案可能让您惊讶！

到目前为止介绍的 Scrum 框架，最适合在同一地点工作的单个 Scrum 团队。 但现实中，一个 Scrum 团队常常无法独立实施整个项目，或者成员必须分布在多个地点。

当一个团队无法满足产品需要时，组织可以考虑增加团队。仅仅地理分散，并不意味着必须增加团队；增加人员也可能提高协调成本。 我们还经常看到，这些团队分布在相距遥远的地区，甚至不同大洲。

组织将团队分布到不同地点，有多种原因：

• 技术原因： 构建软件某些独立组件所需的知识，在总部所在地无法获得；
• 专业能力原因： 开展某些软件工程活动的能力在本地无法获得。例如，测试自动化、用户界面设计，或内部软件与其他供应商软件的集成，可能需要总部以外的专家；
• 规模原因： 为了在预定期限内向客户交付，项目需要更多人员，人数超过单个 Scrum 团队的合理容量。这时可能需要多个紧密协作的 Scrum 团队，而不是无限扩大一个团队；
• 业务原因： 使用成本较低地区的人力资源，或利用不同时区的工程师保持工作连续性，都可能具有合理商业价值。

沟通是 Scrum 框架不可或缺的一部分，所有成员都应重视克服分布式项目环境中的工作挑战。 此外，所有成员都应能使用沟通工具，包括音视频会议和屏幕共享工具。

常用项目管理工具有助于团队保持良好、持续的沟通，包括产品待办列表、Sprint 待办列表、事件清单、知识与新闻共享工具等。

项目组织：多个团队

在更大规模项目中扩展 Scrum 框架，最简单的方法是在同一地点增加团队数量。

如果需要多个团队协作实施项目，最好逐步增加团队数量。

这对您意味着什么？

同一地点的多个团队

对大多数组织而言，逐步增长比一次成立十个新团队更容易管理。最佳实践是从一个 Scrum 团队开始。经过几轮成功的 Sprint，再让一到两个团队加入项目。确认这些 Scrum 团队（更多内容请参阅 多个 Scrum 团队）能够良好合作后，您就可以继续为分布式项目组织增加团队。

增加团队数量

创建新 Scrum 团队通常有两种方式：

• 将现有 Scrum 团队拆成多个团队，并在需要的地方和时间加入新成员；
• 由此前完全未参与该项目的其他工程师，组建新的 Scrum 团队。

拆分现有团队的优势在于，可以发挥已有成员的知识，以及他们在当前项目中的经验。

因此，新团队一成立，通常就具备一定生产力。主要缺点是，一个已经运作良好的 Scrum 团队被拆成两个团队，这可能影响成员积极性。 尤其是高层没有提前宣布并说明原因，成员在心理和技术上也尚未准备好时。

增加全新团队时，现有团队可以保留原有结构，继续开展 Sprint。不过，仍须关注与新团队的协调、入职引导和集成。完全新建的 Scrum 团队，需要更长时间积累必要知识、形成推进势头并提升产能。

无论采用哪种方式为组织增加 Scrum 团队，都请牢记以下原则：

• 从少量 Scrum 团队开始；
• 逐步增加团队数量；
• 在变化和增长期间，确保工作连续，以及软件和业务价值顺畅交付；
• 若存在严重影响生产力和工作连续性的问题，应先解决，而后再增加 Scrum 团队。

项目组织：分布式团队

当新 Scrum 团队必须分布在不同地点时，多团队的主要复杂性便会显现。人员沟通障碍、工作协调困难，以及团队间对共同项目规范的误解，只是其中几项。

多个地点的多个团队

不解决这些挑战，后果十分严重。

企业因为缺乏以下能力，浪费了数十亿美元的 IT 预算： 组织领导能力 和 规模化 Scrum 专业能力。

以下四项关键建议，可以帮助您应对这些挑战：

• 确保新 Scrum 团队成员接受 Scrum 框架培训，成为 规模化 Scrum 专家,
• 确保新成员充分了解项目，正确理解自己为何而工作。不仅要从技术角度理解，也要从专业业务价值角度理解，从而在工作决策中提高贡献价值；
• 确保建立项目规范。单个 Scrum 团队会规定如何沟通、规划和完成工作，多团队项目组织同样需要更高层面的规范，让团队共同沟通、规划、运作、解决问题，并交付客户和业务价值。
• 确保新成员至少暂时与有经验的项目成员共同工作。这可能需要到远程地点访问、开展在岗培训，完全合理，也值得鼓励。这种方式能顺畅传递知识，并在不同团队和地点的成员之间建立双向、面对面的交流。

虚拟团队

分布式 Scrum 团队的另一种形式，是成员分散在多个地点。这样的团队称为“虚拟团队”。

主要挑战是确保成员之间顺畅沟通。Scrum 团队仍须开展所有规定的 Scrum 事件以协调工作，只是现在并非所有人都在同一房间。

虚拟团队

同一地点的成员可以在有帮助时共用一个房间，同时确保远程成员充分参与。他们需要更多依靠协作和沟通工具，可以从同一会议室通过视频会议，与虚拟团队另一部分成员连接，一起参加 Scrum 事件。

Scrum 产品负责人团队

如本资料多次强调的，Scrum 产品负责人与团队定期沟通，对成功交付项目至关重要。

不同地点的 Scrum 团队，需要能够有效获取产品决策。 对于同一产品，各团队共享一位产品负责人、一个产品目标和一份产品待办列表。产品负责人可以委派支持性工作，但仍承担责任；无须为每个团队另设一位承担最终责任的产品负责人。

本版将“Scrum 产品负责人团队”和“首席 Scrum 产品负责人”描述为一种组织协作模式。产品负责人可以与代表或其他产品专家合作，但这些称谓并非额外的 Scrum 责任，也不取代对一个产品承担责任的唯一产品负责人。

承担责任的产品负责人在这种协作支持下，重点确保：

• 构建正确的产品，满足客户需求；
• 产品负责人与任何受委派者有效协作，帮助团队为客户创造业务和技术价值。

产品负责人始终对有效管理产品待办列表负责。支持性的需求工作可以受益于其他专业能力和利益相关者意见。 参与者可以包括商业论证代表、相关利益相关者、企业架构师和技术架构师。

对于同一产品的多个团队，产品负责人及支持人员围绕一份有序的产品待办列表，朝共同产品目标工作。每个 Scrum 团队负责交付其中一些用户故事，但仍会有某些故事需要多个团队共同关注并提供成果。

组件团队与功能团队

在不同团队之间分配工作时，可以让团队负责特定软件组件或功能。 因此，我们称之为“组件团队”或“功能团队”。

组件团队

采用组件团队时，每个团队只负责整个系统中的指定组件。 完成用户故事时，通常需要把故事拆成更小部分，在单个组件内实现。组件团队之间的组件依赖，使持续集成成为成功交付不可或缺的环节。

Scrum 产品负责人团队

这些依赖可能使团队更难在一个 Sprint 内交付完整功能，必须通过协作与集成应对。围绕同一产品工作的团队，仍需要交付集成、可用且符合共同完成定义的增量。

这会使正在进行、尚未集成的工作批量变大，交付前置时间变长。 这并不理想，因为 Scrum 团队应以较小批量和较短前置时间，交付可发布的软件增量。

组件团队的优势是，更容易聚焦特定组件的架构和设计细节，积累专业知识。 这对需要探索与创新的组件可能极为有利。

另一方面，组件团队成员只专长于整个系统中的个别组件。 他们可能失去全局视野，忽略功能的业务必要性。

请记住，客户付费要的不是组件，而是能用来经营业务的功能。 如果不能始终聚焦功能，软件的整体优化和集成可能耗费更多时间。组件团队的决策往往优化单个组件，却可能为整体解决方案的成功和性能造成隐形瓶颈。

组件团队

功能团队

功能团队全面负责实现产品待办列表中规定的用户故事。 团队无须再按不同组件划分。每个功能团队负责交付完整可用的功能，以及该功能带来的业务价值。

功能团队

功能团队成员具备跨职能技能，尽可能自主行动，实现快速交付。 功能团队的优势是保有系统层面的知识，更容易把自己的功能与系统其他部分集成。

不过，功能团队可能更难积累足够的组件知识。培养一个能够快速、独立交付的自主功能团队也需要时间，因为建立跨学科团队并不容易。即便如此，在大多数组织中，真正完成工作的往往正是这些高绩效团队，您的组织很可能也是如此。

如何选择组件团队或功能团队？

实践中，大多数大型组织会同时使用专门的组件团队和功能团队。

组件团队与功能团队

图中的 C 团队是组件团队，按计划或按需向其他功能团队提供基础设施服务。 C 团队本身并不直接实现端到端用户故事，而是交付功能团队所承诺故事中的相关需求。

这样能尽量减少功能团队中必须掌握这些组件知识的专业人员数量。

分布式项目环境中的 Scrum Master

在分布式项目环境中，Scrum Master 的作用更加重要。在这样的项目安排下：

• 需要额外努力，让各团队对 Scrum 框架价值观保持一致；
• 建立影响多个团队的单个团队规范和项目规范（标准），需要更长时间；
• 最后，团队及其交付成果之间的依赖增多，会造成许多障碍。

Scrum Master 需要易于联系，并能有效支持团队。同地办公可能有帮助，但并非 Scrum 要求，远程支持也可以。分布式安排应让 Scrum Master 能够：

• 帮助推动消除阻碍团队进展的障碍；
• 帮助团队建立有效的工作约定；以及
• 帮助团队改善 Scrum 框架的运用。

一些组织设置首席（主要）Scrum Master，支持跨团队辅导与协调。这是可选的组织模式，并非强制层级，也不取代各 Scrum 团队的责任。

大型组织中的每个 Scrum 团队仍须有人承担 Scrum Master 的责任，并为其事件、自我管理和改进提供有效支持。