6.2 规模化产品

流畅度是成功扩展敏捷的基础，但只有它还不够，除非每个团队完全独立工作，否则你还需要一种协调团队工作的方法。这比听起来更难，因为团队之间有相互依赖的关系，这往往会导致瓶颈、延误和沟通错误。成功地扩大敏捷的规模是要弄清楚如何管理这些依赖关系。

有两种扩展敏捷的基本策略：纵向扩展，试图增加能够在没有瓶颈的情况下一起工作的团队的数量；横向扩展，试图通过隔离团队的责任来消除瓶颈，这两种策略可以同时使用。

6.2.1 纵向扩展

纵向扩展是指增加能够分享产品所有权的团队数量。所谓“分享所有权”，是指团队之间没有明确的工作领域，每个团队都可以在产品的每个部分工作，并且可以接触任何代码。

我将讨论这样做的两种方法：LeSS和FAST。为了清楚起见，我将使用本书中的术语，而不是每种方法使用的术语，但我会把它们的术语放在括号里。

LeSS

LeSS是大规模Scrum（Large-Scale Scrum）的缩写，是最初扩展敏捷规模的方法之一，它是由Craig Larman和Bas Vodde在2005年创建的。

基本的LeSS适用于2～8个团队，每个团队最多8人。所有的团队都在同一个可视化计划（LeSS称之为“产品待办事项”）中，并且团队间共享所有代码的所有权。还有LeSS Huge，它可以扩展到更多团队。我将在后面讨论它。

一组LeSS团队由一个产品经理（LeSS称其为“产品所有者”）指导，他负责决定产品的方向。团队在固定长度的迭代中工作，迭代时间通常为两周。在每次迭代开始的时候，团队都会聚集在一起，查看可视化计划并决定每个团队要处理哪些以客户为中心的故事（backlog items或feature），然后这些团队只对优先级最高的故事进行处理。

每隔一段时间，各团队就会聚在一起重新计划（改进待办事项列表），这通常发生在每个迭代的中期。团队可以在可视化计划中添加故事，并向产品经理提出优先级建议。

每个LeSS团队都是一个功能团队，这意味着无论涉及哪些代码，该团队从头到尾都在做完整的故事。一旦一个团队对一个故事负责，那么这个团队就拥有这个故事。团队成员被期望与客户和其他利益相关者合作，以澄清细节，并被期望修改和改进代码库的各个部分，以完成每个故事，在LeSS中没有团队级代码所有权的概念。

因为多个LeSS团队可能最终会接触到相同的代码，所以应该相互协调以防止出现问题。这种协调通常是临时性的和点对点的，团队成员知道什么时候需要协调，因为他们一起工作来选择故事，而且部分讨论包括考虑如何以及何时进行协调。

集体代码所有权是通过使用持续集成来实现的，这包括每个程序员至少每隔几小时就把他们的最新代码合并到一个共享分支上。LeSS还包括各种其他协调、指导和学习的机制。

采用LeSS

本书中的素材与LeSS完全兼容，只是与团队所有权有关的大部分内容是由LeSS团队共同拥有的，而不是某个特定的团队，这一点尤其体现在产品管理和代码所有权上。此外，LeSS的一些术语与本书的术语不同。

持续集成对于LeSS特别重要，需要快速地提交构建。你可能需要更积极地使用多阶段构建（参见13.2.6节），具体来说，你可能需要将部分或全部测试移到二级构建，尽管这会增加破坏构建的风险。

如果你正在寻找一种成熟的、经过测试的扩大敏捷规模的方法，请从LeSS开始。你需要在专注区和交付区发展得更加流畅，专注区是最基本的，而交付区是团队分享代码所有权所必需的。至少，你需要共同的代码所有权、测试驱动开发和持续集成。

关于LeSS的更多信息，请参见LeSS网站less.works，或LeSS书籍《大规模Scrum：大规模敏捷组织的设计》（ Large-Scale Scrum：More with LeSS ） ^[Larman2015] 。

FAST

