nexus 指南 - scrumorg-website-prod.s3.amazonaws.com · 版权所有scrum.org ，2015...

2015 年 8 月

Nexus™ 指南Nexus的权威指南:

规模化Scrum开发的外⾻骨架

由 Ken Schwaber与 Scrum.org开发并维护

版权所有 Scrum.org，2015 保留所有权利第 1 页（版本 1.1）

目录

NEXUS 概览 ....................................................................................................... 2

Nexus 指南的目的 ........................................................................................... 2

Nexus 的定义 ................................................................................................. 2

Nexus 背景 .................................................................................................... 2

Nexus 框架 .................................................................................................... 3

Nexus 过程流 ................................................................................................. 4

软件实践 ........................................................................................................ 5

NEXUS .............................................................................................................. 5

Nexus 角色 .................................................................................................... 5

Nexus 集成团队 ........................................................................................... 6

Nexus 事件 .................................................................................................... 7

Nexus Sprint 规划 ...................................................................................... 7

Nexus 每日 Scrum ..................................................................................... 8

Nexus Sprint 评审 ...................................................................................... 9

Nexus Sprint 回顾 ...................................................................................... 9

精炼 ......................................................................................................... 10

Nexus 工件 .................................................................................................. 11

产品待办列表 ............................................................................................. 11

Nexus 目标 ............................................................................................... 11

Nexus Sprint 待办列表 ............................................................................. 12

集成增量 ................................................................................................... 12

工件透明度 ................................................................................................... 12

“完成”的定义.......................................................................................... 13

结束语 ......................................................................................................... 13

致谢 ............................................................................................................ 13

翻译 ............................................................................................................ 13

版权所有 Scrum.org ，2015 保留所有权利第 2 页（版本 1.1）

Nexus 概览

Nexus 指南的目的

Nexus 是开发和维护规模化产品和软件开发的框架。它使用 Scrum 作为

其构造块。本指南包含 Nexus 的定义，其中包括 Nexus 的角色、事件、

工件以及将它们组织在一起的规则。Ken Schwaber 和 Scrum.org 开发了

Nexus，Nexus 指南也由他们撰写和提供。

Nexus 的定义

Nexus（名词）：开发单元（在规模化专业 Scrum 中）

Nexus 是一个由角色、事件、工件和技术组成的框架，它把大约 3 至 9

个 Scrum 团队共同工作于同一份产品待办列表以构建满足目标的集成增

量的这些工作结合与编排在一起。

Nexus 背景

软件开发是复杂的，可工作软件的集成有许多工件和活动必须协调，以构

建“完成”的成果。这项工作必须组织、序列、依赖解决，之后出成果。软

件呈现出额外的困难，因为它不是物理存在。

许多开发人员已经在使用 Scrum 框架，作为一个团队一起工作，致力于

开发可工作软件的增量。然而，如果不止一个 Scrum 团队工作在同一产

品待办列表和共同代码基的同一产品上，那么就会出现困难。如果开发人

员为不在同一地的团队，他们所做的工作相互影响，他们如何沟通？如果

他们工作在不同团队，他们如何集成和测试增量？这些挑战出现在两个团

队集成之时，三个或更多团队时，将会变得更为困难。

许多依赖就产生在至少每个 Sprint 中多个团队合作构建完整和“完成”增量

工作时。这些依赖涉及到：


1. 需求：需求范围可能重叠，并且它们实现方式也可能会相互影

响。当排序产品待办列表和选择需求时，这些知识必需考虑到。

2. 领域知识：团队成员拥有不同业务和计算机系统的知识。这些知

识将会映射至 Scrum 团队以确保其适当，同时，在一个 Sprint 期

间将团队之间的干扰降到最小。

3. 软件和测试工件：在软件代码和测试套件中，需求是或将被实例

化。

某种程度上要求，团队成员的知识、代码／测试工件映射至同一个

Scrum 团队，减少团队之间的依赖。

当运用 Scrum 软件开发呈现规模化时，需求、领域知识和软件／测试工

