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

]]> https://www.uperform.cn/less-agile-less-huge-large-scale-scrum-framework/ Thu, 15 Sep 2016 02:18:56 +0000 http://www.uperform.cn/?p=959 […]]]> LeSS规则是LeSS框架的定义，分为LeSS和巨型LeSS两种规模。这些是我们认为导入LeSS必须做到的事情。

LeSS Framework Rules

The LeSS framework applies to products with 2-“8” teams.

LeSS Structure

• Structure the organization using real teams as the basic organizational building block.
• Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived.
• The majority of the teams are customer-focused feature teams.
• Scrum Masters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices. A Scrum Master does not focus on just one team but on the overall organizational system.
• A Scrum Master is a dedicated full-time role.
• One Scrum Master can serve 1-3 teams.
• In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus shifts from managing the day-to-day product work to improving the value-delivering capability of the product development system.
• Managers’ role is to improve the product development system by practicing Go See, encouraging Stop & Fix, and “experiments over conformance”.
• For the product group, establish the complete LeSS structure “at the start”; this is vital for a LeSS adoption.
• For the larger organization beyond the product group, adopt LeSS evolutionarily using Go and See to create an organization where experimentation and improvement is the norm.

LeSS Product

• There is one Product Owner and one Product Backlog for the complete shippable product.
• The Product Owner shouldn’t work alone on Product Backlog refinement; he is supported by the multiple Teams working directly with customers/users and other stakeholders.
• All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.
• The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might expand. Broader definitions are preferred.
• One Definition of Done for the whole product common for all teams.
• Each team can have their own stronger Definition of Done by expanding the common one.
• The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently).

LeSS Sprint

• There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated whole product.
• Sprint Planning consists of two parts: Sprint Planning One is common for all teams while Sprint Planning Two is usually done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items.
• Sprint Planning One is attended by the Product Owner and Teams or Team representatives. They together tentatively select the items that each team will work on that Sprint. The Teams identify opportunities to work together and final questions are clarified.
• Each Team has their own Sprint Backlog.
• Sprint Planning Two is for Teams to decide how they will do the selected items. This usually involves design and the creation of their Sprint Backlogs.
• Each Team has their own Daily Scrum.
• Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized coordination. Emphasize Just Talk and informal networks via communicate in code, cross-team meetings, component mentors, travelers, scouts, and open spaces.
• Product Backlog Refinement (PBR) is done per team for the items they are likely going to do in the future. Do multi-team and/or overall PBR to increase shared understanding and exploiting coordination opportunities when having closely related items or a need for broader input/learning
• There is one product Sprint Review; it is common for all teams. Ensure that suitable stakeholders join to contribute the information needed for effective inspection and adaptation.
• Each Team has their own Sprint Retrospective.
• An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and create improvement experiments. This is attended by Product Owner, Scrum Masters, Team representatives, and managers (if any).

LeSS Huge Framework Rules

LeSS Huge applies to products with “8+” teams. Avoid applying LeSS Huge for smaller product groups as it will result in more overhead and local optimizations.

All LeSS rules apply to LeSS Huge, unless otherwise stated. Each Requirement Area acts like the basic LeSS framework.

LeSS Huge Structure

• Customer requirements that are strongly related from a customer perspective are grouped in Requirement Areas.
• Each Team specializes in one Requirement Area. Teams stay in one area for a long time. When there is more value in other areas, teams might change Requirement Area
• Each Requirement Area has one Area Product Owner.
• Each Requirement Area has between “4-8” teams. Avoid violating this range.
• LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach.
• Remember each day: LeSS Huge adoptions take months or years, infinite patience, and sense of humor.

LeSS Huge Product

• Each Requirement Area has one Area Product Owner.
• One (overall) Product Owner is responsible for product-wide prioritization and deciding which teams work in which Area. He works closely with Area Product Owners.
• Area Product Owners act as Product Owners towards their teams.
• There is one Product Backlog; every item in it belongs to exactly one Requirement Area.
• There is one Area Product Backlog per Requirement Area. This backlog is conceptually a more granular view onto the one Product Backlog.

LeSS Huge Sprint

• There is one product-level Sprint, not a different Sprint for each Requirement Area. It ends in one integrated whole product.
• The Product Owner and Area Product Owners synchronize frequently. Before Sprint Planning they ensure the Teams work on the most valuable items. After the Sprint Review, they further enable product-level adaptations.