FAST是流式技术（Fluid Scaling Technology）的缩写。它是Ron Quartel的心血结晶，也是我见过的最有前途的扩展方法之一。不幸的是，在写这篇文章的时候，它也是最不被证实的。我把它包括在内是因为我认为它值得你关注。

Ron Quartel在华盛顿的一家健康保险机构创建了FAST。在巅峰时期，他运作着一个拥有65人的团队。他以极限编程为基础，然后在开放空间技术上分层，这是一种帮助大型团体围绕主题进行自我组织的技术。

与LeSS相比，FAST更具流动性。LeSS是基于迭代和拥有特定故事、长期存在的团队，FAST使用连续的工作流，每隔几天就组建新的团队，在FAST中没有团队级别的所有权。

一个FAST小组被称为一个“部落”。每个部落由开发人员和一个或多个产品经理（FAST称之为“产品总监”）组成，他们负责设定方向。整个部落可以由150人组成，尽管在写这篇文章时还没有测试过。

每隔两天部落就会聚在一起开一次“FAST会议”，来决定要做什么工作。这是一个简短而快速的会议，产品经理解释他们的优先事项，然后人们自愿带领一个团队去做一些事情。这些领导人被称为“团队管理人”，任何人都可以自愿成为团队管理人，这是一个临时角色，只持续到下一次FAST会议。

产品经理的优先级是一个指南，而不是一个命令。尽管团队管理人被期望秉诚行事，但他们仍然可以选择他们喜欢的工作。这有时需要做一些产品经理没有被明确要求的事情，比如清理烦琐的代码或减少开发中的分歧。

一旦团队管理人自愿加入并解释了他们的团队将从事的工作，部落中的其他成员就会根据他们想和谁一起工作，以及他们想做什么工作，来自行选择进入团队。

FAST团队没有创建详细的故事分解，而是为每个有价值的增量创建一个“发现树”（有价值的增量是可以单独发布的，参见8.2节）。发现树是对发布增量所需的工作进行分层、及时的分类，它可以用墙上的便签或虚拟白板上的虚拟便签来表示。

各团队以两天或部落选择的任何时间节奏来工作。团队并不期望在这段时间内完成任何具体工作，相反，他们只是尽可能多地取得进展。发现树是用来提供连续性的，并帮助人们看到进展。如果需要的话，有人也可以自愿成为某个特定发现树的“功能管家”，以增加连续性。其他跨团队的协作发生在一个临时的、点对点的基础上，类似于LeSS。

两天结束后，部落有另一个FAST会议，各小组简要地回顾各自的进展，然后循环往复，这个会议是快速、流畅和低仪式感的。

采用FAST

FAST并不像LeSS那样与这本书兼容，专注区的许多做法并不完美适用。

具体来说就是：

· 本书中提到的“团队”的一切反而都适用于整个FAST部落。

· 你会有额外的团队空间需求，尽管现有的指南仍然适用，特别是对远程团队而言。

· 对章程和回顾会议必须进行调整，以便与更多人一起工作，而且他们可能需要更多有经验的主持人，特别是对于远程团队。

· 可视化计划按原样适用，但不再包含比有价值的增量还要小的东西。

· 计划与博弈、任务计划和产能不再被需要了。

· Slack需要以另一种方式引入。

· 站会被FAST会议所取代。

· 预测是完全不同的（而且简单得多，尽管其准确性还没有被评估）。

· 由于缺乏稳定的团队，因此团队动态会变得复杂。

另一方面，交付区和优化区的实践同样适用，与LeSS一样，你可能需要在持续集成的速度方面更加激进。

虽然FAST还没有像LeSS那样得到证实，但我认为它是非常有前途的。如果你有敏捷经验，并且能在一个10～30人的试验团队中进行尝试，我建议给它一个机会。

要尝试FAST，你需要有经验的教练。理论上，FAST只要求专注区的流畅度，但Ron Quartel在他的FAST试点中包括了有经验的XP教练，我认为他们对交付以及专注实践的熟悉程度是使FAST成功的部分原因。如果你想尝试，我建议你也这样做。