件的依赖关系应该驱动团队组织。就这个意义上来说，生产力将被优化。

Nexus 框架

Nexus 是一个外骨架，位于联合创建一个集成增量的多个 Scrum 团队的

顶部。Nexus 与 Scrum 是一致的，其部分对于工作于 Scrum 项目的人而

言非常熟悉。所不同的是，Nexus 更多关注的是多个团队之间的依赖关系

和互操作，在至少每个 Sprint 中提供一个“完成”的集成增量。

如下图所示，Nexus 包含：

● 角色：新角色——Nexus 集成团队，它的存在是为了协调、教练

和督导 Nexus 的应用和 Scrum 的运行，以便得到最佳成果。Nexus

集成团队由产品负责人、Scrum Master 和 Nexus 集成团队成员组

成。

● 工件：所有 Scrum 团队使用同一份产品待办列表。当产品待办列

表项被精炼和准备就绪时，在 Sprint 内团队在其中工作的指示器被

可视化。新工件——Nexus Sprint 待办列表，它的存在是协助整个

Sprint 过程的透明性。所有 Scrum 团队各自维护他们自己的 Sprint

待办列表。


● 事件：事件追加，放置，或更换（例如 Sprint 评审）定期 Scrum

事件被增强。修改后，在 Nexus 中，他们不仅服务于所有 Scrum 团

队的整体投入，而且还服务于每一个个体团队。

NexusTM框架，规模化 Scrum 外骨架

Nexus 过程流

在 Nexus 中的所有工作都由全体 Scrum 团队成员来完成，作为 Nexus 的

跨功能团队成员。基于依赖关系，团队可以选择最为合适的团队成员来做

特定工作。

精炼产品待办列表：产品待办列表需要分解，以便识别依赖，解除

或依赖最小化。产品待办列表项精炼为功能薄片，团队应尽早地明

确此项工作。

Nexus Sprint 规划：来自每个 Scrum 团队的合适代表见面讨论和

评审精炼的产品待办列表。他们为每个团队选择产品待办列表项。

之后，每个 Scrum 团队规划各自的 Sprint，酌情与其他团队进行交

互。其成果是与 Nexus 首要目标对齐的 Sprint 目标集，每个

Scrum 团队的 Sprint 待办列表和一份惟一 Nexus Sprint 待办列


表。Nexus Sprint 待办列表使得 Scrum 团队所选的产品待办项和

任何依赖透明化。

开发工作：所有团队开发软件，经常集成他们的工作到共同的环

境，并测试，以保证集成是完成的。

Nexus 每日 Scrum：来自每个 Scrum 团队的合适代表每日开会确

定是否存在任何集成问题。如果存在问题，那么这一信息透明传递

回每个 Scrum 团队每日例会。之后，Scrum 团队使用他们自己的

Scrum 每日例会创建当天计划，确保在 Nexus Scrum 每日例会中

提出的集成问题得到处理。

Nexus Sprint 评审：所有团队与产品负责人一起评审集成增量。产

品待办列表可能会被调整。

Nexus Sprint 回顾：来自每个 Scrum 团队的合适代表开会确定共

同的挑战。然后，每个 Scrum 团队各自举行 Sprint 回顾。来自各

个团队的合适代表再次讨论，任何必要的行动都基于共同的挑战，

提供自下而上的智慧。

软件实践

许多软件开发实践需要与 Scrum 团队工作绑定以便协作构建集成增量。

其中大多数实践需要自动化。自动化有助于对工作与工件的数量及复杂性

的管理，尤其是在规模化环境中。

Nexus

Nexus 的角色、事件和工件继承了相应的 Scrum 角色、事件和工件的目

的和意图属性，正如 Scrum 指南所述。

Nexus 角色

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


Nexus 集成团队

Nexus 集成团队的职责是确保在每个 Sprint 至少产生一个集成增量（整

合工作由 Nexus 完成）。Scrum 团队负责开发潜在可发布的增量，如

