使用 Nexus 规模化 Scrum 的权威指南: 游戏规则

Nexus 概览

Nexus 指南的目的

Nexus 是开发和维护规模化产品和软件开发的框架。它使用 Scrum 作为其构造基石。本指南包含 Nexus 的定义，其中包括 Nexus 的角色、事件、工件以及将它们组织在一起的规则。Ken Schwaber 和 Scrum.org 开发了 Nexus，Nexus 指南也由他们撰写和提供。

Nexus 的定义

Nexus（名词 ）：人或事物之间的关系或连接。

Nexus 是一个框架，由角色、事件、工件和将它们组织在一起的规则组成，它把大约 3 至 9 个 Scrum 团队共同工作于同一份产品待办列表以构建满足目标的集成增量的这些工作结合和编排在一起。

Nexus 的背景

软件交付是复杂的，可工作软件的集成有许多工件和活动必须协调，以构建“完成”的成果。这项工作需要被组织、安排顺序、消除依赖，并依阶段产出成果。

许多开发人员已经在使用 Scrum 框架，作为一个团队一起协同工作，致力于开发和交付可工作软件的增量。然而，如果不止一个 Scrum 团队工作在同一份产品待办列表和共同代码基的同一产品上，则经 常会遇到困难。如果这些开发人员分别处在不同地点的团队，他们所做的工作相互影响，他们如何沟 通?如果他们在不同的团队中工作，他们如何集成和测试增量?这些挑战出现在两个 Scrum 团队将他 们各自工作集成为一个单一增量时，在三个或更多团队协作时，将会显著地变得更为困难。

在每个 Sprint 中协作构建(至少一次)一个完整和“完成”增量时，团队之间的工作会产生许多依赖。 这些依赖涉及:

1. 需求：需求范围可能重叠，并且它们实现方式也可能会相互影响。当排序产品待办列表和 选择需求时，应该考虑到这些重叠与影响。
2. 领域知识：团队成员拥有不同的商业和计算机系统的知识。他们的知识应该分布在各个 Scrum 团队中，以确保团队具备他们工作所需的知识，以便在 Sprint 期间将 Scrum 团队之 间的干扰降到最小。
3. 软件和测试工件：需求最终会以软件来实现。

在某种程度上，将需求、团队成员的知识、软件工件映射至同样的 Scrum 团队，可以降低团队之间的依赖。

当使用 Scrum 进行规模化软件交付时，需求、领域知识和软件工件等依赖关系应该驱动软件开发团队 的组成。这样的团队组成能够将生产力最优化。

Nexus 框架

Nexus 是一个过程框架，用于多个 Scrum 团队一起工作创建集成增量。Nexus 与 Scrum 是一致的，对于 使用过 Scrum 的人来说，对于它的部分内容是非常熟悉的。不同之处在于，Nexus 更加关注的是多个 Scrum 团队之间的依赖关系和互动，确保在每个 Sprint 都能至少交付一个“完成”的集成增量。

如图所示，Nexus 包含：

• 角色：新角色—— Nexus 集成团队(Nexus Integration Team)，它的存在是为了协调、教 练(coach)和督导 Nexus 的应用和 Scrum 的运作，以便得到最佳成果(outcomes)。 Nexus 集成团队由产品负责人(Product Owner)、Scrum Master 和 Nexus 集成团队成员组 成。
• 工件(Artifacts):所有 Scrum 团队使用同一份产品待办列表。产品待办列表项经过精炼 并准备就绪后，Sprint 中团队执行工作的指标变得透明化。新工件—— Nexus Sprint 待办列表( Nexus Sprint Backlog)，它的存在是为了提高整个 Sprint 的透明度。所有 Scrum 团队 各自维护他们自己的 Sprint 待办列表。
• 事件：Nexus 事件新增、扩充、或取代常规 Scrum 事件(例如 Sprint 评审)来增强它们。 经过修改后，它们不仅服务于 Nexus 内的所有 Scrum 团队的整体投入，而且还服务于每一 个个体团队(individual team)。

Nexus 过程流

Nexus 由共同致力于至少在每个 Sprint 结束时交付潜在可发布集成增量的多个跨职能(cross-functional) Scrum 团队组成。基于依赖关系，各团队自组织(self-organize)和选择最为合适的团队成员来做特定 工作。