你可以在fastagile.io中找到更多关于FAST的信息。寻找“FAST指南”，它是一个快速且简单的阐述。我还在文献[Shore2021]中对Ron Quartel进行了关于FAST的采访。

纵向扩展的挑战和好处

纵向扩展的致命弱点也是它的优势：共享所有权，纵向扩展的团队共享整个代码库的责任。这就要求人们对各种代码都很熟悉。在实践中，至少对于LeSS和FAST来说，人们确实倾向于专业化，选择从事熟悉的工作，但还是有很多东西需要学习。

不过这不是最大的问题，真正的问题是，集体代码所有权很容易变成没有代码所有权。你看，集体代码所有权并不仅仅是赋予你改变代码的能力，当你看到一个机会时，它也赋予了你让代码变得更好的责任。对于大型团体来说，群体很容易认为其他人会做这件事。这在小团队中也可能是一个问题，但在大团队中会被放大——团队需要额外的辅导来帮助人们履行他们的责任。

另外，纵向扩展解决了扩展敏捷时的一个主要问题：建立跨职能的团队。敏捷团队需要具有专业技能的人，如UX设计、运营和安全。如果你的团队只有6～7个人，那么就很难保证每个团队都有具备这些技能的人。但这样你就会遇到一个分配问题：如何确保每个团队在需要的时候就能有他们需要的人？

这对纵向扩展的团队来说不是一个问题。如果你有30个人，以及足够两位用户体验设计师工作的内容，那就没有问题，你可以只引入两位用户体验设计师。在FAST中，他们会把自己分配到需要他们技能的团队；在LeSS中，他们会加入一个或两个特定的团队，而这些团队会自愿从事用户体验相关的工作。

6.2.2 横向扩展

尽管纵向扩展是我对规模化敏捷的首选方法，但许多组织还是转向了横向扩展。在横向扩展中，重点是允许团队独立地工作。横向扩展不是像纵向扩展那样分享产品或组合的所有权，而是将产品或组合分割成单独的责任，由特定的团队拥有。

横向扩展的挑战是如何定义团队的责任，使团队尽可能地隔离开来。这是很难做到的，而且很难根据产品优先级的变化进行调整。

理论上，每个团队应该拥有一个以客户为中心的端到端产品模块。在实践中，横向扩展的团队是如此之小，以至于他们很难拥有整个模块，你最终会发现有两个团队需要访问相同的代码。但在横向扩展的模型中，团队不应该与其他团队分享代码。

因此，尽管理想的情况是每个团队都拥有产品的一个部分，但你几乎总是不得不引入其他不太理想的团队类型。 Team Topologies ^{[Skelton2019]} 一书将其分为四种类型：

· 端到端团队。最理想的。专注于一个特定的产品，面向客户的产品切片或客户群。

· 复杂的子系统团队。专注于构建系统中需要特殊知识的部分，例如，一个较大的云产品中的机器学习组件。这些类型的团队应该谨慎创建，并且只有在所需的知识真正专业化的时候才创建。

· 赋能团队。专注于为其他团队提供专业知识，如用户体验、运营或安全，而不是代表其他团队做工作，这导致赋能团队成为一个瓶颈。这类团队专注于帮助其他团队学习如何自己做这些工作，有时，这涉及提供简化复杂问题的资源，如安全检查表或用户体验设计指南。

· 平台团队。类似于赋能团队，只是平台团队提供的是工具而不是直接帮助。和赋能团队一样，平台团队不为其他团队解决问题，但这类团队提供的工具使得其他团队能够解决自己的问题。例如，一个平台团队可以提供部署软件的工具。

成功地进行横向扩展的秘诀在于你如何将责任分配给团队，跨团队的依赖性越少越好。这从根本上说是一个架构的问题，因为团队的职责需要模拟你所期望的系统架构（这也被称为“康威逆定律”）。

当你只有少量团队时，横向扩展效果最好。当团队的数量小的时候，很容易理解每个人是如何配合的，并协调他们的工作。如果出现问题，每个团队的代表可以聚在一起解决问题。