Scrum 规定。对 Scrum 团队成员的所有角色在 Scrum 指南中规定。

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

● 产品负责人

● Scrum Master

● 一个或多个 Nexus 集成团队成员

在合适和必要时，Nexus 集成团队成员也可以工作于 Nexus 中的 Scrum

团队。如果是在这种情形下，为 Nexus 集成团队的工作是必须优先考虑

的。Nexus 集成团队成员资格优先于 Scrum 团队成员。这一首选项有助

于确保解决影响多个团队的问题的工作处于优先位置。

随着时间的推移，Nexus 集成团队组成可能会发生改变，以反映 Nexus

当前的需要。Nexus 集成团队的常规活动可能包括教练、咨询和突出对依

赖关系和跨团队问题的认知。它也可能会做产品待办列表方面的工作。

Nexus 集成团队拥有任何集成问题的所有权。对在 Nexus 之中所有的

Scrum 团队全部工作的成功集成负责。集成包括解决任何可能阻碍

Nexus 交付持续集成增量能力的技术和非技术跨团队的约束。他们应该运

用 Nexus 自下而上的智慧去解决问题。

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

Nexus 工作于惟一产品待办列表，正如 Scrum 框架中所描述，一个产品

待办列表对应有一个可以最终确定其内容的一个产品负责人。产品负责人

负责产品价值最大化，Scrum 团队执行和集成工作。产品负责人是

Nexus 集成团队组成部分。


产品负责人负责排序和精炼产品待办列表以便 Nexus 构建的集成增量产

生最大化的价值。如何做到这一点，可能会广泛跨组织、Nexus、Scrum

团队和个体。

Nexus 集成团队中 Scrum Master

Scrum Master 在 Nexus 集成团队中对确保 Nexus 框架被理解和遵循负

有全责。Scrum Master 也可以是 Nexus 的一个或多个 Scrum 团队的

Scrum Master。

Nexus 集成团队成员

规模化开发工作需要单一 Scrum 团队并不经常使用的工具和实践。

Nexus 集成团队由熟练使用这些工具和实践的专业人士和系统工程通用领

域人士组成。Nexus 集成团队成员确保实践和工具被执行和理解，用于检

查依赖关系，经常集成所有工件满足“完成”的定义。

Nexus 集成团队成员负责教练和指导 Nexus 中的 Scrum 团队获取、执行

和学习这些实践和工具。另外，他们教练 Scrum 团队进行必要的开发、

基础设施、或确保高质量集成增量开发所需的架构标准。

如果满足了他们的主要职责，那么 Nexus 集成团队成员也可以作为开发

团队的成员在一个或多个 Scrum 团队中承担工作。

Nexus 事件

Nexus 事件持续时间由 Scrum 指南的相应事件的长度作为指导。他们除

了相应的 Scrum 事件之外都是时间盒。

Nexus Sprint 规划

Nexus Sprint 规划的目的是协调在一个 Nexus Sprint 中所有 Scrum 团队

的活动。产品负责人提供领域知识、选择指南和优先级决策。


Nexus Sprint 规划之初，来自各个 Scrum 团队的合适代表验证和调整在

精炼事件中构建的工作排序。所有 Scrum 团队成员应该参与其中，以便

最小化沟通问题。

在 Nexus Sprint 规划会议期间制定 Nexus Sprint 目标。它描述在整个

Sprint 期间由 Scrum 团队想要满足的目的。一旦 Nexus 整体工作被理

解，每个 Scrum 团队将执行他们自己特定的 Sprint 规划。假如这一会议

是在同一空间举行，团队能够持续共享最新发现的依赖关系。当每一个

Scrum 团队完成他们各自的 Sprint 规划事件时，Nexus Sprint 规划完

成。

在 Nexus Sprint 规划期间，新的依赖关系可能会涌现。它们应该被可视

化和最小化。跨团队的工作序列可能需要调整。在 Nexus Sprint 规划期

间，一个充分精炼的产品待办列表中新依赖关系的涌现将会最小化。为

