You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's turtles all the way down.（一切建筑皆有底座）。
在软件领域，这个比喻意味着每个平台都是基于另一个平台构建的，即便它的底座平台是隐藏和不可见的。
如果底层或下层平台无法稳定运行或者设计上有缺陷，那么上层平台也会变得不稳定，无法提供加速组织内其他软件交付所需的坚实基础。
如果底层平台存在运行漏洞或者性能问题，那么平台团队就需要构建隔离抽象和给出临时解决方案，或者通知开发团队这些潜在问题来避免他们踩坑。
高效能软件开发团队是任何组织能够持续交付价值的关键。
本书主要介绍了高效能团队模式 —— 团队拓扑，为组织设计和团队交互提供了一种实用的、分步的、适应性的模型，将团队视为交付的基础，
团队结构和沟通路径能够随着技术和组织成熟度的发展而演变。
我们需要以团队为中心的方法来实现可持续的 CI/CD，而不是以工具为中心。
康威定律：
一种基本的观点是，设计系统的组织由于受限于组织的沟通结构，只能设计出与之类似的系统架构。
我们发现，这对于系统设计管理方面存在显著的影响。
从根本上讲，我们发现了一种设计组织的架构标准，即组织设计需要以满足沟通的需要为导向。
随着系统复杂性的提升，组织构建和进化方面的认知需求也会随之增加。
通过定义清晰的职责和边界来管理团队间的认知负荷，是团队拓扑方法在团队设计方面最与众不同的特点。
现代组织设计……是基于用户的协作设计。
组织不仅要努力做到团队自洽，还要不断的思考和与时俱进，以便快速的向客户交付价值。
为了实现完美的软件交付，统一团队语言和共同协作方式所带来的的价值是巨大的。
团队拓扑方法希望能够帮助那些纠结于寻找一种合适的方法来优化团队结构的组织，
或者那些还没有意识到团队设计可以带给业务产出和实际软件系统良好影响的组织，
从而帮助他们获得更加快速和持续的成功。
组织应该被视为一个复杂的具有适应性的有机体，而非一个机械的线性系统。
构建和运行这些高度复杂、相互连接的软件系统是一种团队活动，需要不同平台和技术领域的人才共同努力。
此外，现代 IT 组织必须快速且安全的交付和运维软件系统，并且还要同步适应业务或日常环境中的变化和压力。
业务需要兼顾系统的稳定性和交付速度两方面的优化。
组织结构必须协调职责来支持高质量、有影响力的软件交付的目标。
我们必须改变之前的思想，不再将团队视为一组可替换的个体，即只要他们沿用 “正确” 的流程和使用 “正确” 的工具就能获得成功，
而是将人员和技术视为社会技术生态系统中的一分子，正如计算芯片中用到的碳和硅一样。
从表面上看，组织结构图的问题在于我们试图把人看成软件来安排组织结构，把他们的沟通局限在组织结构图的汇报路径上。
但是人们的沟通并不局限于图中的连接线，我们会联系任何为了达成工作目标所依赖的人员，我们会为了达成目标来改变规则。
这就是为什么实际的沟通路径和组织结构图呈现出来的差异很大了。
传统的组织结构图并不能帮助我们理解组织中的真实沟通模式。
相反，组织需要开发一种更加实际的示意图来表示个体和团队之间预期的和实际的沟通方式。
这两者之间的差异有助于展现什么样的系统型更加适合组织。
实际上，人们为了完成工作，会与另外一条汇报线上的人员进行横向或纵向沟通。
组织需要有意识的培养这种创造力和解决问题的能力，并从中受益，而不局限于自顶向下和自底向上的沟通和汇报。
系统思维更加专注于全局优化，将目光着眼于完整的工作流，识别哪里是目前的最大瓶颈并消除它，进行持续改进。
团队拓扑聚焦于如何建立动态的团队结构和交互模式，从而帮助团队快速适应新的环境，并达成快速和安全的软件交付目标。
或许这些并不是你当前所面对的最大瓶颈，但你终究会面对严峻的团队结构问题所带来的低效沟通和不恰当的流程，从而拖慢交付速度。
组织设计法则：
团队拓扑提供了四类基本的团队类型 —— 流动式团队、平台团队、赋能团队、复杂子系统团队。
三种团队核心交互模式 —— 协作模式、服务模式、促进模式。
它着眼于不同团队拓扑要如何随着技术和组织的成熟度而不断演进。
在技术和产品探索阶段，通常需要高度协作的环境（存在重叠的团队边界）才能成功。
但是，如果在探索阶段结束后（也就是已获得成型的技术和产品时）依赖维持同样的结构，反而会导致精力的浪费和误解。
康威定律：
设计系统的组织由于受到约束，这些设计往往是组织内部沟通结构的副本。
这个 “定律” 表明一个组织的真实沟通路径和最终软件架构之间的强相关性。
这种同态力将软件架构和团队结构塑造成相同的 “形状”。
构建软件需要理解团队的沟通路径，以便更加实际的考虑什么样的软件架构才是可行的。
如果预期中理论上的系统架构不符合组织模型的话，那么其中之一就需要做出改变。
逆康威定律：
组织要根据他们想得到的软件架构来设计团队结构，而不是期望团队盲从一个被设计好的团队结构。
其中的核心观点在于，将软件架构看做一个独立的概念，认为它可以被孤立设计，然后交由任何团队来实现，这从根本上就是错误的。
谈到认知负荷，我们可以简单的将其了解为任何一个人在给定的时间内大脑中所能保存的信息量是有上限的。
然而，当给一个团队分配职责或者软件组件的时候，我们几乎不会考虑认知负荷。
可能是因为期望团队能够不假思索的完成被交代的任务。
如果不考虑认知负荷，团队就会做大量并行工作，尝试覆盖过多的职责和领域。
这让团队开始疲于奔命，精力在不断的任务切换中消耗殆尽。
产品团队负责的服务和组件数量（团队的需求）通常会随着时间不断增长。
然而，新服务的开发通常是按照团队能够全职投入来规划的，并不是根据团队的认知负荷来规划的。
这些被忽视的部分恰恰是有问题的，因为团队依然要修复和改进已有的服务。
最终，团队成了交付的瓶颈，而他们的认知负荷也大幅超标，从而导致了延迟、质量问题，并且这也持续的伤害了团队的工作意愿。
在一个充满不确定性和新鲜事物的环境中，需要频繁的重塑协同团队来应对知识型工作，传统的组织结构图已经很难跟上现实的节奏。
相反，我们需要利用康威定律、认知负荷限制和团队有限方法论来设计团队，确保拥有清晰的目标并推动团队交互，不断优化软件交付和策略的适应性。
如果系统的架构和组织架构不一致，那么组织架构将成为赢家。
组织在设计产品时往往要匹配或模仿真实的组织沟通结构。
当组织被划分为职能竖井（也就是团队按照专业职能来划分，比如 QA、DBA 和 安全团队）时，难以面向端到端的工作流设计一个良好架构的软件系统。
同理，如果一个组织主要根据不同地域的销售渠道来划分，那么就难以开发出一种有效的软件架构来面向全球所有区域提供多样性的软件服务。
对于任何一个特定的团队或组织，那些必要的沟通路径不存在，导致了一系列可替代的设计方案难以有效落地。
组织内部的沟通路径（无论是否和正式汇报线一致）严重制约了组织所能设计的解决方案的类型。
如果我们想要避免一些过度关注技术内部实现的设计，就可以通过组织重组来实现这个目标。
同样的，如果我们希望组织能够发现并采用一些特定的设计，这些设计更加有助于价值流动，那么我们同样可以通过组织重组来让它变为现实。
逆康威定律
组织需要通过团队和组织结构的改进来实现预期的软件架构。
康威定律告诉我们，在设计组织团队之前，首先要弄明白我们所希望的软件架构是怎样的，否则组织中的沟通路径和激励最终决定软件架构。
团队划分是软件架构的第一版草稿。
如果我们让管理者来决定哪些团队开发哪些服务，那么就相当于我们默认让管理者来决定软件架构。
如果一个构件软件系统的组织想要决策团队的形态、职责和边界，那么技术负责人的输入是不可或缺的。
对于那些声称要成为架构师的人来说，技术和社交能力缺一不可。
他们需要理解人，并在一个社会架构中工作。
他们同样需要一个远超单纯技术领域的职责，在组织结构和人事方面拥有一定的话语权，比如让他们同事兼任管理者。
从根本上讲，我们需要在组织设计中引入技术人员，因为他们理解核心的软件设计概念，
比如 API 和接口、抽象、封装等。
康威定律的一个核心内涵之处，并非所有的沟通和协作都是有价值的。
因此，定义 “团队接口” 并设定预期，哪些工作依赖于紧密协作，而哪些不需要，这是非常重要的。
很多组织认为沟通总是越多越好，但事实并非如此。
我们需要的是特定团队间更为聚焦的沟通。
我们同样需要识别那些意料之外的沟通，并进一步寻找根本原因。
管理者应该集中精力在模块化系统中，理解被人忽略的设计接口背后的原因，以及难以预料的团队互动。
评估组织内团队之间沟通的健康度：
这种架构是否最小化了团队间的沟通路径？这种架构是否鼓励团队进行沟通？
从逻辑上讲，根据软件架构设计，如果两个原本不应该彼此沟通的团队正在进行沟通，那么一定是哪里出了问题。
如果我们能够保持团队间低频沟通，甚至在零沟通的前提下依然可以安全、有效和快速的构建和发布软件，那么我们就应该这样去做。
制约沟通的一个简单方法就是，将团队安排在办公室的不同区域、不同楼层，甚至不同大楼。
如果团队主要通过即时通信软件进行虚拟沟通，那么团队间沟通的信息量和模式可以作为识别那些与软件架构所预期的交互不匹配的沟通情况。
团队内高频沟通，两个合作团队之间可以保持中频沟通，而大多数团队间应该做到低频沟通。
如果一个组织认为 “每个人都需要看到每条对话消息” “每个人都需要参加大量的站会” “每个人都需要出席会议”，这样才能完成决策过程，那么我们的组织设计肯定出问题了。
康威定律表明，这样多对多的沟通会产生单体、杂乱、高度耦合和相互依赖的系统，并会阻塞快速流动。
也就是说，过多的沟通并不一定是好事。
如果团队错误解读了康威定律，会带来风险，表面上看建立另一组团队可以完美适配所需的架构，
但实际上，却非常不利于工作的快速流动。
过去很多 “组织结构调整” 的潜在目标都是为了减少员工或者围绕管理者和领导者的权势建立山头。
解散高效能团队比破坏公物还过分，这是一种企业病态。
对于需要大量信息的知识密集型、问题解决型任务来说，一个有凝聚力的团队的表现要远远超出个人的集合。
即便像美国陆军这种等级森严的组织，也将团队作为基本的作战单位。
表现最突出的团队之所以能够取得非凡的成就，不仅仅是因为团队成员的个人素质，还在于这些成员凝聚成了一个整体。
谷歌在针对他们自己团队的研究中发现，团队活力远比谁在团队中更重要。
在衡量绩效的时候，团队比个体更重要。
因此，我们必须从团队入手实现高效的软件交付。
让小而美的长期团队成为标准
我们将团队视为组织中最小的交付实体。
因此，团队永远不应该把工作指派给个人，而应指派给团队。
邓巴数字
邓巴发现 15 是一个人可以信任人数的极限，而其中只有 5 个人能获得深入了解的信任。
放任团队规模超过 7~9 这个魔法数字，将危及团队构建软件的生命力，因为信任将开始崩塌，不合时宜的决策也会随之而来。
组织需要最大化团队成员之间的信任，这就意味着需要限制团队成员的数量。
人类学研究表明人与人之间的关系类型和深度存在明显的限制：
团队需要信任来维持高效运作，但是如果团队规模变得太大，以至于难于维持必要的信任水平，
那么组织就不能像之前小团队那样高效了。
在一个为期 6 个月的项目结束后，团队刚刚开始展露高效，这时候将人员分配到不同的团队不是一个明智的选择。
布鲁克斯定律
给一个团队添加新成员，并不会立即提升团队的容量。
事实上，在初始阶段，这样做很有可能会降低团队的容量。
需要一段时间来让人们适应新的环境，但是在新人加入后，团队内部的沟通路径也会因此显著增加。
不仅如此，对于新老成员来说，为了理解和适应彼此的观点和工作习惯，他们在情感上需要适应过程。
Tuckman 模型描述了团队在四个阶段上的表现：
激荡期实际上在团队的整个生命周期中不断出现，组织需要通过对团队动力的培养来保存高效能。
让多个团队改动相同的系统或子系统的问题在于，没人负责所有的改动及其带来的混乱结果。
然而，如果一个团队负责系统或子系统，并且团队成员可以自主的规划他们的工作，那么团队面对短期改动时就能做出明智的选择，
因为他们知道在未来的几周里他们要花时间来移除不好的修改。
团队的代码所有权并非是在划分底盘。
团队对代码负责并维护，但是团队成员不应该觉得代码是他们的而排斥其他人。
相反，团队应该将他们自己视为管家和看管人，而并非私人所有者。
也就是说，将代码视为园艺工作，而非监管工作。
为了促成团队协作，团队成员需要将团队需求置于个人需求之上，他们需要做到：
然而即便通过引导，有的人依然不适合团队工作，或者不愿意将团队需求放在个人需求之上。
这些人会影响团队工作，在极端场合下，甚至会摧毁团队。
这类人就是 “团队毒药”，需要在他们带来伤害之前将他们移出团队。
在民用和军事领域的研究强烈表明，
拥有不同背景成员的团队更容易快速的提出创造性的解决方案，也更容易理解其他团队的需求。
良好设计的边界，可以最小化认知负荷
心理学家 John Sweller 将认知负荷定义为 “工作记忆中使用的脑力劳动总量”。
Sweller 定义了三种不同的认知负荷：
面向他人最小化认知负荷是良好的软件开发中最有用的启发式方法。
按照业务领域来组建团队，而不是按照技术活动来组建团队。
我们必须构建跨职能的交付团队，让它可以独立的完成设计、开发、测试、部署、运维系统等一系列活动。
特性团队依赖于高度工程能力成熟度和互信
以特性团队为例，这些团队是跨职能、跨组件团队，负责一个用户特性从概念到生产的全部过程，
完成用户需求交付，监控使用情况及性能表现。
特性团队必须是自给自足的，这意味着他们能够在不依赖于其他团队的前提下完成特性向生产环境的交付。
SRE（站点可靠性工程 Site Reliability Engineering） 就是当你安排软件工程师去设计运维功能时将会发生的事情。
组织结构决定了其所开发的系统的架构。
四类基本团队拓扑：
技术服务团队应该把自己当成纯粹的面向领域团队的服务提供者。
衡量平台团队的价值，要看他们提供给产品团队服务的价值。
如果想快速、安全的交付软件，就应该避免只由单一职能的人员组成的团队。
为获得一个快捷、安全的变更流程而优化的组织，通常应该使用多角色跨职能团队，也就是流动式团队。
有时候，有些特殊领域实在过于复杂，所以需要专门的复杂子系统团队。
但是这样的团队不应该出现在变更工作流中，而是应该为流动式团队提供服务。
一个工作流中的不同阶段和任务应该由同一个团队负责，避免不同团队间的交接。
一个优秀的平台要提供标准、模板、API 及经过验证的最佳实践，帮助开发团队快速创新和高效工作。
一个优秀的平台能够简化开发团队的工作，按照正确的方式做正确的事情。
这不仅针对软件开发，而且对任何类型的产品开发来说都是如此。
我们的目标是搭建一个最小可用平台，而不是让平台面面俱到。
软件开发人员热衷于构建平台，如果没有强有力的产品把控，那么平台的能力就会远超真实需求。
让开发者的世界变简单，降低使用者的认知负荷，是一个优秀平台的关键评判标准之一。
通过降低开发团队的认知负荷，一个优秀的平台帮助开发团队聚焦于业务问题本身，可以加速个人和团队的开发速度，从而让整个团队更高效的工作。
平台最重要的就是面向开发者提供服务。
如果脱离团队需求来开发平台就陷入了一个典型的困境，为了避免这种情况的发生，需要确保平台团队关注用户体验（UX），尤其是开发者体验。
也就是说，当平台规模扩张时，需要将用户体验能力注入平台团队。
如果不这样做，开发人员经常会有挫败感，应该为平台开发人员提供一种反馈途径来了解平台究竟做的怎么样。
如果不能做到这一点，平台就成了公司内部的孤岛，难以让团队真正用起来。
良好的用户体验和开发者体验能够让平台充满吸引力，同时能够让平台的功能特性和 API 层面保持一致。
用户操作手册及其他文档可以覆盖所有功能（无须过度冗长）且实时更新，聚焦达成特定任务目标的方法，而不是面面俱到的罗列平台所有细节。
平台应该帮助开发者扫清障碍，确保团队能够在没有那么多条条框框的前提下开发自己所需的功能。
新开发人员上手平台的容易程度，是对开发者体验的很好的检验。
It's turtles all the way down.（一切建筑皆有底座）。
在软件领域，这个比喻意味着每个平台都是基于另一个平台构建的，即便它的底座平台是隐藏和不可见的。
如果底层或下层平台无法稳定运行或者设计上有缺陷，那么上层平台也会变得不稳定，无法提供加速组织内其他软件交付所需的坚实基础。
如果底层平台存在运行漏洞或者性能问题，那么平台团队就需要构建隔离抽象和给出临时解决方案，或者通知开发团队这些潜在问题来避免他们踩坑。
可以绘制一张全景图来描述你所在组织的平台层级关系。
这将帮助各个内部团队，及使用平台的开发团队理解这些平台能提供什么，以及彼此的依赖关系。
平台需要明确定义服务的可用时间，并周知用户（开发团队）。
用户依赖平台的可用性，同时需要了解什么时候会上线新特性，而旧特性什么时候会下线。
因此，为了帮助开发团队用户更高效的使用平台，我们需要做到：
（1）把内部平台视为线上/生产系统，计划和管理维护时间
（2）引入软件产品管理和服务管理技术
当我们把平台视为线上或生产系统的时候，就需要采取类似其他线上系统的各项活动和实践：
定义服务在线时间、定义故障和支持响应时间、安排支持平台的轮值表、使用适当的沟通渠道（比如通通过服务状态网页）管理故障和宕机时间等。
当然随着平台的成长， 应该不断反思团队究竟需要什么服务，以及平台能够提供什么服务，以此来应对平台团队不断增加的运营工作。
平台团队的主要用户应该是产品团队。
那么如何管理有确定目标用户群和运行实际那的线上软件系统呢？
答案是，引入软件产品管理。
因此，应该由产品管理人员确定平台的发展规划，同时与开发团队进行沟通讨论，至少要考虑开发团队的需求。
平台团队几乎肯定会制作用户画像，用户画像方法将帮助平台团队了解并聚焦典型用户的需求、痛点和目标。
平台团队的成员应该与开发团队用户定期沟通，了解他们的需求。
关键在于平台这个 “产品” 的演进，不应该只是简单的接收并实现开发团队提出的需求，而是应该精心打磨以满足他们的长期需求。
通过指标来跟踪特性的使用情况，用于评估开发优先级。
平台不仅是开发团队在过去某个时间点提出的一组特性的集合，而应该进行整体的、精心的、一致的设计，并且考虑技术发展变化的趋势，以及组织不断变化的需求。
当代码不起作用时，问题萌发于团队的组织方式及人们的沟通方式。
如果每个团队都依赖于跨团队的复杂沟通网络，则很难实现价值流动。
为了软件系统中变更的快速流动，我们需要消除团队之间的工作交接，并让大多数团队与组织中的主变更流程保持一致。
软件交付过程中的许多问题都是由于不同团队之间的边界和他们的职责一时的不清晰造成的。
办公室应该是标准化统一布局的，这一想法非常普遍。
虽然这可以减少装修的工作量，但是会给个人和团队带来长期的负面影响。
不仅如此，我们通常相信开放式办公场地有助于团队协作，但据一个现场调查发现，
在两个采用开放式办公环境的组织中，面对面交流的频率明显下降（大约下降 70%），同时电子方式交流的频率相应增加。
根据我们的经验，出现这种问题通常代表产生了误解，也就是我们需要对目标达成共识，而不仅仅是让人们坐在一起。
根据团队认知负荷来确定软件边界
我们需要寻找天然的方法来拆分系统（根据破裂面），使产生的各个部分尽可能独立演进。
由此，分配到这些部分的团队将体验到更多的自主权。
在协作解决复杂问题的场景中，应该重新考虑采用的技术和组织方式，让人们经常能够独立工作，以获得集体最佳效能。
良好定义的交互模式是高效能团队的关键
在很多组织中，未良好定义的团队交互模式和职责是挫败感和低效率的源头。
即便团队可能被告知他们是自组织的，但团队成员发现他们为了完成工作不得不同其他团队进行交互，这会让人感到非常沮丧。
其他团队也许有责任提供 API 或服务，但他们并不知道应该如何做才能更高效。
丰田成功的根本原因不是其组织结构，而是对其员工能力的开发和习惯的培养。
团队应该思考：
我们应该用什么模式与另一个团队交互？
我们应该与另一个团队紧密协作吗？
我们是否应该提供服务？
或者我们应该期待或提供帮助？
团队间是采用协作模式还是一个团队通过服务的方式为另一个团队提供某种能力，这是团队拓扑方法中的关键要素。
只有当服务边界定义良好、服务被正确实现、服务提供方实施服务管理实践时，服务模式才能正常运作。
基本团队拓扑的团队交互模式
组织的划分决定系统各部分间实际的边界。
架构师需要同时具备技术能力和协作能力，他们也需要具备比单纯技术更广的影响力，比如业务策略、组织结构、个人事务等。
他们事实上需要的是一个管理者。
架构师需要思考：
哪类团队交互模式适用于这两个团队？
在两个团队以及两个系统组件之间需要何种沟通方式？
一个组织中遵循团队拓扑方法的架构师，于是成为团队 API 的定义者，这些 API 塑造了预期的软件架构。
实际上，与其完全依赖于团队成员完成边界的定义，不如让具备 API 设计能力的人来设计组织内团队间的 API。
选择团队交互模式，来降低不确定性并增加流动性。
从来没有最好的设计，流行一时的系统概念也可能需要改变，因此，组织灵活性对于有效设计而言至关重要。
在设计用于构建和运行软件系统的现代组织时，最重要的事情并非是组织自身的架构，而是当新的挑战出现时，用来适应和改变组织的设计规则和方法。
也就是说，我们需要设计的是规则，而不仅仅是组织。
The text was updated successfully, but these errors were encountered: