1. 团队是最有效的软件交付主体，而非个人

1.1 问题

如下图所示，传统的组织结构图并不能帮助我们理解组织中的真实沟通模式。组织需要开发一种更加实际的示意图来表示个体和团队之间预期的和实际的沟通方式。基于组织结构图的决策往往只对组织的一部分进行优化，而忽略了上下游影响。局部优化只对直接涉及的团队有用，但是对于端到端的用户价值交付来说却并无助益。如果在工作流中存在更大的瓶颈，那么这些局部优化的影响就可以忽略不计。

实际上，人们为了完成工作，会与另一条汇报线上的人员进行横向或纵向沟通。组织需要有意识地培养这种创造力和解决问题的能力，并从中受益，而不局限于自顶向下和自底向上的沟通和汇报。

1.2 方案 - 基于康威定律和邓巴数打造小而美的团队

康威定律指出了“如果系统的架构和组织结构不一致，那么组织结构将成为赢家”。特别是，当组织被划分为职能竖井（也就是团队按照专业职能来划分，比如QA、DBA和安全团队）时，难以面向端到端的工作流设计一个良好架构的软件系统。同理，如果一个组织主要根据不同地域的销售渠道来划分，那么就难以开发出一种有效的软件架构来面向全球所有区域提供多样性的软件服务。

架构设计顺序是业务，技术，组织；一切都是为解决业务问题服务的，只有业务架构梳理清楚了才能去设计技术架构。只有业务和技术架构梳理清楚才能去梳理组织架构，因为组织架构的目的是为了业务和技术架构的正常运作。架构的实施顺序是组织，业务，技术；因为组织架构会影响业务架构，业务架构又会影响技术架构。所以如果一个架构师或技术管理者没有能力去影响业务架构和组织架构是不可能做好架构的。

根据邓巴数字来严格管控组织内团队规模的增长。由邓巴数字驱动的团队优先软件架构。

组织群组需要符合邓巴数字，从差不多5个人（或者8个人的软件团队）逐步增长到15个人、50个人、150个人、500个人等。

那我们该如何做呢？

根据邓巴数定律，个人和团队的认知负荷也是有上限的。所以我们要按照业务领域复杂度来组建团队，而不是按照传统组织架构图和技术活动来组建团队。梳理团队职责来匹配团队的最大认知负荷。建立清晰的团队职责边界。定义好团队间明确的 API（不是技术的），要明确哪些事情是对外公开的（如系统API，工具，BAU支持性工作等），对团队内部的（团队内的代码规范，交付实践原则等），并做好时刻地审核与监控。有以下几个启示：

可以将每个领域分配给单一团队。如果领域对团队来说太大，则将单一领域的职责拆分给不同团队

一个7～9个人的黄金规模团队应该可以应对二三个“简单”领域。

如果一个团队已经负责了非常复杂的领域，那么就不应该再给他们分配更多领域，即便是一个非常简单的领域。

避免单一团队负责两个复杂领域。

这里要强调的是：团队是最有效的软件交付主体，而非个人。与以自我为中心的团队成员相比，集体导向的团队成员更有可能关注其他团队成员的任务输入，并在团队交互过程中提高他们的绩效。在团队中拥抱多样化，奖励团队而非个人。

2. 围绕端对端的价值流设计团队拓扑

2.1 什么是团队拓扑

为了尽可能地实现高效，我们需要持续设计团队而不是让他们野蛮生长。我们称之为有意识的团队结构设计，也就是团队拓扑，承认团队在组织中应该有所定位，同时明确每个团队的职责边界。

一般团队间的依赖有三类：知识依赖、任务依赖和资源依赖。这样的分类有助于分析团队间的依赖，以及潜在的针对工作流的约束。

为了减低这三种依赖，按照变更和交付流程来设计团队，可以实现价值快速流动而设置的组织通过将工作保持在价值流团队内来避免交接，并且可以确保将丰富的操作信息集反馈给团队。

这里要说一下Devops，很多人把Devops理解成工具和自动化，实际它的关键是让人们思考对交付链路上团队间交互会导致交付延期，返工等问题；让我们更理解和关注其他团队。有些企业敏捷后，但是没有意识到日益频繁的部署与落后的运维资源和部署能力之间的矛盾，团队只会越来越焦虑，所以良好的工程实践是实施架构变更的基础，否则在组织架构的设计很难实施。所以我们需要加快引入被证明过的工程实践，例如持续构建和交付。

2.2 四类基本团队拓扑

很多组织都在努力实现持续、快速的软件交付，然而他们有多种团队类型，分别有各自不同的（经常定义得不太好）职责。