• 精炼产品待办列表(Refine the Product Backlog): 产品待办列表需要分解，以便识别和 解除依赖或使其最小化。产品待办列表项精炼为功能薄片(thinly sliced pieces of functionality)，并且应该识别出可能完成这项工作的团队。
• Nexus Sprint 规划 (Nexus Sprint Planning):来自每个 Scrum 团队的合适代表进行讨论和 评审精炼过的产品待办列表。他们为每个团队选择产品待办列表项。之后，每个 Scrum 团 队规划各自的 Sprint，酌情与其他团队进行互动。其成果是与 Nexus Sprint 目标(Nexus Sprint Goal)对齐的 Sprint 目标集(a set of Sprint Goals)，每个 Scrum 团队的 Sprint 待办列 表和一份惟一 Nexus Sprint 待办列表。Nexus Sprint 待办列表使得每个 Scrum 团队所选的产 品待办列表和任何依赖关系透明化。
• 开发工作:所有团队频繁地将他们的工作集成到共同的环境，并测试，以保证集成是完成的。
• Nexus 每日 Scrum(Nexus Daily Scrum):来自每个开发团队的合适代表每日讨论确定是否 存在集成问题。如果存在集成问题，那么将这一信息透明化传回每个 Scrum 每日例会。之 后，Scrum 团队使用他们自己的 Scrum 每日例会创建当天计划，确保在 Nexus Scrum 每日 例会中提出的集成问题得到处理。
• Nexus Sprint 评审(Nexus Sprint Review):Nexus Sprint 评审在 Sprint 结束时举行，旨在提 供关于 Nexus 在 Sprint 期间构建的集成增量的反馈。所有 Scrum 团队与利益相关者一起评 审集成增量。产品待办列表可能会被调整。
• Nexus Sprint 回顾(Nexus Sprint Retrospective): 来自每个 Scrum 团队的合适代表进行讨 论以识别出共同面临的挑战。接着，每个 Scrum 团队各自举行 Sprint 回顾。然后，来自各 个团队的合适代表再次讨论，任何必要的行动都基于共同的挑战，提供自下而上的智慧。

Nexus

Nexus 的角色、事件和工件继承了相应的 Scrum 角色、事件和工件的目的和意图属性，正如 Scrum 指南所述。

Nexus 角色

一个 Nexus 由一个 Nexus 集成团队和大约 3 至 9 个 Scrum 团队组成。

Nexus 集成团队

Nexus 集成团队的职责是确保在每个 Sprint 至少产生一个“完成”集成增量(整合工作由 Nexus 完成)。 Scrum 团队负责交付一个潜在可发布产品的“完成”增量，正如 Scrum 规定。 Scrum 团队成员的所有 角色在 Scrum 指南中规定。

Nexus 集成团队是 Scrum 团队，它的组成是：

• 产品负责人
• Scrum Master
• 一个或多个 Nexus 集成团队成员

集成团队成员通常也是 Nexus 中的 Scrum 团队的成员。如果是在这种情形下，他们必须以 Nexus 集成 团队的工作优先。Nexus 集成团队的成员身份优先于个体 Scrum 团队的成员身份。这样的优先顺序有 助于确保影响多个团队的问题的工作处于优先位置。

随着时间的推移，Nexus 集成团队的组成可能会发生改变，以反映 Nexus 当前的需要。Nexus 集成团队 的常规活动可能包括教练、咨询和突出对依赖关系和跨团队问题的认知。它也可能会做产品待办列表上的工作。

Scrum 团队解决在 Nexus 中的集成问题。 Nexus 集成团队为 Nexus 提供了一个集成聚焦点。集成包括 解决任何可能阻碍 Nexus 持续交付集成增量能力的跨团队技术或非技术的约束。他们应该利用 Nexus 中各团队自下而上的智慧去解决问题。

Nexus 集成团队中的产品负责人

一个 Nexus 只有一份产品待办列表，正如 Scrum 框架所描述， 一份产品待办列表对应有一个可以最终 确定其内容的一个产品负责人。产品负责人负责产品价值最大化，由 Nexus 中的 Scrum 团队来执行和 集成工作。产品负责人属于 Nexus 集成团队。

产品负责人负责管理产品待办列表以便 Nexus 构建的集成增量产生最大化的价值。如何做到这一点， 可能会因不同组织、不同 Nexus、不同 Scrum 团队和不同的人而有很大的差异。

Nexus 集成团队中 Scrum Master

Nexus 集成团队的 Scrum Master 对确保 Nexus 框架被理解和遵照执行负有全责。Scrum Master 也可以是这个 Nexus 的一个或多个 Scrum 团队中的 Scrum Master。

Nexus 集成团队成员

Nexus 集成团队由熟练使用工具、各种实践和系统工程通用领域的专业人士组成。Nexus 集成团队成员 确保 Nexus 中的 Scrum 团队理解与实现用于检测依赖关系所需的实践和工具，并频繁地将所有工件集 成以满足“完成”定义。Nexus 集成团队成员负责教练和指导 Nexus 中的 Scrum 团队获取、执行和学 习这些实践和工具。

另外，Nexus 集成团队成员也教练 Scrum 团队符合组织的开发、基础设施或架构标准，以确保开发出 高质量的集成增量。

