Nexus规模化：多团队Scrum实用操作指南

Nexus是一个用于规模化Scrum的框架。它扩展了Scrum，以协调三至九个Scrum团队共同在单一产品Backlog上工作，并朝向单一集成增量。它由Ken Schwaber和Scrum.org开发，并在Nexus指南中描述。Nexus不取代Scrum——它在Scrum之上添加了一薄层结构，以管理多个团队在同一产品上工作时出现的跨团队依赖关系和集成挑战。

Nexus对Scrum的核心补充

• Nexus集成团队（NIT）。NIT是一个跨职能团队，其主要职责是确保所有Scrum团队的工作在每个Sprint结束时集成为一个有效产品。NIT包括产品负责人（Nexus中所有团队的同一产品负责人）、一名Nexus Scrum Master，以及一名或多名具有解决集成问题技术技能的集成团队成员。NIT不做开发工作；它促进集成并消除集成障碍。

• Nexus Sprint规划。在各团队的Sprint规划之前，所有团队聚集在一起进行Nexus Sprint规划。目的是识别跨团队依赖关系，将产品Backlog条目分配给各团队，并确保每个团队了解他们的工作如何与其他团队的工作相连。Nexus Sprint规划在Sprint中期（届时解决代价更高）之前浮现依赖关系。

• Nexus每日Scrum。每个团队的代表每天聚集，以识别集成问题和跨团队障碍。Nexus每日Scrum不是状态会议；它是专门聚焦于集成风险的协调活动。

• Nexus集成增量。每个Sprint结束时，有一个集成增量——所有团队的合并工作，作为整体集成和测试。各团队可能产生团队级增量，但Nexus标准要求它们被集成为单一增量，原则上可以发布。

何时使用Nexus

• Nexus适用于单一产品真正需要比单个Scrum团队能处理的更多团队时。单个五至九人的Scrum团队通常能处理复杂产品，如果工作能有效排序的话。Nexus增加了协调开销；只有当产品规模真正需要多个团队时才应采用。

• Nexus不适合作为多个独立产品的管理结构。如果三个团队各自在独立产品上工作，他们不需要Nexus——他们需要三个独立的Scrum实施。Nexus专门针对多个团队在一个产品上工作。

• 2022年，Nexus对于正在扩大交付团队以解决技术现代化积压的政府数字项目特别相关。这些环境中的集成挑战——共享数据系统、共享API、部署的监管约束——正是Nexus旨在解决的类型。

XNM协助公共部门组织设计和实施规模化敏捷交付框架。欢迎联系XNM项目群与项目交付咨询团队，探讨贵组织的Nexus和规模化Scrum实施。