版权所有© 2006-2018 Jeff Sutherland 及 Scrum Inc.

Scrum@Scale是Scrum Inc.的注册商标。本指南基于署名-相同方式共享许可协议4.0发布。(CC BY-SA 4.0)

简体中文版原创翻译团队：申健 Jacky Shen (CST, CTC, Agile Coach); 王洪亮 Stephen Wang (CSP, Agile Coach); 李国彪 Bill Li (CST, Agile Coach);

简体中文版官方授权译文链接：http://www.uperform.cn/scrum-at-scale-guide-chinese/，欢迎转载，请保留所有版权信息并遵循共享许可协议进行演绎。

Scrum@Scale指南之目的

最初在Scrum指南中描述的Scrum，是单个团队进行开发、交付和持续发展复杂产品的框架。自诞生以来，它已经扩展到需要多个团队合作来创建产品、处理过程、服务和系统。创建Scrum@Scale是为了有效地整合这种新型的团队生态系统，从而优化组织的整体策略。为了实现这个目标，它利用一个自由扩展的架构建立起一个“最小可行的官僚机构”，自然地将单个Scrum团队的功能扩展到整个组织中。

本指南包括构成Scrum@Scale框架的组件定义，包括扩展的角色、扩展的事件、企业级工件，以及将它们组织在一起的各种规则。

Jeff Sutherland博士基于Scrum、复杂自适应系统理论、博弈论、面向对象技术等背后的基础原则开发了Scrum@Scale。本指南采纳了许多有经验的Scrum实践者的输入，基于他们的现场工作成果。本指南之目标是读者能够自行实施Scrum@Scale。

为什么要Scrum@Scale?

Scrum是为单个团队而设计，使其能够在可持续的速率下发挥最佳生产力。在该领域中，人们发现随着组织内的Scrum团队数量增长，最佳输出（可工作的产品）及那些团队的速率会开始下降（比如由于跨团队依赖和重复劳动等问题）。很明显，为了获得线性的可扩展性，人们需要一个有效整合那些团队的框架。设计Scrum@Scale是为了利用自由扩展的架构达成这个目标。

通过使用无标度架构，组织的增长并不受限于以一组武断规则所决定的特定方式；相反，它可以有机地基于自己的独特需求而增长，并维持可持续的变革速度，从而可以被组织的成员们接受。

Scrum@Scale是为组织的整体扩展而设计：所有部门、产品和服务。它可以被运用到不同领域，包括工商业、政府或学术界中的各类组织。

Scrum@Scale的定义

Scrum（名词）：Scrum是一个框架，在此框架中，人们可以解决复杂自适应问题，同时高效并创造性地交付最大价值的产品。

Scrum指南是最小功能的集合，它通过彻底的透明性促进检视和适应性，从而驱动创新、绩效和团队幸福感。

Scrum@Scale（名词）：Scrum@Scale是一个框架，在此框架中，一致采用Scrum指南进行运作的Scrum团队网络可以解决复杂自适应问题，同时高效并创造性地交付最大价值的产品。

注意： 这些“产品”可以是硬件、软件、复杂的集成系统、处理过程、服务等，取决于Scrum团队所处的领域。

Scrum@Scale是: * 轻量的 – 最小可行的官僚机构 * 易于理解的 – 仅仅包含Scrum团队们 * 难以精通的 – 需要实施一个全新的运作模型

Scrum@Scale是一个对Scrum进行扩展的框架。通过使用Scrum来扩展Scrum，它彻底简化了规模扩展。它仅仅包含一些Scrum团队，这些团队通过Scrum of Scrums和MetaScrums进行整合。

Scrum@Scale本身基于组件的性质允许组织定制他们的转型策略和实现方式。它使得他们获得一种能力，可以将转型的努力聚焦在他们认为最有价值或最需要改变的领域内，然后再向其他方面取得进展。

在Scrum中，要注意区分对“What”与“How”的问责。在Scrum@Scale中也是一样，那么就要明确地理解权限和职责，从而消除浪费性的组织冲突，令团队更容易达致最佳生产力。

为了区分这两个权限，Scrum@Scale包含两个循环：Scrum Master循环（“How”）和产品负责人循环（“What”），彼此具有两个相互接触点。总之，这些循环造就了一个强大的框架，整合多个团队朝着同一个方向而努力。

Scrum@Scale框架的组件

价值观驱动的文化