如果满足了他们的主要职责，那么 Nexus 集成团队成员也可以作为开发团队成员在一个或多个 Scrum 团队中承担工作。

Nexus 事件

Nexus 事件持续时间以 Scrum 指南中的相应事件的长度作为指导。除了对应的 Scrum 事件，Nexus 事件也是有时间盒(time-box)限定的事件。

精炼（需求梳理和排期）活动

规模化的产品待办列表精炼(refinement)服务于双重目的。它预估哪个团队将交付哪些产品待办列表项，并且识别跨团队之间的依赖关系。透明化让团队可以监控依赖关系并使其最小化。

以 Nexus 的规模来看，会有许多不同层级的精炼。只有在产品待办列表项足够独立时，它们才能被选择，并在 Nexus 中的 Scrum 团队之间没有过度冲突的情况下工作。

精炼的数量、频度、持续时间和出席者取决于产品待办列表的固有依赖关系和不确定性。产品待办列表通过不同层级的分解，使得其从非常大和模糊的需求分解为能够被一个 Scrum 团队在一个 Sprint 之内可以交付的可操作的工作。

在整个 Sprint 中，精炼是必要和适当的。产品待办列表精炼将在各个 Scrum 团队中继续精炼，以便在 Nexus Sprint 规划事件中，产品待办列表项已经为被选择准备就绪。

Nexus Sprint 规划

Nexus Sprint 规划的目的是协调 Nexus 中所有 Scrum 团队在这个 Sprint 中的活动。产品负责人提供领域知识、选择指南和优先级决策。在 Nexus Sprint 规划之前，产品待办列表应该被充分精炼，识别出依赖关系，解除或最小化。

在 Nexus Sprint 规划之初，来自各个 Scrum 团队的合适代表验证和调整在精炼事件中构建的工作排序。 所有 Scrum 团队成员应该参与其中，以便最小化沟通问题。

在 Nexus Sprint 规划期间，产品负责人讨论制定 Nexus Sprint 目标。Nexus Sprint 目标描述在整个 Sprint 期间由 Scrum 团队想要满足的目的。一旦 Nexus 整体工作被理解，每个 Scrum 团队将执行他们自己特定的 Sprint 规划。Scrum 团队间应该持续共享最新发现的依赖关系。当每一个 Scrum 团队完成他们各自的 Sprint 规划事件时，Nexus Sprint 规划也随之完成。

在 Nexus Sprint 规划期间，新的依赖关系可能会涌现。它们应该被透明化和最小化。跨团队的工作序列也可能需要调整。一个充分精炼产品待办列表将最大限度地减少在 Nexus Sprint 规划时新依赖关系的涌现。所有在这个 Sprint 被选择的产品待办列表项和它们之间的依赖关系要在 Nexus Sprint 待办列表中变得透明。

Nexus Sprint 目标

Nexus Sprint 目标是 Sprint 的目标集。它是所有在 Nexus 内 Scrum 团队的所有工作和 Sprint 目标的总和。 在 Nexus Sprint 评审时，Nexus 应该表明他们开发的“完成”功能达成了 Nexus 目标，以便获得利益相关者的反馈。

Nexus 每日 Scrum 站会

Nexus 每日 Scrum 是一个事件，来自个体 Scrum 团队中的合适代表，检视集成增量的当前状态，识别集成问题或者新发现跨团队依赖关系或跨团队影响。

在 Nexus 每日 Scrum 期间，参与者应该聚焦于每个团队受集成增量的影响，并讨论:

• 前一天的工作是否成功集成？假如没有，那么为什么没有？
• 有什么新的依赖关系或影响已经被识别？
• 在 Nexus 中有什么新的信息需要跨团队共享？

开发团队使用 Nexus 每日 Scrum 检视 Nexus Sprint 目标进展状况。至少每次 Nexus 每日 Scrum 时， Nexus Sprint 待办列表应该被调整，以反映当前对 Nexus 内 Scrum 团队工作的理解。

在 Nexus 每日 Scrum 中识别的工作，将带回给个体 Scrum 团队，作为规划他们自己内部的每日 Scrum 事件。

Nexus Sprint 评审会

Nexus Sprint 评审在 Sprint 结束时举行，旨在提供对于 Nexus 在整个 Sprint 中构建的集成增量的一个反馈，并在需要时调整产品待办列表。

Nexus Sprint 评审替代个体 Scrum 团队 Sprint 评审，因为聚焦于取得利益相关者对整个集成增量的反馈。 在细节上展现所有完成的工作是不太可能的。最大化获得利益相关者反馈的技巧可能是必要的。Nexus Sprint 评审的结果是经过修订的产品待办列表。

Nexus Sprint 回顾会

