当一个 Scrum 团队不够用时：Nexus 的通俗入门
单个 Scrum 团队在一定范围内运作良好。一旦产品规模超出八九个人所能构建的程度，组织就会增加团队——而麻烦往往从此开始。三个团队各自默默地构建同一产品的不同部分，结果会做出三样彼此对不上的东西。由 Scrum.org 发布的规模化框架 Nexus，正是为了解决这一集成难题而存在。在 2021 年初，许多团队仍在适应远程和混合办公，Nexus 所带来的纪律性反而更显其价值，而非更难理解。
Nexus 刻意保持精简。如果你已经理解 Scrum，一个下午就能学会 Nexus。它并不取代 Scrum，而是在三到九个 Scrum 团队之外包裹一层薄薄的协调机制，使它们共同基于同一份产品待办列表交付一个集成增量。
相比常规 Scrum 究竟改变了什么
各团队保留各自常规的 Scrum 事件、角色与工件。Nexus 在其上仅作少量补充，而最重要的补充就是对集成的关注——确保所有团队的合并工作在每个 Sprint 中至少真正汇合一次。
Nexus 集成团队。 一个小组，负责确保每个 Sprint 都产出可用且集成的产品。它通常包括唯一的产品负责人、一名 Scrum Master，以及帮助各团队解决跨团队问题的成员。它的角色是辅导和支持，而非发号施令。
一个产品负责人，一份产品待办列表。 无论有多少团队，都只有一个产品负责人和一份排好序的产品待办列表。正是这一点防止各团队朝不同方向漂移。
框住整个 Sprint 的 Nexus 事件。 包括 Nexus Sprint 计划、聚焦集成风险的 Nexus 每日站会、对整个增量进行的 Nexus Sprint 评审，以及着眼于整个系统而非单一团队的 Nexus Sprint 回顾。
跨团队的梳理。 各团队共同梳理产品待办列表，足以及早发现依赖关系，并在依赖变成阻碍之前决定哪个团队承担哪项工作。
为什么集成才是核心
大多数规模化的失败并非努力不足，而是集成问题发现得太晚。在 Sprint 最后一天才浮现的依赖代价高昂；而在跨团队梳理时就发现的同一依赖则代价低廉。Nexus 把这种发现尽可能提前，并让一个小组对结果负责。每个 Sprint 产出的那一个集成增量，正是衡量各团队是否真正作为同一产品努力在协作的诚实标尺。
在梳理阶段而非集成阶段让依赖关系可见。
保持唯一的产品待办列表，使优先级不会在团队之间分叉。
频繁集成——每日的集成构建胜过 Sprint 末尾的意外。
让 Nexus 集成团队辅导而非监管；责任仍归属于各团队。
一个务实的提醒：只有当你确实需要多个团队开发同一产品时，才采用 Nexus。为了求快而增加团队往往适得其反——协调成本会随每个团队的加入而上升。要因产品需要而规模化，把团队数量控制在工作所允许的最少，并把集成当作头等活动，而不是事后补救。
如果贵组织正从单一交付团队扩展到多个团队，而接缝处已开始显露问题，XNM 的项目群与项目交付咨询 可以帮助你在裂缝扩大之前建立起协调与集成的纪律。