除了区分对“What”与“How”的问责，Scrum@Scale还进一步在实证背景下创造价值驱动的文化，旨在建立健康的组织。Scrum的价值观包括：开放、勇气、专注、尊重和承诺。这些价值观驱动着实验性决策，而其取决于透明、检视和调整这三大支柱。

开放支持着所有工作和过程的透明性，没有这种透明度，就无法诚实地检视并试图更好地调整它们。勇气指的是大胆跳跃，这是以创新方式更快地交付价值所需要的。

专注和承诺是我们处理工作职责的方式，把交付客户价值作为最高优先级。最后，所有这一切都必须发生在一个尊重每个人的工作环境中，否则不可能创造任何东西。

Scrum@Scale支持仆人式领导风格和基于意图的领导力模型，以帮助组织蓬勃发展，¹培养一个以可持续速率进行工作的积极环境，致力于将面向客户价值放在努力的第一位。

开始使用Scrum@Scale

在实施大型团队网络时，针对少量团队开发出一个可扩展的参考模型是至关重要的。当部署多个团队时，Scrum实施中的任何缺陷都会被放大。

因此，第一个挑战就是建立少量良好实施Scrum的团队。这组团队克服了那些阻碍敏捷性的组织问题，并为Scrum创建一个在组织中众所周知可运行的参考模型，将其用作整个组织范围内扩展Scrum的模式。

随着团队参考模型的加速，延迟交付、产生浪费或妨碍业务敏捷性的障碍及瓶颈会变得明显。消除这些问题的最有效方法是在整个组织中传播Scrum，以便优化整个价值流。

Scrum@Scale通过使组织浸泡在Scrum中，并有机地分配速度和质量，从而实现了生产力的线性扩展，与组织的特定策略、产品和服务保持一致。

Scrum Master循环

团队级过程

在Scrum指南中明确阐述了团队级过程。它由三个工件、五个事件和三个角色组成。团队级过程旨在：

• 最大限度地使完成和通过质量验证的工作流动起来。
• 每个Sprint都提高一点点速率。
• 以一种可持续和丰富的方式运作。

整合如何做事(“How”) – Scrum of Scrums

需要协作的多个团队组成一个“Scrum of Scrums”（SoS） 。SoS是“团队之团队”²，每天举行一个规模化每日例会（SDS）事件，每个团队派代表参加（通常是团队的Scrum Master，尽管任何人都可以参加，也可以派多个人参加）。SDS的存在是为了协调团队并移除障碍以交付价值。

SDS事件反映了每日Scrum例会，优化了团队网络的协作和绩效。另外，SDS：

• 少于15分钟的时间盒。
• 每个团队必须派代表参加。
• 是一个团队代表们解决3个简单问题的论坛：
  • 我的团队有什么障碍阻止了他们完成他们的Sprint目标（或影响即将发布的版本）？
  • 我的团队是否在做任何事情阻止了其他团队完成他们的Sprint目标（或影响他们即将发布的版本）？
  • 我们发现了团队之间的任何新的依赖关系吗，或者找到了解决现有依赖关系的方法吗？

这一组Scrum Master们本身就是一个Scrum团队，负责在每个Sprint末尾从所有参与团队那里完全地集成出一个潜在可交付的产品增量。SoS团队需要实时地应对所有参与团队所提出的障碍。

SoS充当一个发布团队，必须能够直接地向客户交付价值。为了能有效地做到这一点，它需要与Scrum指南保持一致；也就是说，要有自己的角色，工件和事件。这包括一个待办清单梳理事件，他们在其中决定哪些障碍已经“准备好”被移除，最佳移除障碍的方式是怎样的，团队如何才能知道它是“完成”的。要特别关注SoS回顾事件，团队代表们在其中分享各自团队中的任何成功的学习收获或流程改进，以便在SoS中的各个团队能够将这些实践标准化下来。

为了在每个Sprint结束时交付一个完全集成的潜在可交付产品，它需要具备所需的所有技能。它具有产品负责人代表来解决优先级问题。它可能需要经验丰富的架构师，QA负责人和其他操作技能组。当启动Scrum@Scale时，团队们可能还不具备能够支持持续部署的基础架构。这会迫使SoS建立一个“集成团队”或“发布团队”，以完成克服工程缺陷所需的额外工作。SoS被鼓励去激进地解决集成和部署的障碍，因为它创造了一个超高生产力的环境，例如，亚马逊有3300个Scrum团队，平均每秒部署超过一次³。

