在构建能够适应快速变化流的系统时，理解这样一个事实非常重要：系统不仅仅由技术构成（包括软件架构），还包括人、团队以及他们之间的相互作用。我们通常是在社会—技术系统中工作，在这种系统里，组织设计与团队结构会影响技术架构。当讨论组织设计及其影响时，康威定律（Conway’s law）所提供的洞察是一个关键考量。
康威定律所揭示的系统影响
康威定律指出：“任何一个设计系统的组织……都会产出一种设计，而这种设计的结构会是该组织沟通结构的副本”[5.1]。组织设计与沟通路径会映射到组织的软件架构之中。把软件架构孤立地单独设计出来，然后寄希望于任意的团队结构都能按预期实现这套架构，这种做法很少奏效。在设计系统时，必须关注团队结构、团队交互方式，以及整体工作流动。识别并最小化瓶颈，对于优化价值流动至关重要。
职能烟囱团队带来的挑战
理解康威定律的另一种方式，是认识到：一个按职能专长（functional expertise）来组织团队的组织，也就是所谓的职能烟囱（functional silos），极有可能产出一种同样呈现烟囱化特征的系统架构。例如，一个组织可能会分别设置负责用户界面（前端） 、后端服务和基础设施组件的独立团队。这样的设置，可能会产出一种由展示层、后端层和基础设施层构成的分层架构，它反映的正是这些职能烟囱团队的沟通结构（图 5.1）。一旦要实现跨越多个层次的变更——例如添加新的业务功能——就必须跨越多个团队边界，从而触发交接。这些交接需要层层协调，会打断变化流，并造成等待时间与延迟，因为每个团队都必须等待其所依赖的团队先完成任务，自己才能开始或完成手头工作。在图 5.1 中，这些职能烟囱代表了每一层各自承担的职能责任。
图 5.1 使用职能烟囱团队并通过交接跨层实现功能变更
一个组织如果是以一种分步骤、线性的顺序来交付变更，并且把工作交接给分别负责开发、质量保证（QA） 和 运维任务的独立职能烟囱部门（图 5.2），那么它同样也不是围绕端到端变化流来优化的。在这种设置下，工作会按顺序从一个团队流向下一个团队，因此会引入额外的协调成本与交付瓶颈，因为每个团队都依赖前一个团队先完成自己的那部分，自己才能开始后续任务。如果每一个阶段（开发、测试、生产）都由彼此隔离的独立团队负责，那么这种碎片化会阻碍来自线上系统的信息与反馈直接回流到负责构建软件的团队。那些从线上系统中获得的宝贵洞察（例如用户反馈、运行信息、性能表现）可能会被延迟传递，甚至被彻底错过，而开发团队也就缺乏能力去快速适应这些洞察。图 5.2 突出了团队交接所带来的问题，其中职能烟囱指的是基于岗位或角色划分的职能边界。
图 5.2 以线性、分步骤、带交接的方式，在职能烟囱部门之间跨阶段交付变更
从团队视角看流动优化的要求
在《Team Topologies》[5.2] 一书中，Matthew Skelton 和 Manuel Pais 提出了一组团队类型模式和团队交互模式，使组织能够围绕快速的价值流动与持续反馈进行优化。根据这两位作者的观点，从团队视角来优化变化流，需要考虑以下几点：
- 避免职能烟囱，而是追求自治的、跨职能团队，由它们负责设计、开发、测试、部署和运行自己所负责的系统
- 最小化重复交接，避免工作被传递给另一个团队去完成流动中的前一个或后一个阶段
- 采用小型、长期存在的团队
- 让团队对其所负责的系统或子系统拥有所有权
- 最小化团队过高的认知负荷
- 最小化团队之间持续性的高带宽沟通，以支持快速流动 1
- 最小化团队之间持续性的高带宽沟通，并不意味着禁止团队之间的协作或交流。它真正的含义是：要有意识地设计团队交互方式，使大多数日常工作都可以自治推进，而把高带宽协作保留给某些特定场景，例如联合解决问题、快速发现与创新，以及有引导的知识分享。
Team Topologies 关注的是“如何建立动态的团队结构和交互模式，以帮助团队快速适应新条件，并实现快速且安全的软件交付”[5.2]。
对软件交付绩效的影响
由 Nicole Forsgren 博士、Jez Humble 和 Gene Kim 开展的四年研究表明，软件交付绩效会极大影响技术型组织的生产力、盈利能力和市场份额。正如他们在《Accelerate》[5.3] 一书中所指出的：“由于几乎每家公司都依赖软件，因此软件交付绩效对于今天任何开展业务的组织都至关重要。 ”为了实现组织绩效并在市场中脱颖而出，技术型组织必须以一种可持续的方式，既快速又可靠地交付软件。软件交付绩效不仅与组织绩效（盈利能力、生产率、市场份额、客户数量）相关，也与非商业绩效（产品/服务数量、运营效率、客户满意度、产品/服务质量、实现组织/使命目标）相关。
Forsgren 等人 [5.3] 提出了四个软件交付绩效的关键指标，这些指标通常被称为 DORA 指标（DevOps Research and Assessment metrics）或 Accelerate 指标：
- 部署频率（Deployment frequency） ：成功的软件版本部署到生产环境中的频率。
- 变更前置时间（Lead time for changes） ：从代码提交到达到可部署状态所经历的时间。
- 平均恢复时间（Mean time to restore，MTTR） ：从事故发生到完全恢复的平均时间。
- 变更失败率（Change failure rate） ：一次变更在部署后导致故障的频率。
为了提升软件交付绩效，Team Topologies 的作者强调：必须重视有意识的团队设计和团队交互，并主张通过有效管理团队的认知负荷来最小化交付瓶颈。
团队认知负荷与心理工作负荷
人类的工作记忆范围限制了他们在短时间内能够接收、处理并保留的信息量 [5.4]。认知负荷（cognitive load）这一术语由 John Sweller 提出 [5.5]，指的是人类工作记忆在任一时刻能够容纳的信息最大量。
Sweller 的认知负荷理论（cognitive load theory，CLT）起源于教育心理学领域，聚焦于如何设计教学方法，以降低学习情境中的认知负荷（包括个体学习与协作学习 [5.6]）。在 CLT 中，Sweller 提出了三种认知负荷形态 [5.7]：
- 内在负荷（Intrinsic load） ：指任务本身固有的难度
- 外在负荷（Extraneous load） ：指任务呈现方式所带来的负荷
- 促进性负荷（Germane load） ：指围绕任务中的模式进行加工的努力，它与学习和理解材料有关
而心理工作负荷（mental workload，也称 cognitive workload）这一概念则起源于认知心理学 [5.8]，并被应用到人因工程与工效学领域。人因工程与工效学是一门科学学科，关注人类与系统中其他要素之间的交互，以优化整体系统绩效和人的福祉，包括提升安全性 [5.9]（也见第 11 章“促进持续改进并推动未来变化”中的“组织文化与安全思维”一节）。心理工作负荷与任务的认知需求有关 [5.10]，它被定义为完成任务所需的心理努力（或投入的认知资源）。如果心理工作负荷被大幅超出，这一因素就会影响个体的任务表现、注意力与专注度 [5.11]。
Sweller 的 CLT 与关于心理工作负荷的研究（例如 Wickens 的研究）在一些方面存在差异，但二者在一点上是一致的：当人达到认知容量极限并发生超载时，其表现会下降，错误率会上升。
在软件开发场景中（甚至更广泛的场景中），Team Topologies 的作者建议：通过优化团队的认知负荷来减少交付瓶颈。他们将团队的认知负荷描述为：团队成员在某一时刻能够在脑中容纳并处理的信息量。如果一个团队的认知负荷被大幅超出，就会引入交付瓶颈，进而导致延迟与质量问题、降低动机，并对软件交付绩效造成负面影响。
因此，要减少交付瓶颈，就需要优化认知负荷。而优化认知负荷，意味着建立清晰的责任边界，并限制一个团队必须处理的软件系统的数量、规模与复杂度。
Team Topologies 聚焦于降低团队的认知负荷。接下来的各节将介绍 Team Topologies 作者所倡导的团队类型与交互模式。
Team Topologies 的基础团队类型
Team Topologies 识别出了四种团队类型（图 5.3）和三种交互类型（图 5.4），它们能够帮助组织快速适应并快速交付变化。
图 5.3 Team Topologies 的四种团队类型
图 5.4 Team Topologies 的三种交互模式
下面的列表会更详细地说明这四种团队类型的特征：
Stream-aligned teams
流对齐团队（stream-aligned teams）围绕某个特定业务领域或组织能力的持续工作流来对齐。它们离客户更近，并对该工作流承担端到端责任，包括构建、部署、运行、支持以及退役。一个工作流“可能是一个产品、一项服务、一组功能、一条用户旅程，或者一种用户画像”[5.2]。流对齐团队的目标，是持续不断地交付功能，并从持续发布到生产环境的过程中吸收反馈。它们是小型的、自治的、跨职能团队，由一群通才和少量专才构成。
Platform teams
平台团队（platform teams）是另一类团队类型的集合体，它们支持流对齐团队完成工作，并负责提供那些流对齐团队可以方便消费的平台。平台是否使用是可选的，它的抽象层级也可以不同。在较低抽象层级上，平台可以屏蔽基础设施、网络或其他横切能力的复杂性；在较高抽象层级上，平台则可以体现为设计系统、数据平台、机器学习平台，或者合规与法务平台等。平台团队为使用该平台提供内部的自服务服务与工具。它们提升流对齐团队的自治性，并降低其认知负荷。规模较大的平台，甚至可以由多个团队组成的平台群组来提供。一个平台可以从很小开始，体现为一个“最薄可行平台”（thinnest viable platform，TVP），也就是刚好足以满足其消费者需求的平台（见第 6 章“把点连起来”中的“识别支持变化流的服务”一节）。
Enabling teams
赋能团队（enabling teams）扮演内部教练的角色，帮助流对齐团队获得其所缺失的能力。例如，它们可以对工具、实践和框架提出建议，或者搭建一套部署流水线骨架或基础测试框架。赋能团队还可以就超出软件开发本身的能力提供辅导，包括有效沟通能力或实践改进能力。赋能团队的目标，是提升流对齐团队的自治性，并降低其认知负荷。
Complicated-subsystem teams
复杂子系统团队（complicated-subsystem teams）是一种可选团队类型。它用于支持流对齐团队处理那些需要专门知识的、特别复杂的子系统。数学模型、低延迟网络、视频处理编解码器，以及围绕机器学习或数据科学的复杂过程，都是复杂子系统的例子。复杂子系统团队的目标，是降低那些深度复杂领域所带来的认知负荷，而这些领域需要独特的专业知识，不可能要求所有流对齐团队都成为专家。
为了跟上持续不断交付功能的需要，流对齐团队需要其他团队的支持。所有三种专业型团队——也就是平台团队、赋能团队和复杂子系统团队——都可以支持某个流对齐团队，以提升后者的自治性并降低其认知负荷。
团队交互模式
如果一个组织结构想要真正高效，仅仅把团队划分为流对齐团队、平台团队、赋能团队和复杂子系统团队还不够。这些团队如何彼此交互，以及它们何时改变并演进交互方式，对于实现高效运作和战略优势同样非常重要。Team Topologies 提出了三种团队交互模式，它们如图 5.4 所示，并描述如下：
Collaboration
协作（collaboration）指的是多个团队在一段有限时间内非常紧密地合作。它适用于快速发现与创新，例如探索新技术时。不过，协作必须是短期的。
X-as-a-Service
X-as-a-Service 适用于这样一种情况：一个团队需要使用由另一个团队以“服务”形式有效提供的代码库、组件、API 或平台。此外，正如 Skelton 和 Pais [5.2] 所强调的，X-as-a-Service “在需要可预测交付的场景下效果最佳”。X-as-a-Service 的目标是提供自服务能力。
Facilitating
促进式支持（facilitating）发生在这样一种场景下：一个团队会因为另一个团队的主动帮助而获益。这种交互类型能够提升接受帮助团队的生产率、有效性和流动性。提供促进式支持的团队，目标是帮助另一个团队补足所缺失的能力，使其最终能够自给自足。
总体而言，这些团队的目标并不是接管流对齐团队的工作，或者成为后者工作流中的一个拦截环节。相反，这些团队类型和交互模式的设计目的，是为了支持流对齐团队，帮助它们把工作做得更好，使其具备自给自足的能力，从而能够以最少的打断和交接，自主完成自己的工作。
团队类型之间的常见交互
定义清晰的团队类型与定义清晰的交互模式相结合，能够促进组织高效运作。图 5.5 展示了一些交互模式与团队类型的典型组合。
图 5.5 团队类型之间典型的间歇性交互模式
- 协作，对于流对齐团队而言是很典型的：例如，它们会在一段有限时间内与平台团队或复杂子系统团队临时紧密合作，以完成某种探索工作。
- 流对齐团队可能会把平台团队或复杂子系统团队所提供的内容，以 X-as-a-Service（XaaS） 的形式进行消费。
- 赋能团队则会通过临时性的促进式支持，帮助其他团队（例如流对齐团队）提升能力。
为了适应变化，团队之间的交互方式也可以随时间发生变化与演进。第 10 章“实施流动优化”会给出一些例子，说明在把一个遗留系统优化为面向流动的系统时，团队之间的交互模式如何演进。
Team Topologies 对 Wardley Mapping 教义原则的应用
回到 Wardley 的教义原则，应用这些通用教义原则，会增强组织对外部变化的适应能力。Wardley 的教义原则描述的是“要应用什么”，而本书第三部分则通过把 Wardley Mapping、DDD 和 Team Topologies 串联起来，展示“如何应用它们”的技术。把 Team Topologies 的基础团队类型与交互模式结合起来，有助于团队应用 Wardley Mapping 的教义原则，如图 5.6 所示。
图 5.6 Team Topologies 对 Wardley Mapping 教义原则的应用
“小团队思维”这一教义原则，在 Team Topologies 中通过考虑信任边界及其对应的信任水平而得以落实。更小的团队通常意味着团队成员之间有更高的信任水平，以及更低的协调成本，这有利于快速的变化流。Team Topologies 主张把由五人到大约九人组成的小型、长期存在的团队作为标准。
优化流动并减少瓶颈，是 Team Topologies 方法的核心。定义清晰的团队类型与定义清晰的交互模式相结合，会提升组织效能，使组织能够专注于降低认知负荷，并提升快速的价值流动。应用 Team Topologies，会形成一种灵活的组织设计，从而支持持续演进和对变化的快速适应。
Team Topologies 同样也体现了“提供目的感、精通感与自主性”这一教义原则。基础团队类型为团队的目的提供了清晰理解。优化认知负荷有助于团队追求精通。通过管理认知负荷，团队可以专注于精通其特定领域或责任范围，而不会被不必要的复杂性压垮。具体来说，平台团队、赋能团队和复杂子系统团队的目标，都是提升流对齐团队的自主性，并降低它们的认知负荷。
小结
本章介绍了 Team Topologies 的基础内容，它代表的是从团队型组织视角来看，如何构建自适应的社会—技术系统。图 5.7 总结了 Team Topologies 的方法。
图 5.7 Team Topologies 概览
本章讨论了 Team Topologies 的动态团队结构与交互模式，如何减少瓶颈并促进组织高效运作。自治的、跨职能的流对齐团队围绕持续工作流进行对齐，并聚焦于快速的变化流。其他类型的团队则通过提升流对齐团队的自治性、降低其认知负荷来支持它们。除了团队类型本身之外，团队之间如何交互，以及它们何时改变和演进这些交互方式，对于运营效率也非常重要，并且可以被用来加速变化流。变化流会影响软件交付绩效，而软件交付绩效又会对组织的市场份额、生产率和盈利能力产生巨大影响。
第 6 章将讨论如何把 Wardley Mapping、领域驱动设计与 Team Topologies 这三者串联起来。