Sprint 选择的产品待办列表项和它们的依赖关系在 Nexus Sprint 待办列表

中可视化展现。

对 Nexus Sprint 规划而言，产品待办列表应该充分精炼，识别依赖关

系，解除或最小化依赖关系处于优先考虑位置。

Nexus 每日 Scrum

Nexus 每日 Scrum 是一个事件，来自个体 Scrum 开发团队中的合适代

表，监视集成增量的当前状态，识别集成问题或者新发现跨团队依赖关

系。

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

响，并讨论：

● 前一天的工作是否成功集成？假如没有，那么为什么没有？

● 有什么新的依赖关系已经被识别？

● 在 Nexus 中有什么新的信息需要跨团队共享？


在 Nexus 每日 Scrum 期间，Nexus Sprint 待办列表应该被用于可视化和

管理当前的依赖关系。

在 Nexus 每日 Scrum 中识别的工作，将带回给个体 Scrum 团队，作为

规划他们自己内部的每日 Scrum 的事件。

Nexus Sprint 评审

Nexus Sprint 评审在 Sprint 结束时举行，提供对 Nexus 整个 Sprint 中构

建的集成增量一个反馈。

Nexus Sprint 评审替代个体 Scrum 团队 Sprint 评审，因为整个集成增量

聚焦于从利益攸关者中获得反馈。在细节上展现所有完成的工作不太可

能。最大化获得利益攸关者反馈的技巧可能是必要。

Nexus Sprint 回顾

Nexus Sprint 回顾是一个使 Nexus 聚焦于检视和调整的正式机会。它包

含三个部分：

1. 第一部分是让来自 Nexus 的合适代表会面和识别造成影响超过一个

团队的问题。目的是使问题透明化，共享于所有 Scrum 团队。

2. 第二部分如同 Scrum 框架所描述，每个 Scrum 团队举行他们各自

的 Sprint 回顾。他们可以使用 Nexus 第一部分回顾产生的问题作为

他们讨论内容的输入。在个体 Scrum 团队回顾中应该形成行动处理

这些问题。

3. 最后，第三部分是一个机会，从来自各个 Scrum 团队的合适代表再

次会面，商定如何可视化和跟踪这些识别出来的行动项。这意味着

允许 Nexus 作为一个整体进行调整。

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


● 是否留下任何未完成的工作？Nexus 是否产生技术债务？

● 所有工件，特别是代码，是否经常（如，每天）成功集成？

● 软件是否成功地构建、测试和部署，通常足以防止未解决依赖关

系压倒性的累积？

对于上述的问题，如有必要，解决：

● 因何发生？

● 技术债务如何能被撤销？

● 如何防止再次发生问题？

精炼

在 Nexus 规模化中有许多不同层级的精炼。只有当产品待办列表项充分

独立时，它们能够被选择，并在 Nexus 中 Scrum 团队之间没有过度冲突

地进行工作。

精炼会议的数量、频度、持续时间和出席人数取决于产品待办列表的固有

依赖关系。越是复杂和依赖的产品待办项越必须进行精炼，以便消除依赖

关系。产品待办列表项通过不同层级的分解，使得其从非常大和模糊的需

求分解为能够被一个 Scrum 团队在一个 Sprint 之内可以交付的可操作工

作。

规模化的产品待办列表精炼服务于双重目的。它预测哪一个团队将交付哪

一个产品待办项，并且它识别跨这些团队的依赖关系。可视化允许团队监

控和最小化依赖关系。

跨团队精炼的第一部分应该化时间分解产品待办列表至足够详细，使得能

够被可能交付它们的团队所理解，并且在即将到来的 Sprint 中以何种序列

进行。


精炼的第二部分应该花费时间聚焦于依赖关系。跨团队和 Sprint 的依赖关

系必须被识别和可视化。团队将需要这些信息去重新整理他们工作的序列

和分配，以最小化跨团队依赖的数量。