Scrum of Scrums Master (SoSM)

SoSM负责联合团队的发布，并且必须：

• 使组织可以看到障碍待办清单。
• 移除团队自己无法解决的障碍。
• 对障碍进行排序，特别要关注跨团队依赖和产品待办清单的分配。
• 提升Scrum of Scrums的效果。
• 与产品负责人们密切合作，每个Sprint部署至少一个潜在可交付的产品增量。
• 利用产品负责人的发布计划来整合多团队的部署工作。

扩展SoS

根据组织或实施的规模，可能需要多个SoS来交付非常复杂的产品。在那些情况下，可以从多个Scrum的Scrum中创建一个Scrum of Scrum of Scrums（SoSoS)。 SoSoS是Scrum团队的一个有机模式，可以无限扩展。每个SoSoS都应该有SoSoSM角色们，以及每个工件和事件的扩展版本。

扩展SoS减少了组织内部的沟通路径数量，因此复杂性被封装了起来。SoSoS与SoS的接口、SoS与单个Scrum团队的接口，两者都采用了相同的方式，从而实现线性可扩展性。

示例图：

注意： 尽管Scrum指南将最优团队规模定义为3到9人，但哈佛大学的研究认为最优团队规模为4.6人。⁴ 针对高绩效Scrum团队的研究一再表明4或5人在一起工作是最优人数。对于SoS中的团队数量，这种模式带来的线性可扩展性是至关重要的。因此，在上图和下图中，选择了五边形来表示一个5人团队。这些图仅仅是示例，您的组织图表可能会有很大差异。

高管行动小组

针对整个敏捷组织的Scrum of Scrums被称为高管行动小组（EAT）。EAT是SoS不能移除的那些障碍的终点站。所以，它必须由在政治和财务上得到充分授权的人们组成，去移除那些障碍。EAT的职能是协调多个SoS（或者SoSoS）。和任何Scrum团队一样，它也需要具备一个PO和SM。EAT最好也像Scrum团队一样可以每天见面。每个Sprint他们必须至少见一次面，并且具备一个透明的待办清单。

例图展示了1个EAT，正在协调分布在5个群组中的25个团队

EAT的待办清单及责任

Scrum是一个区别于传统项目管理的敏捷操作系统。整个SM组织汇报给EAT，后者负责在组织内建立、维护和提升其打造的敏捷操作系统。EAT的角色是创建组织转型待办清单（一份经过排序的列表，包含待完成的敏捷举措）并确保落地执行。例如，如果在一个旧组织中存在一个传统的产品开发生命周期，那么一个新的敏捷产品开发生命周期需要被创建、实现和支持。通常它会比旧方法的更好地支持质量和合规事项，但是需要采纳一套不同的规则和指南来实施。另外，组织发展和治理的很多方面也需要调优。

EAT对于整个组织的Scrum质量负责。它的职责包括但不仅于：

• 为参考模型创建敏捷操作系统，以扩展到整个组织，包括提升敏捷性的企业运营规则，过程和指南。
• 度量和改进组织内的Scrum质量
• 构建组织内业务敏捷的能力
• 创建一个针对Scrum专业人士的持续学习中心
• 支持去探索新型工作方法

最后，EAT必须比照SoS，聚集PO群体来建立和支持相应的的产品负责人组织，从而扩展PO职能。这些PO和关键干系人的团队被称为MetaScrum。

Scrum Master组织的输出/效果

SM组织（SoS、SoSoS和EAT）作为一个整体来完成Scrum Master循环的组件：持续改进和移除障碍，跨团队协调，和部署

持续改进和移除障碍的目标是：

• 识别障碍并转化为机遇。
• 维护一个安全的和结构化的环境以排序和移除障碍，并验证和落实改进。
• 确保组织内的可见性以促成变革。

跨团队协调的目标是：

• 协调多个关联团队间的相似流程。
• 管理跨团队依赖以确保它们不会变成障碍。
• 使团队规范和指南的保持对齐，以确保持续的输出。

SoS的目标是像个发布团队一样工作，因此产品部署也是其分内事，而决定发布内容则是PO的分内事。因此，部署的目标是：

• 持续流动式地向客户交付有价值的完成产品。
• 将不同团队的工作集成到一个无缝的产品。
• 确保用户体验的高质量。

产品负责人循环

