The Nexus Framework

Nexus 的定义 

Nexus 是一个由大约 3 到 9 个 Scrum Team 组成的团队，他们一起工作以交付一个产品;它是人和事物 之间的一种连接。Nexus 有惟一的一名 Product Owner，负责管理 Scrum Team 工作的惟一的一份 Product Backlog。 

Nexus 框架定义了职责（accountabilities）、事件（events）和工件（artifacts），将在 Nexus 中 Scrum  Team 的工作结合和编排在一起。Nexus 建立在 Scrum 的基础之上，对于使用过 Scrum 的人来说，它的 部分内容是非常熟悉的。它仅在绝对必要的情况下，对 Scrum 框架进行最小限度地扩展，使多个团队 工作于惟一的一份 Product Backlog，从而构建一个满足目标的 Integrated Increment。 

Nexus 理论 

Nexus 的核心是旨在寻求保持和增强 Scrum 的基础性的自下而上的智慧和经验主义，同时使一组 Scrum Team 能够交付比单个团队所能实现的更大价值。Nexus 的目标是规模化一组致力于同一产品的 Scrum Team 所能交付的价值。通过减少这些团队在每个 Sprint 至少一次协作交付集成的、有价值的和 有用的产品增量时遇到的复杂性来做到这一点。 

Nexus 框架（Nexus Framework）帮助团队解决常见的规模化挑战，例如减少跨团队依赖关系、保持团 队自管理（self-management）和透明，确保问责（accountability）。Nexus 有助于建立透明化的依赖 关系。这些依赖关系通常是由以下方面的不匹配引起的： 

1. 产品结构：不同关注点在产品中独立分离的程度将极大地影响创建集成产品发布的复杂性。 
2. 沟通结构：人们在团队内部和团队之间的沟通方式会影响他们完成工作的能力;沟通和反馈的 延迟会减少工作流（the flow of work）。 

Nexus 提供改变过程、产品结构和沟通结构的机会，以减少或消除这些依赖关系。 

虽然这往往有违直觉，但要想规模化交付的价值，并不总是需要增加更多的人员。增加人员数量和产 品规模会增加复杂性和依赖性，对协作的需要以及决策过程中涉及的沟通路径的数量也会增加。缩减 规模（Scaling-down），即减少从事某项工作的人数，可以是一个交付更多价值的重要实践。

Nexus 框架 

Nexus 在 Scrum 基础之上，通过增强 Scrum 的基本元素，帮助解决跨团队工作中的依赖和协作挑战。 Nexus（见图 1）揭示了一个与 Scrum 非常相似的经验过程（empirical process）。 

Nexus 通过以下方式扩展 Scrum： 

• 职责：Nexus Integration Team 确保 Nexus 在每个 Sprint 中至少交付一个有价值的和有用的 Integrated Increment。Nexus Integration Team 由 Product Owner、Scrum Master 和 Nexus  Integration Team 成员组成。 
• 事件：Nexus 新增、扩充或取代常规 Scrum 定义的事件来增强它们。经过修改后，它们不仅服 务于 Nexus 中的所有 Scrum Team 的整体投入，而且还服务于每个个体团队（individual team）。 Nexus Sprint Goal 是 Sprint 的目标。 
• 工件：所有 Scrum Team 使用同一份 Product Backlog。当 Product Backlog 条目（item）经过精 炼并准备就绪后，哪个团队最有可能在 Sprint 中完成工作的指标也就变得透明了。Nexus Sprint  Backlog 的存在是为了提高整个 Sprint 的透明度。Integrated Increment 代表当前由 Nexus 完成 的所有已集成工作的总和。 

图 1: Nexus 框架

Nexus 职责 

Nexus 由多个 ScrumTeam 组成，这些团队共同为一个 Product Goal 而工作。Scrum 框架在 Scrum Team  中定义了的三种特定的职责:Developers、Product Owner 和 Scrum Master。Scrum 指南中规定了这些职 责。在 Nexus 中，引入了一个额外的职责——NexusIntegration Team。 

Nexus Integration Team 

Nexus Integration Team 的职责是确保每个 Sprint 至少产生一个已完成的 Integrated Increment (整合工作 由 Nexus 完成)。它提供了一个聚焦点，使多个 Scrum Team 的职责成为可能，共同创造有价值的和有 用的增量（Increment），如 Scrum 规定的那样。 

为 Nexus 提供了一个集成聚焦点。集成包括解决跨功能团队的技术和非技术的约束，这些约束可能会 阻碍 Nexus 交付可持续的 Integrated Increment 的能力。它应该使用 Nexus 内部自下而上的智慧去解决问题。 

Product Owner、Scrum Master 以及来自各个 Scrum Team 的合适成员均属于 Nexus Integration Team。 合适的成员是指那些拥有必要技能和知识的人员，他们可以在任何时间帮助解决 Nexus 所面临的问题。 随着时间的推移，Nexus Integration Team 的组成可能会发生变化，以反映 Nexus 的当前需要。Nexus  Integration Team 可能执行的常见活动包括作为教练辅导（coaching）、咨询和突出对依赖关系和跨团 队问题的认知。 