临时性的协调方法在5～10个团队之间就会崩溃，瓶颈开始形成，一些团队停滞不前，另一些团队则有太多工作。你必须花特定的精力来设计你的团队，以保持团队尽可能独立，并尽量减少跨团队的依赖性。每一个团队，尤其是非端到端的团队，都必须把实现其依赖项的自主性作为首要任务。而产品经理必须仔细协调，以确保每个人的工作都是一致的。

当你拥有30～100个团队时，即使是上述方法也会开始崩溃。变化更加频繁，而团队的责任也必须调整，以跟上业务优先级的变化。你需要进行多层的协调和管理。理解整个系统对人们来说变得不再可能。

在实践中，虽然横向扩展可以无限期地持续下去，但随着团队数量的增加，它变得越来越难以管理。纵向扩展更加灵活，但它不能扩展得那么远。

幸运的是，你可以将这两种方法结合起来，以获得两个方面的最佳效果。

6.2.3 纵向扩展和横向扩展

我曾与一家创业公司合作，该公司的团队成员规模已达到300人，但却陷入困境（整个组织有1000多人，但有大约300人在产品开发团队中）。公司的团队都服务于同一个产品的不同方面，但跨团队依赖性正在扼杀团队的产出。

我从横向扩展的角度来处理这个问题：调整团队的职责，尽量减少依赖性，最大限度地提高隔离度。该公司最终拥有和以前差不多的大约40个团队，但团队之间更加独立了。这使团队的开发工作不再受阻，并且恢复了增长。在遇到新的障碍之前，该公司已经有了80个团队。

每个人都对结果非常满意，但如果可以再做一次，我还会引入纵向扩展：可以组建6个50人的小组，而不是40个小组。协调6个纵向扩展的小组比协调40个小团队要容易得多，而且进一步扩展也不会存在任何问题。即使遇到协调方面的挑战，横向扩展技术也能使团队的规模扩大一个数量级。

更好的是，由于纵向扩展的小组规模非常大，因此各小组都可以是端到端的。在我们的设计中，有很多赋能团队和平台团队，其中一些人很难理解他们的角色。端到端的团队则要简单得多。有了纵向扩展的小组，除了运维平台，这就是团队所需要的一切。

当团队达到80人时，崩溃的部分原因是团队的责任没有被履行。我们已经设计了一个审查和更新团队责任的机制（这是架构团队的工作），但是就像经常发生的那样，它在匆忙中被遗忘了。纵向扩展的小组不需要这么多的维护，因为这类小组更容易适应不断变化的业务条件。

换句话说，你可以把横向扩展和纵向扩展结合起来，把纵向扩展的小组看作一个单一的“团队”。从横向扩展的角度来看，你可以将横向扩展的小组视为一个单一的“团队”。如果你这样做，几乎每个团队都可以是端到端团队，但运营平台的小组可能是个例外。

6.2.4 我的建议

总之，你应该如何扩展敏捷组织？

首先要强调团队的流畅度，组织最常犯的错误是在没有建立起基本能力的情况下广泛传播敏捷。在大多数情况下，要实现良好的扩展，你需要团队同时发展出专注和交付的能力。

纵向扩展后再横向扩展，在大多数情况下，LeSS是你最好的选择，如果你有经验并且愿意尝试，可以尝试FAST。

如果达到了纵向扩展的极限，为60～70人，尽管FAST可能能够进一步扩展，但建议你分成多个纵向扩展的小组，每一个都应该是端到端的团队。你不再需要一个复杂的子系统小组或赋能小组，因为现在的小组已经足够大了，足以包含所有需要的专业知识。在某些情况下，你可能想抽出一个平台组来处理共同的基础设施，通常是一个运维和部署平台。

如果你在使用LeSS，LeSS Huge描述了这种横向扩展的分割，尽管风格略有不同，但它保留了LeSS对集体代码所有权的强调，甚至跨越了两个小组（LeSS称之为“区域”）。然而，在实践中，这些小组倾向于专业化。

但请记住：成功的扩展取决于流畅的团队，这就是本书其余部分的内容，我们将从专注区的流畅度开始。