团队拓扑

任何大型软件工作，例如大型公司的软件资产，都需要很多人——每当有很多人时，你都必须弄清楚如何将他们分成有效的团队。组建以业务能力为中心的团队有助于软件工作响应客户的需求，但所需的技能范围往往会压倒这样的团队。团队拓扑是马修·斯凯尔顿和曼努埃尔·佩斯开发的一种描述软件开发团队组织的模型。它定义了四种团队形式和三种团队交互模式。该模型鼓励健康的互动，使以业务能力为中心的团队能够在提供稳定而有价值的软件流方面蓬勃发展。

此框架中的主要团队类型是流对齐团队，一个以业务能力为中心的团队，负责单个业务能力的软件。这些是长期运行的团队，他们将自己的工作视为提供软件产品来增强业务能力。

每个流对齐团队都是全栈和全生命周期的：负责前端、后端、数据库、业务分析、功能优先级排序、UX、测试、部署、监控——软件开发的全部内容。他们是以结果为导向的，专注于业务结果，而不是以活动为导向的团队，专注于业务分析、测试或数据库等功能。但它们也不应该太大，理想情况下，每个团队都是一个双披萨团队。一个大型组织将拥有许多这样的团队，虽然它们有不同的业务能力来支持，但它们有共同的需求，例如数据存储、网络通信和可观察性。

这样一个小型团队需要减少认知负荷的方法，这样他们就可以专注于支持业务需求，而不是（例如）数据存储问题。实现这一点的一个重要部分是建立在处理这些非重点问题的平台之上。对于许多团队来说，平台可以是一个广泛可用的第三方平台，例如 Ruby on Rails 用于数据库支持的 Web 应用程序。但是，对于许多产品来说，没有一个现成的平台可以使用，团队将不得不找到并集成多个平台。在一个更大的组织中，他们将不得不访问一系列内部服务并遵循公司标准。

可以通过为组织构建内部平台来解决此问题。这样的平台可以完成第三方服务的集成、近乎完整的平台和内部服务。团队拓扑将构建此（毫无想象力但明智地）团队归类为平台团队。

较小的组织可以使用单个平台团队，该团队在外部提供的产品集之上生成一个薄层。然而，较大的平台需要比双披萨所能容纳的人员更多。因此，作者正在转向描述许多平台团队的平台分组。

平台的一个重要特征是它被设计为以一种主要自助的方式使用。流对齐团队仍然负责其产品的运营，并直接使用平台，而无需期望与平台团队进行复杂的协作。在团队拓扑框架中，这种交互模式被称为X-as-a-Service 模式，平台充当流对齐团队的服务。

然而，平台团队需要将他们的服务构建为产品本身，并深入了解客户的需求。这通常需要他们使用不同的交互模式，即协作模式，在他们构建该服务时。协作模式是一种更密集的伙伴关系形式的交互，应该被视为一种临时方法，直到平台成熟到足以转移到 x-as-a 服务模式为止。

到目前为止，该模型并没有代表任何特别有创意的东西。将组织分解为业务对齐团队和技术支持团队是一种与企业软件一样古老的方法。近年来，许多作家表达了使这些业务能力团队负责全栈和全生命周期的重要性。对我来说，团队拓扑的明智见解是专注于这样一个问题：拥有全栈和全生命周期的业务对齐团队意味着他们经常面临过度的认知负荷，这不利于对小型、响应式团队的渴望。平台的主要好处是它减少了这种认知负荷。

这种见解具有深远的影响。首先，它改变了平台团队应该如何看待平台。减少客户团队的认知负荷会导致不同的设计决策和产品路线图，这些路线图主要用于标准化或成本降低的平台。除了平台之外，这种见解使团队拓扑通过识别另外两种团队类型来进一步发展其模型。

一些能力需要专家，他们可以投入大量时间和精力来掌握对许多流对齐团队都很重要的主题。安全专家可能比作为流对齐团队的成员花费更多的时间来研究安全问题并与更广泛的安全社区互动。这些人聚集在赋能团队中，他们的作用是在其他团队中培养相关技能，以便这些团队能够保持独立，并更好地拥有和发展其服务。为了实现这一点，赋能团队主要使用团队拓扑中的第三种也是最后一种交互模式。促进模式涉及一种指导作用，赋能团队不在那里编写和确保符合标准，而是教育和指导他们的同事，以便流对齐团队变得更加自主。

流对齐团队负责其客户的整个价值流，但偶尔我们会发现流对齐团队工作中的一些方面非常苛刻，需要一个专门的团队来专注于它，从而导致第四种也是最后一种团队类型：复杂子系统团队。复杂子系统团队的目标是减少使用该复杂子系统的流对齐团队的认知负荷。即使该子系统只有一个客户团队，这也是一个值得的划分。大多数复杂子系统团队努力使用 x-as-a 服务模式与其客户互动，但需要在短时间内使用协作模式。

团队拓扑的设计明确承认了康威定律的影响。它鼓励的团队组织考虑了人员和软件组织之间的相互作用。团队拓扑的倡导者希望其团队结构将软件架构的未来发展塑造成响应式和解耦的组件，这些组件与业务需求保持一致。

乔治·博克斯巧妙地调侃道：“所有模型都是错误的，有些是有用的”。因此，团队拓扑是错误的：复杂的组织不能简单地分解为只有四种团队和三种交互方式。但像这样的约束正是使模型有用的原因。团队拓扑是一种工具，它促使人们将他们的组织发展成一种更有效的运营方式，一种允许流对齐团队通过减轻其认知负荷来最大限度地提高其流程的运营方式。