Nexus Sprint 回顾是一个 Nexus 自我检视和适应(inspect & adapt)的正式机会，并为下一个 Sprint 制定改进计划以确保持续改进。Nexus Sprint 回顾是在 Nexus Sprint 评审之后与下一个 Nexus Sprint 规划之前之间进行的。

它包含三个部分:

1. 第一部分是让来自 Nexus 中各个 Scrum 团队的合适代表进行讨论和识别会造成影响超过一个团队的问题。目的是使问题透明化，共享于所有 Scrum 团队。
2. 第二部分是如同 Scrum 框架所描述，每个 Scrum 团队举行他们各自的 Sprint 回顾。他们可以使用 Nexus 第一部分回顾产生的问题作为他们讨论内容的输入。在个体 Scrum 团队回顾中应该形成行动处理这些问题。
3. 最后，第三部分是一个机会，从来自各个 Scrum 团队的合适代表再次进行讨论，商定如何可视化和跟踪这些识别出来的行动项。这意味着允许 Nexus 作为一个整体进行调整。

因为它们都是常见的规模化功能障碍，每次回顾应该处理以下主题：

• 是否留下任何未完成的工作？Nexus 是否产生技术债务？
• 是否所有工件，特别是代码，都能频繁（如，每天）成功集成？
• 软件是否成功地构建、测试和部署，频度足以防止未解决依赖关系压倒性的累积？

对于上述的问题，如有必要，讨论以下问题：

• 为什么会发生？
• 技术债务如何消除？
• 如何防止问题再次发生？

Nexus 工件

如 Scrum 指南所描述，工件代表工作成果或价值，提供透明化，为检视和适应(inspection & adaptation)提供机会。

产品待办列表

整个 Nexus 和它的所有 Scrum 团队只有惟一一份产品待办列表。产品负责人对这份产品待办列表负责， 包括它的内容、可用性和有序性。

在规模化的情境下，产品待办列表必须在依赖被检测和最小化的层级水平上进行理解。为了支持解决方案，产品待办列表经常被分解为被称之为“薄切片”功能的粒度。在 Nexus Sprint 规划会议上，当 产品待办列表项可被选择以便 Scrum 团队完成，并且没有跨团队依赖性或已降低到最低时，产品待办列表项被视为“准备就绪”。

Nexus Sprint 待办列表

Nexus Sprint 待办列表由源自各个个体 Scrum 团队的 Sprint 待办列表的所有产品待办列表项组成。 它用于突出 Sprint 期间的依赖关系和工作流。它至少每天更新，通常作为 Nexus 每日 Scrum 的一部分。

集成增量

集成增量代表由 Nexus 完成的所有已集成工作的总和。集成增量必须可以使用和潜在可发布，也就是意味着它必须满足“完成”定义。在 Nexus Sprint 评审时，检视集成增量。

工件的透明化

就像它的基石—— Scrum 一样，Nexus 是基于透明化的。在 Nexus 中，Nexus 集成团队与 Scrum 团队协同工作，确保所有工件提供足够透明度给团队，集成增量的集成状态被广泛地理解。

基于 Nexus 工件状态所做决策，其效果与工件透明化水平一致。不完整或部分信息将导致不正确或有缺陷的决策。这些决策的影响能够在 Nexus 规模上放大。软件开发必须在技术债务对 Nexus 而言变得不可接受之前检测并解决依赖关系。缺乏完整的透明度将使它不可能有效指导 Nexus，使其最小化风险和最大化价值。

“完成”的定义（DoD）

Nexus 集成团队负责“完成”的定义（Definition of Done），应用于每个 Sprint 的集成增量开发之中。Nexus 的所有 Scrum 团 队坚守“完成”的定义。只有当产品负责人认为增量可用并且满足潜在可发布时，增量才被认为“完成”。

个体 Scrum 团队可以选择更为严格的“完成”定义，应用于他们自己的团队中。但不能使用严格程度 逊于增量约定的标准。

结束语

Nexus 是免费的，由本指南提供。与 Scrum 框架一样，Nexus 的角色、工件、事件和规则是不可变的。虽然仅仅实施部分的 Nexus 是可能 的，但其结果就不是 Nexus 了。

致谢

Nexus 和 Scaled Professional Scrum 由 Ken Schwaber、 David Dame、 Richard Hundhausen、 Patricia Kong、 Rob Maher、 Steve Porter、 Christina Schwaber 和 Gunther Verheyen 共同合作开发。

翻译

修订者：Jacky Shen (CST, CTC，优普丰认证敏捷教练)

译者：周建成 (Agile Coach), 本中文指南（2018年1月版）从 ken Schwaber 的英文原版翻译而来，https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-01/2018-Nexus-Guide-Chinese-Simplified.pdf