为了避免这个问题，我们将团队类型的数量缩减为如上图所示的四类基本团队拓扑。四类基本团队拓扑中没有运维或支持团队，这是有意为之的。构建系统的长期团队同样负责这些系统的线上运维工作，所以无须“移交”给独立的运维或支持团队。

1. 价值流团队：匹配业务领域或组织能力的持续流动的工作任务。持续流动依赖于清晰的目标和职责，从而让多团队拥有各自工作流的同时，可以并行不悖。不要试图在团队中为每个角色配备一名专职人员，否则团队中至少要有九名成员才能完全覆盖这些能力。相反，我们只需要让团队具备这样的能力即可，大家彼此学习。下面是该团队的行为和产出：

价值流团队旨在为特性交付建立一条稳定的工作流。

价值流团队能够根据最新变更的反馈不断调整方向。

价值流团队采用试验性手段带来变革，并从中不断学习和调整。

价值流团队几乎不存在同其他团队的工作移交。

可以用可持续的变更流程来评价价值流团队（兼顾一些技术支持和团队健康度指标。）

价值流团队必须腾出时间来提升代码质量（有时候也说成处理技术债），从而确保代码易于变更和维护。

价值流团队应该主动并定期接触支持型基本拓扑团队（复杂子系统团队、赋能团队、平台团队）。

价值流团队的成员感觉他们已经具备或者正在逐步具备“自治、精通、目标”这三种知识型工作者的核心能力。

2. 赋能团队：赋能团队由特定技术领域或产品领域的专家组成，可以由他们来提供帮助。赋能团队进行调研工作，尝试不同方案，并在工具、实践、框架、技术栈等方面给出高质量的建议。这使得价值流团队不必付出太多努力就能获得能力提升。下面是该团队的行为和产出：

赋能团队要主动了解价值流团队的需求，在深入协作时建立定期检查点和联合沟通机制。

赋能团队要在他们的专业领域保持浪潮之巅，在价值流团队提出实际需求之前，持续跟进新方法、工具和实践。在过去，这常常被视为架构师或者创新团队的使命，但如果能通过赋能其他团队来达成这个目标就更好了。

赋能团队既要传播好消息（比如，“这里有一个新的UI自动化测试框架，可以将我们的测试脚本代码减少50%”），也不能遮掩坏消息（比如，“当前我们广泛使用的JavaScript框架已经不再被维护了”）。这样才能在合适的时候引入特定技术，并在合适的时候舍弃它们。

有些时候，当价值流团队难以直接使用某些服务时，赋能团队应该充当内外部的服务代理。

赋能团队不仅要促进自身团队内的学习，也要在价值流团队之间扮演组织内促进共享必要知识的角色。

3. 复杂子系统团队：复杂子系统团队负责构建和维护系统中严重依赖专业领域知识的子系统。处理复杂和专业的工作需要具备特定能力的专家，他们通常很难培养或者寻找。复杂的例子如：视频编码和解码、某财务报税服务系统、人脸识别引擎等。下面是该团队的行为和产出：

复杂子系统团队根据子系统当前的开发阶段来安排相应的工作：在早期的设计和开发阶段，与价值流团队密切协作；在子系统趋于稳定的后期阶段，减少交互并重点关注子系统接口、特性的演化和使用。

有复杂子系统团队协助时，该子系统的交付速度和质量都要明显高于仅由价值流团队负责时的情况（在决定拆分前）。

复杂子系统团队需要根据使用这些复杂子系统的价值流团队的需求来合理地安排优先级并完成交付。

4. 平台团队：平台团队提供的内部服务使得价值流团队无须开发底层服务，降低了认知负荷。价值流团队可以方便地使用平台团队提供的自服务的网站门户和/或编程API（而非厚厚的使用手册）。下面是该团队的行为和产出：

平台团队与价值流团队密切协作，理解价值流团队的需求。

平台团队依赖于快速原型技术，尽早引入价值流团队成员以获得快速反馈，哪些有效而哪些无效。

平台团队需要重点关注服务的可用性和可靠性，并将平台视为一种产品，需要定期回访用户以确认服务的可用性，以及服务是否依然满足用户需求。

平台团队自己也应该是他们所提供服务的用户（如果适用的话），同价值流团队和赋能团队并肩战斗，可能的话，也应该依托于其他平台团队负责的下层平台。

平台团队应明白其提供的新的内部服务（如新技术）将像创新曲线那样被各个价值流团队逐步引入，而不是一蹴而就的。

2.3 团队优先的边界策略

软件交付过程中的许多问题都是由于不同团队之间的边界和他们的职责一时的不清晰造成的。我们需要寻找天然的方法来拆分系统（根据破裂面），使产生的各个部分尽可能独立演进。由此，分配到这些部分的团队将体验到更多的自主权。将子系统边界与业务（主要是独立的）部分对齐是一个很好的方法，领域驱动设计方法可以很好地支持这种方法。但我们注意其他破裂面，如变更频率、风险、监管合规等。通常来说，我们需要组合各种破裂面。