如果产品待办项已经准备就绪，在 Sprint 规划会议期间以最小化依赖关系

供选择，那么在 Sprint 期间已经举行了足够的精炼会议。

Nexus 工件

如 Scrum 指南所描述，工件代表工作成果或价值，提供透明化，为检视

和调整提供机会。

产品待办列表

整个 Nexus 和它的所有 Scrum 团队共用同一份产品待办列表。产品负责

人负责产品待办列表，包括它的内容、可用性和有序性。

在规模上，产品待办列表必须在依赖被检测和最小化的层级水平被理解。

为了支持解决方案，产品待办项经常被分解为叫作“薄切片”功能。在

Nexus Sprint 规划会议之上，当他们能够被选择以便 Scrum 团队完成，

并且与其他 Scrum 团队之间没有或最小化依赖时，产品待办列表项被视

为“准备就绪”。

Nexus 目标

在 Nexus Sprint 规划会议期间，制定整个 Sprint 目标。称之为 Nexus 目

标。它是所有工作和 Nexus 中各个 scrum 团队的 Sprint 目标的总和。在

Nexus Sprint 评审时，Nexus 应该表明他们开发的功能达成了 Nexus 目

标。


Nexus Sprint 待办列表

Nexus Sprint 待办列表由源自各个个体 Scrum 团队的 Sprint 待办列表的

所有产品待办列表项组成。它用于突出依赖关系和 Sprint 期间的工作流。

它至少每天更新，通常作为 Nexus 每日 Scrum 的一部分。

集成增量

集成增量表示由 Nexus 完成的所有集成工作的总和。集成增量必须可以

使用和潜在可发布，也就意味着它必须满足“完成”的定义。在 Nexus

Sprint 评审时，检视集成增量。

工件透明度

就像它的构建块——Scrum，Nexus 是基于透明度的。Nexus 集成团队与

Nexus 中的 Scrum 团队一起工作和组织确保透明度，表现在所有工件

上，增量的集成状态被广泛地理解。

基于 Nexus 工件状态的做决策，其效果与工件透明度水平一致。不完整

或部分信息将导致不正确或有缺陷的决策。这些决策的影响能够在 Nexus

规模上放大。缺乏完整的透明度将使它不可能有效指导 Nexus，使其最小

化风险和最大化价值。

软件必须开发，以便依赖关系被检测，使得技术债务变得不可接受之前被

解决。不可接受技术债务的测试是当集成发生时，所有依赖的解决与否仍

然不清楚。在这种情形之下，没有解决的依赖仍然隐藏在代码和测试基

中，降低了软件的整体价值。


“完成”的定义

Nexus 集成团队负责“完成”的定义，应用于每个 Sprint 的集成增量开发之

中。Nexus 的所有 Scrum 团队坚守“完成”的定义。只有当产品负责人认

为增量可用和潜在可发布时，增量被认为“完成”。

当功能成功地添加到产品和集成到增量中，产品待办列表项被认可为“完

成”。所有 Scrum 团队负责开发和整合他们的工作直至满足这些属性的增

量。

个体 Scrum 团队可以选择更为严格的“完成”的定义，应用于在他们自己的

团队中。但不能使用严格程度逊于增量约定的标准。

结束语

Nexus 是免费的，由本指南中提供。与 Scrum 框架一样，Nexus 的角

色、工件、事件和规则是不可变的。虽然仅仅实施部分的 Nexus 是可能

的，但其结果就不是 Nexus 了。

致谢

Nexus 和规模化专业 Scrum 由 Ken Schwaber、David Dame、 Richard

Hundhausen、Patricia Kong、Rob Maher、Steve Porter、Christina

Schwaber 和 Gunther Verheyen 共同合作开发。

翻译

本中文指南（版本 1.1）是从 ken Schwaber 的英文原版翻译而来。

译者：周建成，敏捷教练（[email protected] ）。

mailto:[email protected]

nexus 指南 - scrumorg-website-prod.s3.amazonaws.com · 版权所有scrum.org ，2015...

Documents