读后感
随手翻的一本书，整体阅读感觉不够系统，可能对于我来说太过复杂了，阅读起来没有将知识串联起来的愉悦感。
看到部分片段再联系工作的经验有所感触，像瞬间迸发的思路，这算是收获吧。
笔记
高效能团队模式：支持软件快速交付的组织架构
马修·斯凯尔顿 曼纽尔·派斯
178 个笔记
阅读周期:
- 阅读时长：7 小时
- 开始时间：10/14/2022, 9:20:59 PM
中文版推荐序
一是他认为：“我们需要以团队为中心的方法来实现可持续的 CI/CD，而不是以工具为中心。”
二是他分享了四类团队类型和三种交互模式，四类团队类型包括：流动式团队、赋能团队、复杂子系统团队、平台团队；三种交互模式包括：协作、服务、促进。
译者序
很多时候，技术能够解决的问题都不是问题，而最大的问题在人身上，确切地说是在由个人构成的组织身上。引用我非常尊敬的一位领导的话来说：“所有的事情归根结底都是人的事情，只要人对了，那么事情就都对了，所以组织最重要的事情是去发现人、培养人、激发人心中的火花。”对此，我深以为然，可见组织和人的问题才是“Being DevOps”的最大障碍。
序言
雷曼软件进化定律，特别是持续增长法则，反映了随着系统的使用、不断涌现出新需求和机会，给软件能力扩展带来了巨大的压力。为了应对这种日益增加的复杂性，并且从中受益，需要极大地提升双模设计领域的重要性：系统设计及创建和迭代这些系统的组织设计。
通过定义清晰的职责和边界来管理团队间的认知负荷，是团队拓扑方法在团队设计方面最与众不同的特点。实现适当范围、有限职责、自然且相对独立的（子）系统结构是团队想要达成的目标。
前言
第 Ⅰ 部分探索了康威定律，阐述了组织交互方式是如何限制我们的系统设计的，以及应该如何顺势而为并将其转变成我们的优势。接下来，我们定义了什么是团队，并研究了那些影响团队协作效率的现实约束。
第 Ⅱ 部分研究了一组已经在业界被证明了的静态团队模式，以及如何结合康威定律和组织的实际情况来选择其中一种模式。这部分内容可以帮助你思考适合所在组织的团队拓扑，并且提供了如何将团队映射到系统中的指导原则，进一步思考了康威定律和基础团队拓扑。
最后，第 Ⅲ 部分研究了组织设计的进化方法，提供了强大的创新能力和快速交付能力来应对快速变化的外部环境。这部分内容解释了如何使用团队拓扑方法来建立一个对市场和用户需求具有敏感度的组织，并提供了相关的人员招聘和技能方面的指导。
一个组织应该是人和技术共同作用的结果。在这方面，本书和以下领域不谋而合：控制论[特别是将组织视为一个“感知系统”，这个理论最早可以追溯到 1948 年 Norbert Wiener 首次出版的《控制论：或关于在动物和机器中控制和通信的科学》（Cybernetics：Or Control and Communication in the Animal and the Machine）一书]、系统思考（尤其是戴明博士的杰出工作）、Cynefin 框架等用于访问复杂系统的方法论（Dave Snowden 和 Mary Boone 在 2007 年 Harvard Business Review 上发表了论文 A Leader’s Framework for Decision Making）和适应性结构理论（Gerardine DeSanctis 和 MarshallScott Poole 在 Organization Science 上发表了文章 Capturing the Complexity in Advanced Technology Use：Adaptive Structuration Theory。他们在其中强调了技术影响力并不是恒定的，而是取决于团队和组织如何看待这项技术）。
第 Ⅰ 部分 团队即交付
要求每个人都与其他人进行沟通只会让事情变得一团糟。
第 1 章 组织结构的陷阱
业务需要兼顾系统稳定性和交付速度两方面的优化。
尽管存在以上这些风险和需求，但是很多企业组织人员和团队的方式依然与现代软件开发和运维的方式背道而驰。组织过分依赖于组织结构图和矩阵来划分和控制工作，导致在快节奏交付的同时缺少必要的条件来拥抱创新。为了取得成功，组织需要一种稳定且高效的团队模式和协作方法。作为敏捷性和适应性的基础，他们需要不断投入资源赋能和培养团队。为了在竞争日益激烈的市场环境中生存下去，组织需要团队和成员能够及时感知外部变化，并且不断地与时俱进。
好消息是使用正确的思维方式以及强调适应性和重复性的工具，并把团队和人视为中心，是可能兼顾快速和安全的。
作为管理这些接口的技术团队成员，我们必须改变之前的思想，不再将团队视为一组可替换的个体，即只要他们沿用“正确”的流程和使用“正确”的工具就能获得成功，而是将人员和技术视为社会技术生态系统中的一分子，正如计算芯片中用到的碳和硅一样。与此同时，我们需要确保团队具有内驱力，并且给予团队充分的机会在这类系统中出色地完成工作。
组织的沟通结构
组织结构图在构建软件系统方面的确有用，尤其是在监管领域和法律合规方面。然而，在一个高度协作的环境中，结果充满不确定性，那么将组织结构图视为拆分工作的根本原则，往往会导致不切实际的预期。我们需要依赖的是低耦合且长期存在的团队，他们能够高效协作来平衡速度与安全方面。
但是人们的沟通并不局限于图中的连接线，我们会联系任何为了达成工作目标所依赖的人员，我们会为了达成目标来改变规则。
。组织需要有意识地培养这种创造力和解决问题的能力，并从中受益，而不局限于自顶向下和自底向上的沟通和汇报。
举个例子，某团队采用了云技术和基础设施即代码技术，将新基础设施的初始化时长从几周或几个月缩短到了小时、分钟级别。但是如果每次生产部署变更需要在每周一次的组织会议上进行审批，那么发布频率最高也只能维持在每周一次。
系统思维更加专注于全局优化，将目光着眼于完整的工作流，识别哪里是目前的最大瓶颈并消除它，进行持续改进。团队拓扑聚焦于如何建立动态的团队结构和交互模式，从而帮助团队快速适应新的环境，并达成快速和安全的软件交付目标。
每个组织都存在不止一种而是三种组织结构。 1.官方架构（组织结构图），促进合规性。 2.非正式架构，个体间的“影响范围”。 3.价值创造架构，工作是如何在个人间和团队间完成的。
例如，诞生于 20 世纪 90 年代并在之后几十年流行的“矩阵管理”方法，试图通过个人对业务主管和职能主管的双线汇报，来解决高度不确定性和专业技能要求所带来的工作复杂性。尽管与纯粹的职能型团队组织相比，更加重视业务价值，但是它依然采用了一种静态世界观，无法跟上业务和技术领域的进化节奏。
五条组织设计法则。 1.根据令人信服的理由来设计。 2.为设计决策提供开发选项。 3.选择正确的设计时机。 4.寻找事物偏离轨迹的线索。 5.对未来保持警惕。
团队拓扑：一种全新的团队思维方式
团队拓扑提供了四类基本的团队类型——流动式团队、平台团队、赋能团队和复杂子系统团队，以及三种团队核心交互模式——协作模式、服务模式和促进模式。
在技术和产品探索阶段，通常需要高度协作的环境（存在重叠的团队边界）才能成功。但是，如果在探索阶段结束后（也就是已获得成型的技术和产品时）依然维持同样的结构，反而会导致精力的浪费和误解。
团队拓扑还特别重视设计和构建软件系统的人性化方法。它将团队视为软件交付过程中不可分割的元素，并且承认和尊重团队的认知容量是有限的。团队拓扑和基于康威定律的动态团队设计一起构成了探索解决方案的策略工具。
康威定律的复苏
构建软件需要理解团队的沟通路径，以便更加实际地考虑什么样的软件架构才是可行的。如果预期中理论上的系统架构不符合组织模型的话，那么其中之一就需要做出改变。
Eric Raymond 在他的 The New Hacker’s Dictionary 一书中幽默地说道：“如果有四个小组合作开发一个编译器，那么你将得到一款具有四个步骤的编译器。”
认知负荷和瓶颈
谈到认知负荷，我们可以简单地将其理解为任何一个人在给定的时间内大脑中所能保存的信息量是有上限的。
如果不考虑认知负荷，团队就会做大量并行工作，尝试覆盖过多的职责和领域。这让团队开始疲于奔命，精力在不断的任务切换中消耗殆尽。
如果考虑到 Dan Pink 的内在动机三要素，这就一点儿也不奇怪了：自治（被多个团队源源不断的请求和优先级所淹没）、精通（样样都懂却无一精通）、目标（过多的职责领域）。
我们需要把团队摆在第一位，鼓励去限制他们的认知负荷。将认知负荷明确作为团队规模、分配职责和建立团队边界的有力工具。
团队拓扑方法提倡组织设计要优化运行系统的变更和反馈流程。这需要限制团队的认知负荷，明确设计团队之间的交互模式，以帮助生成我们所需的软件系统架构（基于康威定律）。
总结：重新思考团队的结构、目标和交互方式
过于关注可以快速见效的自动化工具实施，而忽略文化和组织变革，这一点并不意外。
第 2 章 康威定律为何如此重要
[康威定律]让我们不断追问：“是否会因为组织结构而导致一个更好的设计无法实现？”
——梅尔·康威，摘自论文 Toward Simplifying Application
Development,in a Dozen Lessons
理解并使用康威定律
“如果系统的架构和组织结构不一致，那么组织结构将成为赢家。”Malan 是想提醒我们组织在设计产品时往往要匹配或模仿真实的组织沟通结构。这一点无论是内部研发还是由外部供应商提供，对于任何组织设计和构建软件系统，都具有重要的战略意义。
为什么组织难以发现或者保持特定的架构呢？康威在他 1968 年发表的文章中给出了一些线索：“对于任何一个特定的团队或组织，那些必要的沟通路径不存在，导致了一系列可替代的设计方案难以有效落地。”
组织内部的沟通路径（无论是否和正式汇报线一致）严重制约了组织所能设计的解决方案的类型。
逆康威定律
我们的研究支撑了被称为“逆康威定律”的方法，即组织需要通过团队和组织结构的改进来实现预期的软件架构。目标是组织结构能够赋予团队完成从设计到部署的工作的能力，而无须团队之间进行高频沟通。
有利于团队协作流程的软件架构
· 松耦合：组件不强依赖于其他组件。
· 高内聚：组件拥有清晰的职责边界，并且它们的内部元素强相关。
· 清晰合理的版本兼容性。
· 清晰合理的跨团队测试。
通过控制团队规模，我们得以达成 MacCormack 和他同事提出的“如果想要一个架构易于理解，那么就应该控制模块大小，并尽可能地减少设计变更的波及范围，从而让架构对于贡献者（Contribution）更加友好”。换句话说，我们需要通过团队优先的软件架构来最大化人的能力和产出。
组织设计依赖于技术专家
如果我们认可康威定律中描述的分形的力量（也就是在架构和团队组织之间），那么我们也必须承认任何能够决定工程团队结构的人都会强烈地影响软件系统架构。这里存在一个康威定律的逻辑推论，用 Ruth Malan 的话来说就是：“如果我们让管理者来决定哪些团队开发哪些服务，那么就相当于我们默认让管理者来决定软件架构。”
组织设计和软件设计实际上代表了一个硬币的两面，两者都依赖于一群经验丰富的人员来推进实施。Allan Kelly 对于软件架构师职责的观点进一步拓展了这种思想。
我从未像现在这般坚信，对于那些声称要成为架构师的人来说，技术和社交能力缺一不可。他们需要理解人，并在一个社会架构中工作。他们同样需要一个远超单纯技术领域的职责，在组织结构和人事方面拥有一定的话语权，比如让他们同时兼任管理者。
限制非必要沟通
康威定律的一个核心内涵指出，并非所有的沟通和协作都是有价值的。因此，定义“团队接口”并设定预期，哪些工作依赖于紧密协作，而哪些不需要，这是非常重要的。很多组织认为沟通总是越多越好，但事实并非如此。
Mike Cohn 作为 Scrum 产品开发方法的创始人之一，提出了一些问题，来评估组织内团队之间沟通的健康度：“这种架构是否最小化了团队间的沟通路径？这种架构是否鼓励团队进行沟通？”
从逻辑上讲，根据软件架构设计，如果两个原本不应该彼此沟通的团队正在进行沟通，那么一定是哪里出了问题。是不是 API 设计得不够好？是不是平台不合适？是不是组件存在缺失？如果我们能够保持团队间低频沟通，甚至是在零沟通的前提下依然可以安全、有效和快速地构建和发布软件，那么我们就应该这样去做。
团队内部高频沟通，两个合作团队之间可以保持中频沟通，而大多数团队间应该做到低频沟通。
有些时候，两个或多个团队感觉需要围绕软件进行沟通，纯粹是因为他们各自负责的系统代码托管在同一个版本控制库里面，或者是这些代码属于同一个应用或者服务。但是这些部门在逻辑上应该是彼此独立的。当这种情况发生时，我们需要使用“破裂面”模式（这一点将在第 6 章介绍）把软件拆分为更小的部分，并纳入独立的版本控制库中。
这时我们往往不经意间就会陷入一种需要跟每个人（也就是将提取有用信息的责任推给了消费者）进行沟通才能完成工作的沟通和交互模式中。从康威定律的视角来看，这将会给软件系统带来意想不到的后果，特别是在缺少模块化设计的子系统之间。
小心那些流于表面的康威定律
康威定律告诉我们，组织的产品设计会受到沟通结构的制约，导致这些产品设计成为沟通结构的复制品。因此，我们需要注意共享工具对于团队交互模式的影响。如果我们希望加强团队合作，那么共享工具能帮助我们达成这个目标。如果我们希望在团队间建立清晰的职责边界，那么独立工具（或者相同工具的不同实例）也许是更好的选择。
总之，不要在脱离团队内部关系优先的前提下，盲目地为整个组织选择单一工具。用一句话来概括就是，独立团队使用独立工具，协作团队使用共享工具。
说得严重些，出于管理方便和减少人员投入为目标的常规组织结构调整会让组织有效地构建和运维软件系统的能力荡然无存。忽视康威定律、团队认知负荷和相关的动态风险来进行组织结构的调整，就好比让一个小孩子来做心脏外科手术一样，往往是毁灭性的。
总结：康威定律对于有效的技术团队设计至关重要
快速流动需要限制团队间的沟通。团队协作对于开发中的灰色地带非常重要，尤其是那些需要探索和专业度才能有所进展的领域。但对于执行而非探索领域来说，沟通就成了不必要的开销。
实现软件架构（以及与之相关的好处，比如交付速度或者故障恢复时长等）的一个关键方法就是使用逆康威定律：设计团队来满足理想的软件架构。
第 3 章 团队优先的思维方式
，表现最突出的团队“之所以能够取得非凡的成就，不仅仅是因为团队成员的个人素质，还在于这些成员凝聚成了一个整体”。
让小而美的长期团队成为标准
在大多数组织中，一个有效的团队最多由 7 ～ 9 个人组成。以亚马逊著名的“两张比萨”团队为例，他们软件团队的规模是只需要两张比萨饼就能喂饱全体成员。这一人数限制也是 Scrum 框架所推荐的，源于对群体认知和信任的进化限制，也就是我们所熟知的邓巴数字（以人类学家罗宾·邓巴命名）。邓巴发现 15 是一个人可以信任人数的极限，而其中只有 5 个人能获得深入了解和信任。
当快速地交付变更时，确保对高度信任的不断追求是至关重要的。高度信任正是驱动团队创新和实验的源泉。如果信任缺失，或者由于组织变大而不断降低，交付的速度和安全将受到影响。
人类学研究表明人与人之间的关系类型和深度存在明显的限制：
· 大约只有 5 个人，我们能与之保持密切的个人关系和工作记忆。
· 大约只有 15 个人，我们能与之产生深度信任。
· 大约只有 50 个人，我们能与之建立互信。
· 大约只有 150 个人，我们能记得他们。
团队需要信任来维持高效运作，但是如果团队规模变得太大，以至于难于维持必要的信任水平，那么组织就不能像之前小团队那样高效了。
团队需要时间磨合来实现高效。通常团队需要花费 2 周到 3 个月甚至更长的时间来形成一个有凝聚力的集体。
给一个团队添加新成员并不会立即提升团队的容量（这就是著名的布鲁克斯定律）。事实上，在初始阶段，这样做很有可能会降低团队的容量。需要一段时间来让人们适应新的环境，但是在新人加入后，团队内部的沟通路径也会因此显著增加。不仅如此，对于新老成员来说，为了理解和适应彼此的观点和工作习惯，他们在情感上需要适应过程（Tuckman 团队开发模式的“激荡期”阶段）。
Tuckman 模型描述了团队在四个阶段上的表现。 1.组建期：团队刚刚建立。 2.激荡期：解决最初的个性和工作方式上的差异。 3.规范期：共同演进标准工作方式。 4.执行期：达到高效能状态。
团队所有权还能够让团队在多个“视域”中思考，从探索阶段到开发执行阶段，来更好地维护软件及其活力。Jez Humble、Joanne Molesky 和 Barry O’Reilly 在他们合著的《精益企业》（Lean Enterprise）一书中指出，视域 1 覆盖了产品和服务不远的未来，同一年内可以交付的结果；视域 2 覆盖了接下来的几个周期，产品和服务的范围不断扩大；视域 3 覆盖了接下来的几个月时间，需要通过试验来评估新服务、产品和特性的市场准入和适配活动。
让多个团队改动相同的系统或子系统的问题在于，没人负责所有的改动及其带来的混乱结果。然而，如果一个团队负责系统或子系统，并且团队成员可以自主地规划他们的工作，那么团队面对短期改动时就能做出明智的选择，因为他们知道在未来的几周里他们要花时间来移除不好的修改。这些不同的时间范围的意识和所有权可以帮助团队更加有效地关注代码。
软件系统的每一个部分都需要有明确的单一负责团队。这就意味着不能在组件、库或代码层面存在共享所有权。
团队应该是交付的基础，而非个人。如果遵循团队优先方法，我们需要确保团队中的每个人都具备这样的思维方式。这对于有的人来说可能有些陌生，但只要有正确的引导和充足的时间来学习，很多人都能接受这种思维方式。
为了促成团队协作，团队成员需要将团队需求置于个人需求之上，他们需要做到：
· 按时参加站会。
· 保证讨论和调查事项走上正轨。
· 聚焦于团队目标。
· 在开始新工作之前帮助其他团队成员解决阻塞事项。
· 辅导新团队成员和缺乏经验的成员。
· 避免陷入“谁赢谁输”的争论，与此相反，认可探索新的选项。
《转危为安》（Out of the Crisis）一书的作者、精益生产运动的关键人物爱德华·戴明博士的管理 14 条指出要“废除年度绩效考核和目标管理”。在现代组织中，奖励个人绩效往往会导致糟糕的结果，并损害员工的行为。
良好设计的边界可以最小化认知负荷
良好设计的边界可以最小化认知负荷
约束团队职责以匹配团队认知负荷
在现代软件交付中，最不为人熟知的增加摩擦的要素就是团队不得不处理越来越大而复杂的代码基线。这给团队带来了无限的认知负荷。
对于软件交付团队来说，在认知负荷方面，团队优先方法意味着要限制软件系统的大小，从而匹配团队的期望工作状态。也就是说，组织不应该允许一个软件子系统成长为超出团队所负责的软件的认知负荷。
在 1988 年，心理学家 John Sweller 将认知负荷定义为“工作记忆中使用的脑力劳动总量”。Sweller 定义了三种不同的认知负荷。
· 固有认知负荷，与问题领域的基本任务相关，比如：Java 类的结构是什么样的？我要如何创建一个新方法？
· 额外认知负荷，与任务处理的环境相关，比如：我要如何重新部署这个组件？我要如何配置这个服务？
· 相关认知负荷，与那些需要格外关注学习和高性能方面的任务相关，比如：这个服务是如何与 ABC 服务进行交互的？
一般来说，为了高效地交付和运维现代软件系统，组织应该试图最小化固有认知负荷，比如通过培训、良好的技术选型、招聘合适人员、结对编程等方式来实现。同时，要尽量消除额外认知负荷，尤其是那些没有意义的、冗余的任务和命令，这些保留在工作记忆中没有太大价值并且通常可以被自动化任务取代。最后，为相关认知负荷预留更多的空间，这也就是“增值”思维的所在。
如果我们将一个超出团队认知负荷的系统强加到团队的职责中的话，团队就无法像一个高效能单元一样运转，并且表现出一种松散组织的个体行为，每个人都在试图努力完成个体任务，却毫不关心是否能带给团队最大的收益。
对于非常看重高效能团队协作的环境来说，有必要在设计任务结构时通过委托子任务的方式让它变得不那么难以实现，这样一来注意力就会收敛到必要的任务上，团队协作也就顺利进行了。
评估认知负荷的一个简单而快速的方法就是以一种非评判的方式问团队：“你觉得你的工作效率高吗？你能及时响应那些交给你的工作吗？”
虽然这不是一个准确的衡量标准，但答案有助于判断团队是否感到超出负荷。如果答案是否定的，组织可以应用一些启发式方法来理解认知负荷是否过高以及为什么过高。如果确实是这样的话，组织需要采取必要的步骤来降低认知负荷，从而确保团队能够再次变得有效和主动。顺便说一句，这将增加团队内部的激励水平，因为团队成员能够看到更多工作的价值和目的。
在度量认知负荷的时候，我们真正在意的是领域复杂度，也就是说，我们试图通过软件解决的问题有多复杂？领域是相比软件大小更加适用的概念。
包括构建、持续集成、持续交付、自动化测试和基础设施自动化等。团队需要不断应对大量工作和上下文切换，这些任务同时来自不同的产品线。团队普遍认识到他们缺乏必要的领域知识，但是没有时间投入研究。事实上，他们绝大部分的认知负荷都是额外的，几乎没有空间留给固有认知负荷和相关认知负荷。
最开始，要识别每个团队必须处理的不同领域，并将其归类为简单（大多数工作都有一条清晰的行动路径）、复杂（需要分析变更，为了获取有效的解决方案可能需要几次迭代）、非常复杂（解决方案依赖于大量的试验和探索）。
第一个启发是，可以将每个领域分配给单一团队。
第二个启发是，一个 7 ～ 9 个人的黄金规模团队应该可以应对二三个“简单”领域。因为这些领域非常流程化并且响应更加机械化，所以在领域间切换的成本更可以被接受。在真实环境下，这种简单领域可能是一个老旧软件系统，仅仅有一些微小的、偶发的、简单的改动。不过，这样做的风险是会消减团队成员的积极性，毕竟他们都在处理例行工作。
第三个启发是，如果一个团队已经负责了非常复杂的领域，那么就不应该再给他们分配更多领域，即便是一个非常简单的领域。
最后一个启发是，避免单一团队负责两个复杂领域。
软件设计并不是要在单体架构和微服务架构之间做出选择，而是要适配团队的最大认知负荷。
为了增加团队负责的软件子系统或领域大小，可以通过降低固有认知负荷和额外认知负荷来优化团队工作生态，从而最大化团队认知容量。
· 提供一种团队优先的工作环境（虚拟或物理的），你将在本章后面看到更多相关内容。
· 通过缩减会议、减少邮件、指派专门的团队或个人来支持答疑等手段来尽量少地打断团队日常工作。
· 变革管理形态，沟通目标和产出而非观察过程，McChrystal 在《赋能：打造应对不确定性的敏捷团队》中称之为“着眼，放手”。
· 提升其他使用你所在团队提供的代码或 API 的开发者体验质量，可以编写良好的文档，提供一致性、易用的用户交互设计和其他开发者体验实践。
· 使用一种专门为降低团队认知负荷而设计的平台来构建软件。
设计“团队 API”和促进团队交互
团队 API 包括如下内容。
· 代码：团队生成的运行时端点、库、客户端、UI 等。
· 版本：团队如何在代码和服务中识别变更，比如使用语义化版本号[SemVer]作为一种“团队承诺”，不去破坏已有内容。
· Wiki 和文档：特别是团队所负责软件的操作指导。
· 实践和原则：团队倾向的工作方式。
· 沟通：团队远程沟通工具，比如聊天工具、视频会议等。
· 工作信息：团队在做什么，即将做什么，以及中短期的整体优先级。
· 其他：任何其他团队与团队交互的内容。
在 API 管理书里面也提到贝索斯要求所有人使用设计外部 API 的理念/标准设计内部 API
在云服务商 AWS，他们采用了一种更严格的团队 API 方法，其 CEO Jeff Bezos 近乎偏执地坚持团队间独立。比如，任何一个 AWS 团队必须假设所有其他团队都是潜在的服务不可用攻击者，从而要求服务级别的限额和限流。
促进团队信任、认知和学习
提供时间、空间和资源来使能和鼓励不同团队中具备相似技能和经验的员工凑到一起学习，从而提升职业竞争力，这是至关重要的。
为了帮助团队构建信任、认知和学习新事物的文化，有两种核心方法。（1）一个是有意设计的物理和虚拟环境。（2）另一个是让大家远离办公桌，参与到实践社区和组织中（一群兴趣相同的成员定期、自愿地聚在一起学习和分享，比如相关的兴趣领域、内部技术大会等）。
为了实现高效软件交付，办公室设计需要适应各种工作模式：个人专注工作模式、团队内协作模式及跨团队协作模式。
物理工作环境给高效能团队交互能力带来了至关重要的影响。成功的组织都会花时间和资金为他们的员工打造一个舒适的物理空间。
这种办公布局的设计经过了深思熟虑，小队或者部落的成员可以轻而易举地识别出其他团队的工作（比如看板墙、在制品限制、状态雷达等）并且快速学习新的方法。有些组织可能走得更远，把整层的办公空间划分为独立的业务流，促进快速流动和团队间的简单协作。
技术团队和非技术团队放在同一层的同一个区域，这样有助于打破部门壁垒，从而共享相同的目标和用户。统一销售、产品、服务和技术团队使用的设备，从而更广泛地共享工具并以相同的方式工作（例如，所有的销售和服务团队同事都有笔记本电脑，你也不必为了得到一台 MacBook 而争当明星程序员）。
· 清空桌面规则：提供保管箱用于存放个人物品，鼓励人们在办公室里四处走动，坐在他们喜欢的地方来创造价值，而不是局限于固定团队的固定工位。
· 技术约束：办公桌被设计为仅支持一个显示器，这样就可以看到坐在对面的人，进行更自由的交互。技术人员拥有两三台显示器是很普遍的事情，所以这种设计并不常见。但这是一个很有趣的例子，通过限制使用一些技术来打造数字化组织，从而为了目标更高效地协作。甚至桌子腿都是凹进去的，营造出一种长凳效果，这样一来人们就可以在工位之间自由移动而不会绊到腿，方便和其他人坐在一起。
· 白板墙：为了鼓励更多非正式、创意性沟通，墙壁被设计成可书写的，这样无论是在走廊中还是汽车旁都可以边画边讨论。大多数会议室采用玻璃设计，这样人们就能看到谁在里面，并决定是否需要进去。我们还设计了很多非正式的会议空间，沙发、软椅等，大家可以随时跟同事坐下来聊天，而不用提前预订会议室。
· 活动空间：在所有的建筑中都设计有活动空间，这样我们可以聚在一起并且甚至邀请本地社区参与进来，共同组织活动和会议，帮助我们了解组织外的人并和他们一起工作。
有效的远程办公不仅在于要引入必要的工具，团队还需要就工作时间、响应时间、视频会议、沟通语气和其他实际方面的基本规则达成一致。
总结：控制团队认知负荷并促进团队交互来实现快速交付
总结：控制团队认知负荷并促进团队交互来实现快速交付
在快速变化和具有挑战性的环境中，团队比个人小组更有效。成功的组织——从美国军队到大大小小的公司——把团队作为完成工作的基本手段。团队通常是小巧、稳定和长期存在的，允许团队成员花时间和空间来打磨他们的工作模式和团队动力。
重要的是，由于团队规模（邓巴数字）的限制，单个团队能够承受的认知负荷有一个有效的上限。这强烈表明任何团队负责的软件系统大小和领域复杂度都存在一个上限。团队需要全权掌控他们所负责的系统或子系统。处理多个代码库的团队往往缺乏主人翁意识，特别是缺乏保持系统健康的理解和意识。
团队反模式
第一种反模式是临时起意的团队设计。它包括团队规模巨大和沟通过载带来的额外成本，于是将一个大规模团队拆散，或者建立一个新团队来负责全部商业软件和中间件的维护，又或者仅仅因为某次数据处理导致的生产崩溃事故而构建了一个 DBA 团队。当然，针对这些场景应该采取一些行动，但是如果不思考更广泛的团队间交互管理场景，那些看起来很自然的解决方案很有可能会拖慢交付速度，并破坏团队自治能力。
第二种反模式是频繁调动团队成员。这导致了团队仅仅为项目而组建，在项目完成后就立即被打散，也许只留一到两名工程师来“加固”或维护应用。看起来这样体现了高度的灵活性，以及更快速地应对交付日期的响应能力，但是构建新团队和反复切换上下文的成本被低估（或者压根不在项目的预估之中）。虽然一台电脑无论在哪个房间里都能起到相同的作用，但是将一名工程师纳入两个不同的团队能发挥的作用可大不一样。
在给定技能、约束、文化及工程能力成熟度、预期软件架构和业务目标的前提下，哪类团队拓扑有助于更快速、安全地交付？
为变更的流动而设计
Spotify 的技术人员被安排到小型、跨职能的自治小队（Squad）中，每个小队由 5 ～ 9 个人构成，他们拥有长期、稳定的使命。几个工作在相近领域的小队组成一个部落（Tribe），也就是一组关系密切的小队。部落中的小队熟悉其他小队的工作方式，并在部落内部紧密协作。
让软件开发团队暴露在线上运行环境中的组织相比竖井式的竞争对手来说，可以更快速地解决用户问题和运营故障（参见图 4.2）。
“我们必须……构建跨职能的交付团队，让它可以独立地完成设计、开发、测试、部署、运维系统等一系列活动。”重视线上运行系统反馈的组织，不仅可以更快地改进软件，而且可以更快地响应用户。
DevOps 和 DevOps 拓扑
DevOps 拓扑反映了两个核心理念。（1）没有一种通用的组织架构方法来让 DevOps 获得成功。任何一个给定拓扑的适用性和有效性都取决于组织所处的场景。（2）部分拓扑是阻碍 DevOps 成功的反模式，它们忽略了甚至同 DevOps 的核心理念背道而驰。简而言之，并不存在所谓“正确”的团队拓扑，但在组织中存在很多“错误”的团队拓扑。
成功的团队模式
团队保持自主性的关键在于不被外部依赖所阻塞，也就是说新特性不能因为某些团队掌控范围之外的事情发生而处于停滞状态。举个例子，当产品团队交付一个特性的时候，确保独立的质量保障团队有时间进行功能评估和验收，这是一件极其困难的事情。团队拥有不同的工作量、优先级和问题，在构建和运行软件系统的时候有太多不确定的事情，影响多个团队按照预定义的时间节点来协作完成同一工作流。固执地坚持这种方法难以避免时间浪费和交付延期。
产品团队承担了巨大的快速交付压力，但如果他们所使用的系统无法提供必要的自主性支持，那么就导致了日益增长的摩擦。
全面采用 SRE 将是对传统的 IT 运维方式的颠覆，因为 SRE 更加关注“错误预算”（Error Budget，可接受的累计宕机时长），并且 SRE 团队有能力将低质量的软件回退给软件开发团队。
总结：根据现状选择团队拓扑并持续演进
当扩大产品规模、采纳新技术及响应新的市场需求时，团队结构和职责会发生相应的变化来适应现状。但这并非经过深思熟虑的团队拓扑，也无法达成令人满意的速度和效率。
因为这种团队结构调整的决定常常是由某个单独的团队做出的，并没有全面考虑组织级的各种因素，比如技术和文化成熟度、组织规模、软件规模、工程文化及团队间依赖等。因此它只是对局部和短期问题的响应，无法适应不断出现的新问题。
第 5 章 四类基本团队拓扑
如果我们将团队类型的数量缩减为四类基本团队拓扑，这个问题就迎刃而解了。
· 流动式团队
· 赋能团队
· 复杂子系统团队
· 平台团队
流动式团队
流动式团队对应一条单一、有价值的工作流，这也许是一个产品、一项服务、一组功能特性、一个用户故事或者一组用户画像。更进一步地，团队有能力做到快速、安全和独立地构建和交付用户价值，而不需要移交给其他团队来完成部分工作。
流动式团队是组织中最主要的团队类型，其他基本团队拓扑的目标都是为了减轻流动式团队的负担。我们在本章后面会提到，比如赋能团队补齐了流动式团队所需的能力短板，负责预研和试验并建立成功实践。而平台团队则是为了降低流动式团队的认知负荷，他们屏蔽了底层细节（比如初始化环境、监控和部署等），提供了简单、易用的服务。
测试开发工程师把工程效能团队和工具团队的成果带到了各个开发团队，支持和促进最佳实践的实施。
很重要的是，不要试图在团队中为每个角色配备一名专职人员，否则团队中至少要有九名成员才能完全覆盖这些能力。
过去很多软件交付框架采用“产品团队”或“特性团队”指代负责端到端的软件交付价值增量的团队。现如今很多理由表明流动相比产品或特性来说更加贴切。将团队的职责定义为流动，有助于强化组织级对流动性的关注度，从而确保流动的顺畅无阻。
团队应该具有持续设计能力，“把服务、反馈、失败、学习等方面的创新视为头等大事
一个高效能的流动式团队应该有哪些行为和产出呢？
· 流动式团队旨在为特性交付建立一条稳定的工作流。
· 流动式团队能够根据最新变更的反馈不断调整方向。
· 流动式团队采用试验性手段带来变革，并从中不断学习和调整。
· 流动式团队几乎不存在同其他团队的工作移交。
· 可以用可持续的变更流程来评价流动式团队（兼顾一些技术支持和团队健康度指标。）
· 流动式团队必须腾出时间来提升代码质量（有时候也说成处理技术债），从而确保代码易于变更和维护。
· 流动式团队应该主动并定期接触支持型基本拓扑团队（复杂子系统团队、赋能团队、平台团队）。
· 流动式团队的成员感觉他们已经具备或者正在逐步具备 Daniel Pink 所说的“自治、精通、目标”这三种知识型工作者的核心能力。
赋能团队
高效能团队通过不断提高能力而保持领先。但是负责端到端的流动式团队总是工作在交付压力之下，需要快速交付和响应变化，哪有时间去调研、探索、学习和实践新技能呢？赋能团队由特定技术领域或产品领域的专家组成，可以由他们来提供帮助。赋能团队进行调研工作，尝试不同方案，并在工具、实践、框架、技术栈等方面给出高质量的建议。这使得流动式团队不必付出太多努力就能获得能力提升（根据我们的经验，这样的努力及其影响对团队其他成员来说往往会被低估 10 ～ 15 倍）。
赋能团队需要较强的沟通协作能力，他们需要识别流动式团队遇到的问题和不足之处，并相应地提供有效的指导。Jutta Eckstein 称呼他们为“技术咨询团队”，因为不论他们来自组织内部还是组织外部，他们提供的是指导而不是去具体执行。
赋能团队的使命是通过提升流动式团队的能力来提高其自主性，所以需要聚焦于解决流动式团队遇到的问题，而非推广自己手中的解决方案。
赋能团队要主动了解流动式团队的需求，在深入协作时建立定期检查点和联合沟通机制。
赋能团队既要传播好消息（比如，“这里有一个新的 UI 自动化测试框架，可以将我们的测试脚本代码减少 50%”），也不能遮掩坏消息（比如，“当前我们广泛使用的 JavaScript 框架已经不再被维护了”）。这样才能在合适的时候引入特定技术，并在合适的时候舍弃它们。
赋能团队由精通软件工程的专家组成，熟悉应用开发、构建、发布、测试等各个方面。至关重要的是，他们不仅带来了新技术和新工具，而且致力于分享最佳实践和培训团队。如果开发团队在文化和技能方面还没有做好准备，那么急于引入新的构建和部署工具会适得其反。我们发布了“团队宪章”，向整个组织阐述我们的理念和承诺。
我坚持认为，工程赋能团队从工作的第一天起就要为离开做准备，以免他们所服务的团队依赖于他们。我们公开了所做的全部工作，以便让所有开发团队可以学习和具备自行操作的能力。为此，我们演示了编程过程、录制了样例、邀请了其他团队参加我们的演示。据估计，我们的团队只有 1/4 的时间花在了实现解决方案上，而把其他的时间都用来分享知识。
赋能团队和实践社区（Communities of Practice，CoP）都能提升其他团队的认知和能力。他们的区别在于，赋能团队成员每天的工作就是赋能，而实践社区是由来自各个团队的对某一方面感兴趣的人员组成的松散组织，每一周甚至每个月才会搞一次活动，分享实践并改进工作方法。
复杂子系统团队
复杂子系统团队负责构建和维护系统中严重依赖专业领域知识的子系统。相应地，大多数团队成员都必须是这个领域的专家，这样才能理解和变更子系统。
复杂子系统团队与传统的组件团队（当一个子系统已经或期望被多个团队复用时创建）的关键区别在于，只有当某个子系统依赖于大量特定领域知识的时候才会建立复杂子系统团队，这完全是由团队的认知负荷驱动的，而并非出于组件共享的目的。
复杂子系统团队的任务是把需要特定领域专业人员专业能力的开发工作从流动式团队的职责中剥离出来。
平台团队
平台团队的目标是使流动式团队能够以高度自治的方式交付工作。流动式团队在生产环境中拥有构建、运维、修复应用的所有权限。平台团队提供的内部服务使得流动式团队无须开发底层服务，降低了认知负荷。
衡量平台团队的价值，要看他们提供给产品团队服务的价值。”
实际上，平台团队应该聚焦于提供少量、高质量的服务，而不是提供大量存在可用性和质量缺陷的服务。
Don Reinertsen 建议为这些内部基础设施和服务定价，向使用它们的团队收费，以避免人人都要求高等级服务。例如，可以按团队或服务统计云上基础设施的成本费用。
平台团队自己也应该是他们所提供服务的用户（如果适用的话），同流动式团队和赋能团队并肩战斗，可能的话，也应该依托于其他平台团队负责的下层平台。
在大型组织中，平台由若干基本类型团队组成：流动式开发团队、复杂子系统团队、下层平台团队。
2013 年以前，软件开发项目的费用计入资本支出（CapEx），而 IT 运维工作的费用计入运营支出（OpEx），这使得开发团队和运维团队被人为地割裂了。根据要求，软件开发团队 90%的精力必须放在资本支出上，于是他们别无选择，必须不断开发新东西，而没有精力修复问题和改进用户体验。开发团队不是为用户服务的，而是为产品管理层服务的。这种情况必须改变。
因此，从 2013 年起，我们把所有人员都纳入运营支出。所有人的工作目标都变成为公司赢利而奋斗。在这种模式下，大家比以前更贴近用户，考虑用户的诉求，而不再是仅为产品管理层工作。事实上，全部计入运营支出这种模式，让我们有了明确的预算约束：我们有大约 800 名固定员工，没有计划扩大规模。稳定的人员数使我们持续地关注我们的软件应用和服务。
我们采用了精益思想的方法进行流程设计，并将流动引入组织的其他领域，因此我们现在的财务和销售部门都在使用有 WIP（Work-In-Progress，在制品）限制的看板。销售部门甚至对错失的销售机会开始进行无指责的故障复盘！
避免变更流程中的团队竖井
但是这样的团队不应该出现在变更工作流中，而是应该为流动式团队提供服务。一个工作流中的不同阶段和任务应该由同一个团队负责，避免不同团队间的交接。
一个优秀的平台应该“够用就好”
一个优秀的平台要提供标准、模板、API 及经过验证的最佳实践，帮助开发团队快速创新和高效工作。
降低使用者的认知负荷（详见第 3 章）是一个优秀平台的关键评判标准之一。
良好的用户体验和开发者体验能够让平台充满吸引力，同时能够让平台的功能特性和 API 层面保持一致。用户操作手册及其他文档可以覆盖所有功能（无须过度冗长）且实时更新，聚焦达成特定任务目标的方法，而不是面面俱到地罗列平台所有细节。
因此，为了帮助开发团队用户更高效地使用平台，我们需要做到：（1）把内部平台视为线上/生产系统，计划和管理维护时间；（2）引入软件产品管理和服务管理技术。
平台团队几乎肯定会制作用户画像，比如网页开发工程师 Samir、测试工程师 Jennifer、产品负责人 Mani、服务体验工程师 Java 等。用户画像方法将帮助平台团队了解并聚焦典型用户的需求、痛点和目标。平台团队的成员应该与开发团队用户定期沟通，了解他们的需求。
将常见的团队类型转换为基本团队拓扑
如果一个工具团队最初没有清晰的定位或时间限制，那么时间长了很容易成为一个竖井式的工具维护团队。
在传统方式下，很多组织都让一个单一的跨服务团队支持线上/生产环境的应用和服务。在变更速度不那么快和系统复杂度不那么高的时候，这种模式能在支持团队的人数或者技能方面帮助组织降低成本。
然而，随着软件系统持续不断地快速变更，那些成功的组织就会开始重新思考支持团队的组织方式和定位，以便让端到端的变更流程更快、更安全。IT 支持模型之所以长期有效，主要原因有两方面：（1）支持团队的设置要有利于变更流程，（2）组建跨团队的应急小组来处理线上服务故障。
应该为其他团队提供支持，帮助他们变得更高效，而不是替他们做设计和技术上的决定。在 Forsgren、Humble 和 Kim 的 Accelerate 一书中有写道，“架构师应该与他们的用户密切合作，这些用户就是那些构建和运维系统的工程师，组织可以通过这些系统完成使命，架构师可以帮助用户实现更好的产出，向用户提供获得产出的工具和技术。”
兼职的、聚焦于架构的赋能团队的主要工作内容是，让各团队所负责部分之间的有效 API 定义得最合理和高效，让团队间的交互符合康威定律。（我们将在第 7 章进行详细讨论。）
第 6 章 选择团队优先的边界策略
然而许多组织在划分团队职责边界方面遇到了很大的问题。通常很少考虑团队边界的可行性，这会导致团队缺乏归属感、消极怠工和越来越慢的交付速度。
软件边界或“破裂面”
尽管每种类型的单体系统都带有一定的缺陷，但是把软件拆分给各个团队时也有一些值得注意的隐患。拆分软件会降低软件不同部分之间的一致性，并可能导致多个子系统之间产生异常重复数据。如果我们没有足够小心地保持用户体验的一致性，那么跨软件的多个组成部门的用户体验就会下降。此外，如果将软件拆成分布式的系统，也会引入额外的复杂度。
破裂面是软件系统中的一个天然缝隙，它允许将系统很容易地分成两个或多个部分。
破裂面：业务领域限界上下文
识别限界上下文需要大量的业务知识和专业技术知识，因此在开始的时候犯错是正常的。
另一个天然的破裂面是系统的不同部分需要以不同的频率变化的地方。
按系统中通常以不同节奏变更的部分进行拆分，可以使它们变更得更快。现在，企业需要推动的是变革的速度，而不是为单体系统中的所有组件强制推行一致的速度。
我们认为，要让团队高效地沟通，可以选择全员集中办公（所有团队成员都处于同一物理空间中）或真正的远程优先方案（有明确约定的沟通渠道，如通信和协作应用，团队中的每个人都有权使用和查询）。如果这两个办法都不可行（全员集中办公或远程优先方案），那么最好根据不同团队所在的位置将单体系统拆分为对应的独立子系统。使用这种方法，这个组织就可以利用康威定律，使系统架构与现实中的通信约束保持一致。
在松耦合的系统架构（不是单体系统）中，拥有真正的持续交付能力实际上会降低频繁部署小型变更的风险。
在特定类型的系统中，区分性能级别是有益的。当然，性能应该始终是每个系统的长期关注点；并且应该尽可能地对其进行分析、测试和优化。
然而，只有部分应用需要应对大规模的需求高峰（如在最后一天提交的年度税务报告），要求一定程度的扩展和故障恢复能力，而系统的其他部分则并不需要。
这些常见的技术驱动的拆分类型通常会引入更多的约束，减少而并非改进工作流。一般来说，这是因为独立的团队自治性较差，当产品相互依赖的时候，每个团队对工作整体的可见性较低，团队间的沟通路径没有团队内部的通畅。
随着系统的迭代和功能的扩展，它们的客户群（内部或外部）也在增长和变得多样化。一些用户组将依赖于给定的功能子集来完成工作，而其他用户组则需要另一些子集。在分层定价的产品中，子集是按设计内置的（高付费客户比低付费或非高付费客户可使用更多的功能）。
我们重视工作中的协作和自主性，因此将自己组织成“矩阵产品团队”，即完全负责某一产品领域并坐在一起的多功能团队。我们的产品团队通常由四个开发人员、一个产品经理、一个 QA 和一个 UX/UI 设计师组成。我们的团队直接与客户和利益相关人员沟通：他们跟踪支持电话；他们设计、构建和衡量解决方案的影响；他们对交付方案的质量负责。
自动测试技术的投资和良好的运营聚焦有助于团队理解他们正在构建的软件。通过采用我们称之为“一致自治”（Aligned Autonomy）的跨职能产品团队，各个团队对其所负责的软件服务的良好责任心逐渐展现，这样反过来既让我们实现了快速的变更流程，也让我们能够最小化停机时间。
总结：根据团队认知负荷来确定软件边界
最后，我们需要意识到不同类型的单体系统可能会阻碍流动并导致团队之间出现不必要的依赖。虽然我们通常认为系统架构是一个整体，但即使在系统架构已经模块化的情况下，还有其他更微妙的耦合方式（如共享数据库、联合构建和/或发布等）。正如 Amy Phillips 所说的那样，“如果你采用了微服务架构，但是你在发布之前需要等待所有的微服务开发完成后再进行端到端的组合测试，那么这其实就是一个分布式的单体系统。”
在考虑子系统边界时，主要目标应该是找到与业务领域限界上下文结合的软件破裂面，这是因为大多数的限界上下文都将映射到组织中天然存在的业务变更流。反过来，这也意味着业务领域边界可以与流动式团队对齐，有助于聚焦在跨组织的价值流上。
第 7 章 团队交互模式
当团队在某个领域获得了更多的经验、新的技术成熟可用、组织规模变大等情况发生时，团队与其环境间的相互作用就变化了。团队拓扑的选择和调整则促进了这样的变化。有时候，两个团队间可能需要密切合作一段时间，但是 6 ～ 9 个月之后，更独立的运行反而会带来更高效的软件交付。团队拓扑应该根据遇到的挑战而不断调整和演化。同时，如我们在第 I 部分中介绍的那样，始终考虑团队职责和软件架构。
这些团队交互模式定义了组织中各团队间的预期行为模式，简化了团队交互，可用于识别不合理的团队边界。
良好定义的交互模式是高效能团队的关键
在很多组织中，未良好定义的团队交互模式和职责是挫败感和低效率的源头
当我们思考任意团队之间的关系时，首先要明确的是，需要与另一个团队协作才能完成某个目标，还是仅仅使用他们的服务（参见图 7.1）
协作意味着显式地共同工作，而服务是指一个团队使用另一个团队提供的某种“服务”。
团队交互的三种核心模式
·协作：与另一个团队密切合作。
·服务（X-as-a-Service）：使用或提供某种服务，而尽量减少协作。
·促进：为提供或者寻求其他团队的帮助而清除障碍。
几乎所有大中型企业都需要三种团队交互模式的组合，而在小型组织中，这些模式的引入速度也远超大多数人的预期。此外，在与不同的团队交互时，一个团队可能使用两种不同的交互模式。图 7.2 以图形化的方式展现了不同的交互模式。
团队应该思考：“我们应该用什么模式与另一个团队交互？我们应该与另一个团队紧密协作吗？我们是否应该提供服务？或者我们应该期待或提供帮助？”
协作：有利于创新和快速探索，但边界不清
当进行大量探索性工作（比如尝试新技术）时，适合使用协作模式。协作模式避免了团队间工作交接带来的大量损耗，因此适合快速尝试新事物。
协作模式依赖于良好的沟通，以及对团队间共同工作的强烈意愿和能力。
可以用两种有效的方法来描述协作模式下团队之间的交互。第一种是两个具备独特专业技能和职责的团队共同完成工作的一部分。在这种协作模式下，两个团队依然聚焦于他们各自的职责和专业领域，并且在一个特定活动子集中进行协作。
第二种协作模式的显著特征是两个团队几乎融为一体，即便原本两个团队拥有不同的技能和专业领域，但是现在有效地成为一个团队资源池。（小心不要让总人数超过 15 这个邓巴数字。）
根据康威定律，协作模式带来的探索和快速学习也会使两个团队的职责及所负责软件的架构更紧密地融合在一起。如果两个团队的服务或系统需要清晰的、良好定义的接口，那么长期使用协作模式可能不是最佳选择。在短期或者偶尔的协作中建立或优化接口是没问题的，但如果需要两个团队长期协作，那么意味着要么领域边界可能有问题，要么团队职责、技能融合等方面出现了问题。
服务：职责清晰、交付可预期，但依赖有效的产品管理
服务最具挑战的部分已通过早期紧密协作的“发散式”方法得以解决，最终将最有效的解决方案沉淀成一种服务。
只有当服务边界定义良好、服务被正确实现、服务提供方实施服务管理实践时，服务模式才能正常运作。
即便类似底层 XML 格式转换这样一种简单的代码类库（Code Library），也都能受益于产品管理和开发者体验原则。构建和支持 XML 类库的团队需要考虑版本和向后兼容性，提供经过沟通的旧版本类库下的线路、线图，协助使用者迁移到新版本等。对于任何超过一个代码类库的情况，这种服务化的方法都显得非常重要。
选择基本团队结构
如第 5 章讨论的，一个专职架构团队通常是一种需要避免的反模式。然而，在组织中架构团队的职责是通过探索、调优和重塑团队交互模式从而来影响软件系统架构时，少数几名软件和系统架构师构成的小组可以卓有成效。
架构师需要同时具备技术能力和协作能力……他们也需要具备比单纯技术更广的影响力，比如业务策略、组织结构、个人事务等。他们事实上需要的是一个管理者。
选择团队交互模式来降低不确定性并增加流动性
“团队间会进行人员交换，一名团队成员可能去另一个团队待上几天或一周，直到实现一个特性。”Heidi Helfand 也提到，“有意识地安排团队调整，这给大家带来了学习新事物的机会。”
至关重要的是，这种改变是经过深思熟虑的（即便只是一段时间），并且获得了相关人员的赞同、理解和热情。
总结：三种良好定义的团队交互模式
协作：两个团队在一段时间内紧密协作，共同探索新模式、方法和约束。团队共享职责、边界模糊，但问题得以快速解决，并且组织可以快速学习。
·服务：一个团队使用另一个团队提供的某种“服务”，比如一个服务或者 API。如果边界清晰，可以清晰描绘团队职责，则服务使用方团队能够做到快速交付，而服务提供方团队则努力让他们的服务变得尽可能简单、易用。
·促进：一个团队在一定的时间内帮助另一个团队学习和实践新技术方法。团队提供辅助，旨在让另一个团队实现独立工作，同时接受帮助的团队也要有开放的学习心态。
什么样的团队交互是合适的
协作是一件昂贵的事情。没必要的协作尤其昂贵，特别是这种协作可以通过底层平台或者能力来屏蔽依赖。
这种有意识地通过改变团队交互模式来倒逼交付能力发生根本性变化，是强有力的策略技术领导力的本质。
团队拓扑结构的不断演进
协作模式代价高昂但有利于发现新方法，服务模式有利于可预期的交付，因此可以根据不同的软件系统领域和各个团队的情况来设置团队模式。
团队拓扑演进的触发器
这种专业化的强化循环是一种局部优化（快速完成需求交付），通常会给团队的整体工作流带来负面影响，因为工作计划是根据“谁了解什么事情”而并非“我们现在必须要处理的最高优先级任务是什么”制订的。这种专业化造成了交付瓶颈（正如《凤凰项目》和《DevOps 实践指南》一书中所述的）。这种例行任务同样会对个人的积极性产生负面影响。
然而，让这些团队不断成长的前提是赋予他们对于产品完整生命周期的自主性。这意味着没有对外部团队的强依赖，比如等待另一个团队构建新的基础设施。使用内部平台来实现自助申请新的基础设施是一种弱依赖（比方说自服务基础设施环境是由平台团队维护的。）
比如，为了提升测试覆盖率而建立质量保障（QA）团队来负责所有产品的测试活动，从理论上讲，将工作分配给测试人员会更高效。然而，这种做法并不值得推荐，因为引入了一个“职能竖井”，也就是说，所有软件交付团队都需要等待质量保障团队来测试他们的变更。
有两种方法来解决这类多服务集成问题。（1）将下层服务和 API 平台化并组成一个“平台包装”，对流动式团队提供一致的开发者体验，比如提供问题追溯关联 ID、健康检查端点、测试装置、服务级对象和诊断 API 等。这个“外部平台”依然基于下层平台构建，但对于流动式团队而言屏蔽了细节。（2）让流动式团队负责每一项上层业务服务，对运维指标和错误诊断负责，构建和开发“恰到好处”的集成指标和诊断能力，有助于问题发生时进行诊断。控制监控和诊断使得流动式团队可以追溯和改进他们自己的工作流（参见图 8.8）。
自组织设计与开发
良好定义且稳定的团队可以有效地管理软件系统的不同部分，并使用清晰的沟通模式进行交互，组织就可以激活一种强大的策略能力：组织感知。
Gene Kim 和他的同事定义了现代、高效能组织的 DevOps 三步工作法。 1.系统思考：面向整个组织优化快速流动，而非进行局部优化。 2.反馈环路：运维通知和指导开发活动。 3.持续试验和学习的文化：对每个团队交互进行感知和反馈。
将运维视为对开发的输入需要彻底地重新思考这些长久以来独立存在的岗位职责。Designing Delivery 的作者 Jeff Sussna 是这样描述的：“业务通常将运维看作设计的结果，为了做到同理心，你必须有能力去倾听。为了倾听，你需要来自运维的输入。于是运维就变成了设计的输入。”
结论 下一代数字化运营模型
过度追求“特性交付”而忽略了现代软件中人和团队的动态性，导致了员工参与度的下降，特别是在认知负荷已经过载的情况下。
四类团队类型和三种交互模式
四类基本团队拓扑如下。
·流动式：团队聚焦于业务变更主流程，具备跨职能技术，并且不需要等待其他团队，就能够交付大量的增量。
·平台：团队开发底层平台来支持流动式团队的交付。平台在简化复杂技术的同时降低了使用它们的团队认知负荷。
·促进：团队通过一段时间的转型和学习来辅助其他团队实践和变更软件。
·复杂子系统：团队专注于一个特定的子系统，这些子系统对于普通的流动式团队和平台团队来说过于复杂而难以掌握，仅在真正必要的时候才会使用。
这些特定的团队类型组合起来足以满足快速、高效交付软件的需要。然而，四类基本团队拓扑之间的交互模式对于理解和促进高效软件交付同样至关重要。
·协作模式：两个团队共享目标，特别是在探索新技术或方法的时候，对于快节奏的学习来说，这种投入物超所值。
·服务模式：团队使用其他团队提供的诸如 API、工具或者全套软件产品，协作是最小化的。
·促进模式：一个团队（通常是赋能团队）促使其他团队学习和实践新方法。
下一步：如何上手团队拓扑
首先，作为一个组织，需要扪心自问：团队要达成的目标是什么？
· 变成一个高效能团队？
· 高效负责软件的某个部分？
· 专注于满足用户需求？
· 降低不必要的认知负荷？
· 为其他团队提供软件和信息？
坦诚地回答这些问题会引入团队优先方法来提供办公场所、开发工具、可用平台、实际的子系统/领域拆分、团队友好架构、丰富的监控指标等。
从团队开始，能够带来其他使现代软件快速流动的重要能力：工作流一致、平台及额外的支持和增强团队工作的能力。
技术仅仅是平台的一个组成部分，路线图、演进指导、清晰的文档、对开发者体验的关注，以及对底层复杂实现的适度封装，都是面向流动式团队的有效交付平台的关键部分。