Nexus Integration Team 的组成包括: 

• Product Owner：Nexus 处理惟一的 Product Backlog，如 Scrum 所述，一份 Product Backlog 有惟 一的一名 Product Owner，对 Product Backlog 的内容拥有最终决定权。Product Owner 负责产品 价值最大化，由 Nexus 中的 Scrum Team 来执行和集成工作。Product Owner 还负责对 Product  Backlog 进行有效管理。如何做到这一点，在不同的组织、Nexus、Scrum Team 和个体之间可 能会存在很大差异。 
• Scrum Master：Nexus Integration Team 中的 Scrum Master 负责确保 Nexus 框架如 Nexus 指南中 所述的那样得到理解和实施。该 Scrum Master 也可以是这个 Nexus 的一个或多个 Scrum 团队 中的 Scrum Master。 
• 一个或多个 Nexus Integration Team 成员：Nexus Integration Team 通常由 Scrum Team 的成员组 成，他们帮助 Scrum Team 采用工具和实践，这些工具和实践有助于 Scrum Team 交付有价值的 和有用的 Integrated Increment，通常符合 Definition of Done。 

Nexus Integration Team 负责作为教练辅导（coaching）和指导 Scrum Team 获取、执行和学习这些实践 和工具，以提高他们产生有价值的和有用的增量的能力。 

Nexus Integration Team 的成员身份优先于个体 Scrum Team 的成员身份。只要履行了 Nexus Integration  Team 的职责，他们就可以作为各自 Scrum Team 的团队成员进行工作。这样的优先顺序有助于确保解 决影响多个团队的问题的工作处于优先位置。

Nexus 事件 

Nexus 增加或扩展了 Scrum 指南定义的事件。Nexus 事件的持续时间以 Scrum 指南中相应事件的时长 作为指导。除了对应的 Scrum 事件之外，Nexus 事件也是有时间盒（timeboxed）限定的事件。 

在规模化的情景下，让 Nexus 的所有成员都参与共享信息或达成协议可能并不现实。除非另有说明， 否则无论哪个 Nexus 成员都需要参加 Nexus 事件，以最有效地实现事件的预期成果。

Nexus 事件包括: 

Sprint 

Nexus 中的 Sprint 与 Scrum 中的 Sprint 相同。Nexus 中的 Scrum Team 产生一个惟一的 Integrated  Increment。 

跨团队精炼 

跨团队精炼 Product Backlog 减少或消除 Nexus 中跨团队依赖关系。Product Backlog 必须进行分解，以 使依赖关系透明、识别跨团队之间的依赖关系、消除或最小化依赖关系。Product Backlog 通过不同层 级的分解，使得其从非常大且模糊的需求分解为能够被单个 Scrum Team 在一个 Sprint 之内可以交付的可操作工作。 

在规模化情景下，跨团队精炼 Product Backlog 服务于双重目的: 

• 帮助 Scrum Team 预估哪个团队将交付哪些 Product Backlog 条目。 
• 识别跨团队之间的依赖关系。 

跨团队精炼持续进行。跨团队精炼的频度、持续时间和出席者会有所不同，以优化这两个目的。

如有需要，每个 Scrum Team 将各自继续精炼，以便在 Nexus Sprint Planning 事件中，Product Backlog  条目已经为被选择准备就绪。一个充分精炼的 Product Backlog 将可以最大限度地减少在 Nexus Sprint  Planning 时新依赖关系的涌现。

Nexus Sprint Planning 

Nexus Sprint Planning 的目的是协调 Nexus 中所有 Scrum Team 在这个 Sprint 中的活动。来自各个 Scrum  Team 的合适代表与 Product Owner 会面一同规划 Sprint。 

Nexus Sprint Planning 的结果是： 

• Nexus Sprint Goal，它与 Product Goal 对齐，描述 Nexus 在整个 Sprint 期间将要实现的目的 
• 为每个 Scrum Team 制定的 Sprint Goal ，它们与 Nexus Sprint Goal 对齐 
• 一份惟一的 Nexus Sprint Backlog，它代表 Nexus 为实现 Nexus Sprint Goal 所要做的工作，并使 跨团队依赖关系变得透明 
• 每个 Scrum Team 的 Sprint Backlog，它们使他们为支持 Nexus Sprint Goal 所做的工作变得透明 

Nexus Daily Scrum 

Nexus Daily Scrum 的目的是识别任何集成问题，并检视迈向 Nexus Sprint Goal 的进展情况。来自各个 Scrum Team 的合适代表参加 Nexus Daily Scrum，检视 Integrated Increment 的当前状态，并识别集成问 题和新发现跨团队依赖关系或跨团队影响。每个 Scrum Team 的 Daily Scrum 都会通过制定每日计划来 对 Nexus Daily Scrum 进行补充，主要致力于解决在 Nexus Daily Scrum 期间提出的集成问题。 