整合做什么事(“What”) – MetaScrum

如果一组产品负责人有必要整合一个唯一的待办清单，以供Scrum of Scrums来工作，那么他们自己就形成一个团队称为MetaScrum。每个SoS都有一个对应的MetaScrum。MetaScrum沿着同一路径来对齐多个团队的优先级，这样他们就可以整合多个待办清单，并和干系人保持一致以得到他们对待办清单的支持。MetaScrum举行一种规模化的待办清单梳理活动。

• 每个产品负责人（或其代理）都必须参加
• 这个事件是领导者、干系人或其他客户表达各自倾向的论坛

这个事件按需发生，每个Sprint至少发生一次，以确保一个“就绪”的待办清单。MetaScrum的主要职能是：

• 创建产品的主要愿景并且使之对整个组织可见。
• 和干系人保持一致以确保他们支持产品待办清单的实现。
• 创建唯一的排序的待办清单；确保规避了重复工作。
• 针对SoS内所有团队创建统一的“完成的定义”。
• 消除由SoS提出的依赖。
• 生成一份整合的发布计划。
• 监控能够洞察产品的度量，并基于其进行决策。

类似于SoS，多个MetaScrum本身也作为Scrum团队来运作。所以，需要某人来扮演SM来保持团队的正常沟通。他们还需要唯一的人来负责协调，使得MetaScrum覆盖的所有团队创建出唯一的产品待办清单。这个人被指定为产品总负责人。

产品总负责人(CPO)

通过MetaScrum，产品总负责人与各个团队的产品负责人来协调优先级。他们以干系人以及顾客需求来对齐待办事项的优先级。类似于SoSM，可以是某个团队的PO来扮演这个角色，或者是某个人全职担任这个角色。他们的主要职责和普通PO是一样的，但是在扩展的时候：

• 建立整个产品的战略愿景
• 创建唯一的、排序的待办清单，包含将要被所有团队交付的价值。
• 这些事项对于一个团队的PO来说可以是更大规模的故事。
• 与相应的SoSM紧密工作在一起，以便有效地部署MetaScrum团队创建的发布计划。
• 监控客户对产品的反馈并相应地调整待办清单。

扩展MetaScrum

如同SoS可以增长到SoSoS，MetaScrum也可以用同样的机制进行扩展。没有专门的术语对应这些扩展单元，他们的CPO们也没有专门的扩展头衔。我们鼓励每个组织发展自己的方式。下图中，我们选择了再增加一个“总”以突出那些PO。

一些例图：

注意： 如上所述，这些多边形代表着理想规模的Scrum团队和MetaScrum。这些图仅仅作为例子，你的组织图可能会显著不同。

高管MetaScrum（EMS）

MetaScrum使得PO及其对应的SoS能够以一种网状设计进行无限地扩展。整个敏捷组织的MetaScrum是高管MetaScrum。EMS拥有组织的愿景并设立整个公司的战略优先级，使各个团队围绕共同目标来对齐。

例图展示了1个EMS，正在协调分为5个组的25个团队：

产品负责人组织的输出/效果

PO组织(各种MetaScrum，CPO和高管MetaScrum)作为整体来工作以满足产品负责人循环的组件：战略愿景、待办清单优先级排序、待办清单分解和梳理，以及发布计划

设置战略愿景的目标是：

• 透过一个共享的路径清晰地对齐整个组织。
• 清晰而有力地表述组织为什么存在。
• 描述组织会做什么从而调度其关键资产以支持其使命。
• 持续更新以响应快速变化的市场情况。

待办清单优先级排序的目标是：

• 针对待交付的产品、功能和服务，识别出一个清晰的排序。
• 待办清单的排序反映了价值创造、风险缓解和内部依赖。
• 在分解和梳理待办清单之前，先在整个敏捷组织内对高层举措进行排序。

待办清单分解和梳理的目标是：

• 把复杂项目和产品分解为独立的可工作元素，每个元素都可以被一个团队在一个Sprint中完成。
• 捕获和提炼涌现的需求和客户反馈。
• 确保所有的待办事项条目是真的“准备就绪”以便被各个团队拉取。

发布计划的目标是：

• 预报关键特性和能力的交付
• 向干系人沟通交付预期
• 按需更新优先级排序

连接SM与PO循环

理解反馈

反馈组件是PO和SM循环所交叉的第二个点。产品反馈通过调整产品待办清单来驱动持续改进，发布反馈通过调整部署机制来驱动持续改进。获取和分析反馈的目标是：