在任何情况下，必须使软件的特性团队人员规模保持稳定，以便团队能够以可持续的方式有效地主导和演进他们所负责的软件。

3. 让团队拓扑“动”起来

3.1 三种交互模式

使用一组良好定义的团队交互模式，能避免团队与软件间模糊不清的对应关系，子系统间的边界和API因此变得清晰。兼顾团队优先动态原理和康威定律，我们使用如下三种核心交互模式。

1. 协作：与另一个团队密切合作。有利于创新和快速探索，但边界不清。

2. 服务（X-as-a-Service）：使用或提供某种服务，而尽量减少协作。职责清晰、交付可预期，但依赖有效的产品管理。

服务团队需要完成卓越的工作才能将部分内容服务化，这虽然不容易，但这么一来交付团队就无须过多地理解他们工作之外的非核心细节，帮助他们更快速地实现交付

优点是：如果服务使用方不需要与服务提供方有太多沟通就能使用服务，那么服务使用方就可以高效率地工作。这意味着，在服务模式下，由于服务可以开箱即用，而无须关注其底层实现细节，服务使用方可以快速实现功能，这是使用服务模式最大价值

3. 促进：为提供或者寻求其他团队的帮助而清除障碍。

下表提供了不同团队如何同组织中的其他团队进行交互的有用提示。例如，一个价值流团队通常使用协作模式或服务模式与其他团队交互，而平台团队大部分情况下使用服务模式。此外，这张表也提供了关于每种类型的团队需要哪些人际交往技能的进一步提示。例如，平台团队需要强有力的产品管理和服务管理专业能力，而赋能团队需要较多的指导和促进经验。

四种基本团队拓扑的主要交互模式如下图：价值流团队使用协作模式或服务模式；赋能团队使用促进模式；复杂子系统团队使用服务模式；平台团队使用服务模式向平台使用团队提供服务。

3.2 团队拓扑不断演进

如上图是一个企业中团队拓扑的演进过程，团队1不断地与平台团队协作，探索新的模式和采用新技术的方式。这种探索活动最终使得团队2采用服务模式构建与平台团队的关系。而团队3及之后的团队就可以使用最新版本的平台，从而实现服务化而不需要与平台团队紧密协作。

我们可以在不同时期为组织的不同部分设计不同的团队拓扑，以适应团队目标和环境。

那么什么时候团队拓扑要演进？

当我们软件对于一个团队来说太大了

交付节奏开始变慢

多种业务服务依赖于一个大型的底层服务

4. 如何落地团队拓扑

在高效能团队模式书中并没有落地团队拓扑的方法，在我们实践中可以采用Wardley Map（沃德利地图）

定义您的客户/用户

用户的需求

功能：您将如何满足用户的需求。在团队拓扑中我们可以把此步骤看成我们要构建的团队所相关的系统。

价值链：当您添加依赖关系时，用户、需求和能力列表将成为价值链

Wardley Map – 当您确定所有事物的进化方式并将其相应地（从左到右）定位在进化轴上时，价值链就变成了 Wardley Map。我们就可以把团队和系统放到初创(genesis)，定制(custom)，标准(product)，常态(commodity)

如果随着时间的推移，相关的团队所构建的系统可能也会发生变化，可能需要重新调整到初创(genesis)，定制(custom)，标准(product)，常态(commodity)；同时考虑需要新的功能系统的支持，我们可以来动态调整沃德利地图，同时把相关的团队拓扑类型和协作方式标注到其中。

5. 总结

虽然团队拓扑是一种很好的从团队驱动设计的手段，但是想要构建一个高效的软件交付和运营组织，那么仅仅依靠团队拓扑是不可以的，我们必须要有如下的基础要素：健康的组织文化，优秀的工程和财务实践，清晰的业务愿景。

另外在读这本书的过程中，有遇到两个问题，已经在读者群里面和译者正在沟通。

问题1：Stream-aligned team 现在翻译成了流动式团队，看起来丢失了一些东西，理解起来有些怪怪的。应该是围绕团队的价值来流动，是不是翻译成价值流团队会好一些？

译者回复：stream-aligned team的本意是 team 按照 stream 来安排，能把整个 stream 都跑下来。大致相当于敏捷里常说的特性团队，也有的时候被称作全功能团队。中文翻译，坦率的说，国内确实还没有大家公认的好的译法，所以在这里也感谢和提前感谢大家群策群力。

问题2：在书中作者说用领域复杂度来度量认知负荷，但是没有给出如何度量领域复杂的，这个没有什么可操作性，能不能和作者沟通一下，该如何衡量？

目前还在等待回复中。