Nexus Daily Scrum 并不是唯一一次允许 Scrum Team 调整其计划的时间。跨团队沟通可以在一天中任何 时间进行，详细讨论如何调整适应或重新规划 Sprint 的剩余工作。 

Nexus Sprint Review 

Nexus SprintReview 在 Sprint 结束时举行，旨在提供对于 Nexus 在整个 Sprint 中构建完成的 Integrated  Increment 的反馈，并确定未来的适应性调整。 

因为聚焦于获取益攸关者对整个 Integrated Increment 的反馈，Nexus Sprint Review 取代个体 Scrum  Team 的 Sprint Review。在 Nexus Sprint Review 期间，Nexus 向关键利益攸关者展示他们的工作结果， 并讨论 Product Goal 的进展情况，尽管在细节上展现所有完成的工作是不太可能的。基于这些信息， 与会者就 Nexus 应该如何处理反馈进行协作。Product Backlog 可能会进行调整以反映这些讨论。 

Nexus Sprint Retrospective 

Nexus SprintRetrospective 的目的是规划如何提高整个 Nexus 的质量和效能。Nexus 检视最近 Sprint 中 有关个体、团队、交互、过程、工具及其 Definition of Done 的情况如何。除了个体团队的改进之外， Scrum Team 的 SprintRetrospective 还通过使用自下而上的智慧来聚焦于影响整个 Nexus 的问题，对 Nexus SprintRetrospective 进行补充。 

Nexus Sprint Retrospective 结束 Sprint。

Nexus 工件与承诺 

如 Scrum 指南所述，工件代表工作成果或价值，并且旨在最大限度地提高透明度。Nexus Integration  Team 与 Nexus 内的 Scrum Team 一起工作，以确保所有工件都实现透明，并确保 Integrated Increment  的状态得到广泛的理解。 

Nexus 使用以下工件扩展 Scrum，每个工件都包含一个承诺，如下文所示。这些承诺的存在是为了强化 经验主义和 Nexus 及其利益攸关者的 Scrum 价值观。 

Product Backlog 

只有惟一一份 Product Backlog，其中列出了整个 Nexus 及其所有 Scrum Team 改进产品所需内容的清 单。在规模化的情景下，Product Backlog 必须在依赖关系被检测并且最小化的层级水平上进行理解。 Product Owner 对这份 Product Backlog 负责，包括内容、可用性和有序性。 

承诺： Product Goal 

对 Product Backlog 而言，承诺是 Product Goal。Product Goal 描述产品的未来状态，并作为 Nexus 的长 期目标。 

Nexus Sprint Backlog 

Nexus Sprint Backlog 由 Nexus Sprint Goal 和源自各个个体 Scrum Team 的 Sprint Backlog 的所有 Product  Backlog 条目组成的。它用于突出 Sprint 期间的依赖关系和工作流。随着学到更多，Nexus Sprint  Backlog 在整个 Sprint 期间会进行更新。它应该有足够的细节，以便 Nexus 可以在 Nexus Daily Scrum 中 检检视其进展。 

承诺： Nexus Sprint Goal 

对 Nexus Sprint Backlog 而言，承诺是 Nexus Sprint Goal。Nexus Sprint Goal 是 Nexus 的单个目标。它 是 Nexus 中 ScrumTeam 所有工作和 Sprint Goal 的总和。它通过鼓励 Scrum Team 一起工作，而不是分 开独自行动，从而为 Nexus 的 Sprint 创造连贯性和专注点。Nexus Sprint Goal 在 Nexus SprintPlanning 事 件中创建，并添加到 Nexus Sprint Backlog 中。当 Scrum Team 在 Sprint 期间工作时，他们将 Nexus  Sprint Goal 铭记在心。Nexus 应该在 Nexus Sprint Review 中展示为实现 Nexus Sprint Goal 而完成的有价 值的和有用的功能，以便获得利益攸关者的反馈。 

Integrated Increment 

Integrated Increment 代表 Nexus 迈向 Product Goal 当前完成的所有已集成工作的总和。在 Nexus Sprint  Review 时，检视 Integrated Increment，但可以在 Sprint 结束之前交付给利益攸关者。Integrated  Increment 必须符合 Definition of Done。

承诺： Definition of Done 

对 Integrated Increment 而言，承诺是 Definition of Done，它定义了当集成工作符合产品所需的质量和 度量时的状态。仅当已集成、有价值和可用时，Integrated Increment 才被认为完成。Nexus Integration  Team 负责定义 Definition of Done，该定义应用于每个 Sprint 开发的 Integrated Increment。Nexus 内的 所有 Scrum Team 都必须定义并坚守 Definition of Done。个体 Scrum Team 通过自管理以达到这一状态。他们可以选择更为严格的 Definition of Done，应用于在自己的团队中，但是不能使用严格程度逊 于 Integrated Increment 约定的标准。 

基于工件状态所做决策，其效果与工件透明化水平一致。不完整或部分信息将导致不正确或有缺陷的 决策。这些决策的影响能够在 Nexus 规模上放大。 

结束语 

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