• 验证我们的假设。
• 理解顾客如何使用产品和与产品互动。
• 捕获新特性和新功能的创意。
• 定义针对已有功能的改进。
• 朝着产品/项目完成的方向更新进度，以更好地规划发布计划并与干系人对齐。
• 识别出部署方法和机制的改进项。

度量与透明性

彻底的透明性是Scrum最佳状态运作的本质，但是只在能够拥抱Scrum价值观的组织中可行。它使组织能够诚实地评估进度并检视和调整其产品及过程。这是Scrum指南中记载的Scrum的实证主义本性的基石。

SM和PO循环各自需要的度量会分别由SM和PO组织来决策。对于两个特定组织以及那些组织中的特定功能来说，度量也可能是唯一的。Scrum@Scale并不要求任何特定的度量集，但是它推荐了最低配置，即组织应该度量如下方面:

• 生产力 —— 例如，每个Sprint交付的可工作产品的总量变化
• 价值交付 —— 例如，单位团队工作量能够带来的业务价值
• 质量 —— 例如，缺陷率或者服务宕机时间
• 可持续性 —— 例如，团队满意度

设置这些度量指标以及透明性是为了：

• 提供适当的上下文给所有的决策者——包括团队成员在内——以做出优秀的决策。
• 尽量缩短反馈周期以避免矫枉过正。
• 最小化地要求团队、干系人和领导者进行额外投入。

关于组织设计的一些说明

Scrum@Scale自由扩展的本性，允许将组织设计为一个个组件，就像框架本身一样。它允许重新平衡和重构团队，从而响应市场。随着组织的增长，分布式团队带来的益处可能也很重要。一些组织在无法获取人才的时候则通过外包开发来扩展和签约。Scrum@Scale展示了如何扩展这种情况，同时避免过长的延迟时间、妥协的沟通以及低劣的质量，使得组织在规模上和地理分布上兼具线性扩展性。⁵

在这个组织图中，知识和基础设施团队表示一些虚拟的专业团队，这些专家的数量太少，难以保证在每个团队中都配备。他们作为一个组与多个Scrum团队进行整合，遵照服务水平协议，每个专业方面请求都流经同一个PO，他将那些请求转换为透明的已排序的待办清单。值得注意的是，这些团队并不是坐在一起的一群各自为政的个体(这是为什么他们被标记为中空多边形)；这些团队成员都坐在实际的Scrum团队当中，但是他们组成这个虚拟Scrum是为了传播待办清单和过程改进。

客户关系，法务/合规、人力运营也包含在这里，因为他们是组织中必要的部分，他们将独立于Scrum团队而存在，其他人将依赖于他们。

关于EAT和EMS的最后一点：在这个图中，由于有2个成员同时存在于这两个团队中，所以两者看起来是重叠了。在非常小的组织或者实施中，EAT和EMS可以由同一批人组成。

结束语

Scrum@Scale是为了扩展生产力而设计的，使得整个组织在一个显著改善的工作环境中能够高质量地做到事半功倍。在大型组织中适当的应用本框架可以削减产品和服务的成本，并且提升质量和创新。

Scrum@Scale是为了让Scrum浸透组织而设计的。所有团队，包括了领导层、人力资源、法务、咨询和培训，以及产品和服务团队，他们在精简和提升组织的时候都采用同一种Scrum风格。

良好实施的Scrum可以运作起整个组织。

致谢

我们感谢IDX创建了Scrum of Scrums，它允许Scrum扩展到上百个团队，⁶感谢PatientKeeper创建了MetaScrum，⁷它使得创新产品能快速部署，感谢OpenView Venture Partners将Scrum扩展到整个组织。⁸ 我们珍视来自英特尔的二万五千多人实施Scrum的输入，教会了我们——“没有事物能扩展”——除了一个自由扩展的架构，还要感谢具有最大的Scrum团队的SAP产品组织，教会了我们让2000多个Scrum团队一起工作的必要因素就是让管理层参与到MetaScrum中。

敏捷教练和培训师们与Jeff Sutherland一起工作，在亚马逊、GE、3M、丰田、Spotify和很多其他公司实施了这些概念，这对于在更广范围的不同领域的公司中验证这些概念是非常有帮助的。

最后，Avi Schneier和Alex Sutherland制定和编辑本文的工作是价值无量的。