正版 高效能团队模式(支持软件快速交付的组织架构全彩印刷)

目录
第I部分 团队即交付
第1章 组织结构的陷阱 \ 003
组织的沟通结构 \ 005
团队拓扑：一种全新的团队思维方式 \ 009
康威定律的复苏 \ 010
认知负荷和瓶颈 \ 012
总结：重新思考团队的结构、目标和交互方式 \ 013
第2章 康威定律为何如此重要 \ 017
理解并使用康威定律 \ 017
逆康威定律 \ 020
有利于团队协作流程的软件架构 \ 024
组织设计依赖于技术专家 \ 026
限制非必要沟通 \ 027
小心那些流于表面的康威定律 \ 029
总结：康威定律对于有效的技术团队设计至关重要 \ 032
第3章 团队优先的思维方式 \ 033
让小而美的长期团队成为标准 \ 034
良好设计的边界可以最小化认知负荷 \ 042
设计“团队API”和促进团队交互 \ 051
警告：工程实践是基础 \ 061
总结：控制团队认知负荷并促进团队交互来实现快速交付 \ 061
第II部分 围绕工作流设计团队拓扑
第4章 静态团队拓扑 \ 067
团队反模式 \ 068
为变更的流动而设计 \ 069
DevOps和DevOps拓扑 \ 072
成功的团队模式 \ 073
选择团队拓扑需要考虑的因素 \ 079
使用DevOps拓扑促进组织发展 \ 082
总结：根据现状选择团队拓扑并持续演进 \ 085
第5章 四类基本团队拓扑 \ 087
流动式团队 \ 089
赋能团队 \ 094
复杂子系统团队 \ 099
平台团队 \ 100
避免变更流程中的团队竖井 \ 108
一个优秀的平台应该“够用就好” \ 109
将常见的团队类型转换为基本团队拓扑 \ 113
总结：采用松耦合、模块化的四类特定团队类型 \ 119
第6章 选择团队优先的边界策略 \ 121
软件职责和边界中的团队优先方法 \ 122
不可见的单体和耦合 \ 123
软件边界或“破裂面” \ 125
一个来自生产制造的真实案例 \ 135
总结：根据团队认知负荷来确定软件边界 \ 137
第III部分 改进团队交互来促进创新和快速交付
第7章 团队交互模式 \ 143
良好定义的交互模式是高效能团队的关键 \ 144
团队交互的三种核心模式 \ 146
每种交互模式下团队的行为特征 \ 153
选择合适的团队交互模式 \ 156
选择基本团队结构 \ 158
选择团队交互模式来降低不确定性并增加流动性 \ 161
总结：三种良好定义的团队交互模式 \ 163
第8章 根据组织感知进化团队结构 \ 165
什么样的团队交互是合适的 \ 166
加速新实践的落地和学习 \ 168
团队拓扑结构的不断演进 \ 172
组合团队拓扑追求更高效 \ 177
团队拓扑演进的触发器 \ 178
自组织设计与开发 \ 183
总结：持续进化团队拓扑 \ 188
结论 下一代数字化运营模型 \ 189
四类团队类型和三种交互模式 \ 191
团队优先思维方式：认知负荷、团队API、团队规模架构 \ 192
康威定律的策略应用 \ 192
进化组织设计以提升适应性和感知 \ 193
团队拓扑并非IT效能的全部 \ 194
下一步：如何上手团队拓扑 \ 195
专业术语 \ 199
推荐阅读 \ 202
致谢 \ 204
作者简介 \ 206

Matthew Skelton，从1998年开始开发、部署和运维商业软件系统，他曾就职于伦敦证券交易所、GlaxoSmithKline、FT.com、LexisNexis及伦敦政府。作为Conflux的首席咨询师，Matthew是2016年出版的Continuous Delivery with Windows and .NET和Team Guide to Software Operability两本书的合著者。Matthew拥有雷丁大学计算机和控制学专业的学士学位，以及牛津大学神经系统科学专业的硕士学位，并且他也是开放大学的音乐文学硕士，还是英国特许工程师(CEng)。在业余时间，他的兴趣是吹小号、参与唱诗班、作曲及越野跑。
Manuel Pais，是DevOps和持续交付领域的一位独立咨询师，专注于团队设计、实践和流程方面。他通过策略评估、实践工作坊和教练服务来帮助组织定义和实践DevOps与持续交付(包括技术方面和人员方面)。他是2018年出版的Team Guide to Software Releasability一书的合著者。
石雪峰，京东商城工程效率专家，DevOps标准核心编写专家，Jenkins社区全球大使，极客时间专栏《DevOps实战笔记》作者，《Jenkins?2权威指南》联合译者。
董越，阿里巴巴前研发效能高级专家，DevOps标准核心编写专家，《未雨绸缪——理解软件配置管理》《软件集成策略——如何有效率地提升质量》作者，《版本控制之道——使用Git》译者。曾就职于西门子、摩托罗拉、雅虎、索尼、去哪儿网等大型企业。
雷涛，华佑科技CTO，DevOps标准核心编写专家，百度前工程效率专家，《Jenkins?2权威指南》联合译者，曾先后就职于新浪网、摩托罗拉、诺基亚、爱立信、乐视致新等国内外知名企业，专注于互联网、电信、金融、无人驾驶汽车等行业的软件工程效率提升。

1.高效运维社区创始人萧田国、DevOps时代社区联合创始人景韵联合作序，业内多名专家力荐。
2.全面介绍高效能团队模式——团队拓扑，为组织设计和团队交互总结了四类团队类型和三种交互模式，结合案例进行了递进的、深入的阐述，对数字化转型中的企业极具参考价值。
3.本书适合关注软件系统开发和运维过程效率的公司领导层(包括CTO、CIO、CEO、CFO等)、经理、部门主管、软件和系统架构师，以及所有参与构建和运行软件系统的人阅读，适用于想让系统的交付和运行变得更高效的任何人。

本书针对以下典型场景并提供了一些建议的阅读方法：√ 希望了解不同的团队类型，以及哪种类型最高效。
√ 希望解耦一个巨大的单体软件系统。
√ 希望改进软件系统架构。
√ 希望提升软件开发团队的效率。
√ 希望提升团队的士气和效率。
√ 希望了解在哪些方面投入可以实现预期的增长。
√ 希望了解如何持续改进团队拓扑以适应业务变化的需求。

团队作为IT组织最基础的能力单元，是IT治理的坚实着力点。在围绕IT运营转型、IT价值洞察、科技风险治理三大领域的IT新治理模式中，团队组织设计与交互模式是必谈的话题。企业在落地DevOps、FinOps的过程中，需要打造集合业务、财务、科技(开发、测试、运维)的高效能团队模式，构建以价值为导向、兼顾风险、敏捷精细的IT新治理能力。
——杨玲玲，中国信息通信研究院云计算与大数据所治理与审计部副主任(主持工作)近年来，金融行业广泛通过实施DevOps来进行数字化转型。DevOps的核心在于通过企业级的工具与标准，消除员工个体的差异，快速实现企业级能力的提升。但在实践DevOps的过程中，我们发现团队能力的提升和组织模式的演进依然无法回避，团队作为企业最小也是最核心的作战单元，最终决定了整个企业数字化转型的成效。我们都是企业组织结构的局中人，也应该成为企业组织结构的破局者。本书系统地描述了组织设计模型，包括四类团队类型和三种交互模式，这对我们打造高效能团队很具参考价值。
——温建波，中国工商银行软件开发中心项目办总经理数字化转型要求企业具备超强的感知、洞察能力，由全方位数据支撑的明智决策能力，快速创新、复制、组装的研发上线能力。如何快速研发上线？精益、敏捷、DevOps、产品制、部落制等都离不开高内聚、松耦合的IT架构，以及与之匹配的开发组织结构。本书以康威定律为基础，结合邓巴理论，通过正向推导、逆向演绎、深入浅出，提供了建立一个灵活、高效团队的方法论，为企业数字化转型建设打下了坚实基础。
——廖??定，锦州银行信息技术部联席总经理在云原生、DevOps和精益敏捷的大浪潮下，软件开发模式也发生了深刻的变革，然而支撑软件开发的组织架构却多年没有明显变化，已经变得越来越难适应。作为传统金融机构的金融科技负责人，我在企业数字化转型的过程中反复思考我们作为强监管的金融机构，在拥抱新模式时应该用什么样的组织形式来推动有价值的产品开发。本书是少有的介绍敏捷组织架构的图书，全书围绕康威定律阐述了我们需要什么样的组织架构才能更好地推动、提升端到端价值交付的效率，非常值得一读。
——何??波，中泰证券股份有限公司金融科技委员会主任&科技研发部总经理在DevOps变革中，企业必须选择合适的团队拓扑来提升各个团队之间的协作效能，进而提高DevOps变革的成功概率。康威定律告诉我们有什么样的团队拓扑就会有什么样的软件架构，换言之，团队拓扑设计会在一定程度上限制技术方案的可能性。如果你想深入了解团队拓扑设计与团队协同提效之间的制约与关系，或者你对团队拓扑设计和研发效能提升两者之间的相关性有所疑惑，那么本书都会是你的不二选择。
——茹炳晟，腾讯技术工程事业群基础架构部T4级专家，腾讯研究院特约研究员《高效能团队模式》为如何预测、适应市场和技术变革提供了新的洞察。企业为了生存需要忘记既有的管控架构，并向具备最有效信息的领导者授权，以便快速采取行动并做出响应。本书有助于企业高管和商业领袖专注于高效能团队的关键战略，从而有效地应对当下的需求并面向未来持续演进。
——Barry O'Reilly，ExecCamp创始人，商业顾问， Unlearn和《精益企业》1(Lean Enterprise)作者 对于管理而言，没有什么比要如何搭建组织结构并激发你所鼓励的行为发生更加基础的。尽管如此，很少有人会针对跨越数字化、DevOps和SRE的IT组织结构转型背后的组织设计模型进行归类分析。Skelton和Pais不仅接受了这个大胆的挑战，也通过创建一种难以获取的独特资源达成了这个目标。 ——Damon Edwards，Rundeck联合创始人《高效能团队模式》为以增加流动性为目标的评估和优化团队组织提供了一种必要的框架。那些具备合理规模、合理边界及合理沟通级别的团队，将为公司带来价值，并使团队成员感到满意。《高效能团队模式》将系统方法与现实案例研究相结合，并以此释放技术团队的全部潜力。
——Greg Burrell，Netflflix高级可靠性工程师Matthew Skelton和Manuel Pais的《高效能团队模式》是独一无二的。它将给技术企业带来深远的影响。我们需要一种结构化的、有条理的方法来塑造持续交付团队，而并非照搬Spotifty的经验，这正是本书带来的价值。
——Nick Tune，Navico API平台主管在Condé Nast International，对于理解我们的DevOps现状，以及定义我们孜孜不倦追求的DevOps实施模型的远景目标来说，“DevOps拓扑”都是至关重要的。我们可以通过书中细致描述的模型来绕开陷阱，避免陷入团队反模式。我为Matthew和Manuel从DevOps拓扑中收获的成长，以及他们将进一步的研究转化为深远的组织设计《高效能团队模式》一书而感到非常欣喜。 ——Crystal Hirschorn，Condé Nast工程、全球战略和运营副总裁那些高效能团队是现代数字化经济价值的核心源动力。但是培养和规模化这类团队的生态系统常常是一个难以实现的目标。在《高效能团队模式》一书中，Skelton和Pais为下一代数字化运营模型提供了创新性的工具和理念。强烈将这本书推荐给全球的CIO、企业架构师和数字产品策略专家们。
——Charles Betz，Forrester Research首席分析师Matthew Skelton和Manuel Pais说《高效能团队模式》是一本工具书，的确如此。本书良好的结构和清晰的标识来源于深度思考，这些让读者像作者一样认为一个组织是一个社会技术系统1 或者生态系统。基于这种假设得出了实用建议、操作指导及一种构建有效的技术人文组织设计方法的技巧。对于技术组织设计领域的任何人来说，《高效能团队模式》都值得一读。 ——Naomi Stanford博士，组织设计实践者、导师和《组织设计指南》作者我认为Matthew和Manuel在模式和语言方面的研究，无论对于组织内部随时间塑造组织转型策略，还是帮助业务和技术领导者将组织和持续交付联系起来，都具有难以置信的价值。
——Richard James，Nationwide数字技术与工程主管团队是组织最基本的组成部分，对于中等效能和高效能组织而言，团队如何工作及在哪些系统中运营都不尽相同。本书对于你要如何根据当下状况来优化组织系统来说可谓是智慧的源泉。
——Jeremy Brown，Red Hat开放创新实验室EMEA主管DevOps很重要，但是真实世界中的组织要如何切实构建自己从而实现DevOps呢？你不能将所有人都安置于一个独立竖井式的团队中，或者所有人都坐在一个大而空旷的办公室中并一起吃午饭和踢足球。《高效能团队模式》为回答DevOps的关键问题提供了一些实践模板，而其他一些问题则作为练习留给读者。
——Jeff Sussna，Sussna Associates创始人&CEO，Designing Delivery作者如果你寻找一本书来分析传统工作方式下的挑战，并且要获得一些迁移战略方面的实践指导，比如新的交互模式、降低认知负荷、建立合理的团队API等，那么我将这本书推荐给你。
——Daniel Bryant，InfoQ技术顾问&新闻经理《高效能团队模式》是一本引人入胜的读物，它探索了团队与团队支撑的IT系统结构之间的共生关系。超越了静态组织结构图或自组织混乱等通用方法，展示了如何让人际系统和IT系统共同发展的方法。
——Mirco Hering，埃森哲DevOps主管，DevOps for the Modern Enterprise作者

中序 陆止于此，海始于斯。 ——葡萄牙诗人卡蒙斯 2019年冬，我们一行来到葡萄牙首都里斯本，参加DevOps World | Jenkins World Lion大会。在大会现场，我们遇见了Team Topologies一书的联合作者Manuel Pais，他的演讲Why You Need to Think About Team Design for CI/CD中有如下两个要点让我们心有戚戚。 一是他认为：“我们需要以团队为中心的方法来实现可持续的CI/CD，而不是以工具为中心。” 二是他分享了四类团队类型和三种交互模式，四类团队类括：流动式团队、赋能团队、复杂子系统团队、平台团队；三种交互模括：协作、服务、。这种的团队组织设计与协作模式带给我们很大的启发。运维和DevOps时代社区一直致力于在国内推行DevOps、推广中国信息通信研究院牵头的DevOps系列标准，在这个过程中我们与国内企业和相关专行了大量的交流，交流中总会谈到组织与文化。Team Topologies一书的目的就是要解决组织和文化的问题。 如果你在实践DevOps的过程中，想要解耦一个巨大的单体软件系统、提升软件开发团队的效率及持续团队拓扑以适应业务变化的需求，那么将这给你，你一定能在这本书中找到一些答案。 华为提出“方向要大致正确，组织要充满活力”，那么科技组织如何才能充满活力呢？这本书假设一个组织是一个社会技术系统或者一个生态系统，这个系统由个体和团队之间的交互塑造而成，也就是说，一个组织应该是人和技术共同作用的结果，这是的动态组织的特点。 这本书基于大量的研究成果，借鉴了大规模开发和运行软件系统的实践。在BookAuthority于2020年评选的“100 Best Product Management Books of All Time”中排名第3，同时经常高居（美国）网站上计算机编程结构设计类图书，软件设计、测试与工程类图书畅销书榜单前20，这充分说明业界对一本解决组织模式问题的图书是多么渴望。 怀揣作者赠送的签名版Team Topologies，我们从里斯本回到北京，DevOps三剑客（石雪峰、董越、雷涛）一拍即合，希望引入这本书。在电子工业出版社博文视点的帮助下，三剑客从2020年春节开始了本书的翻译工作。在2021年的夏天，这本书终于要和国内读者们见面了。 这本书的三位译者都是行业内的领军人物： 石雪峰，一位爱折腾的大侠，DevOps标准核心编写专家，商城工程效率专家，极客时间专栏《DevOps实战笔记》作者，《Jenkins 2指南》联合译者，Jenkins全球大使。 董越，一位博识有趣的大侠，DevOps标准核心编写专家，《未雨绸缪——理解软件配置管理》与《软件集成策略——如何地提升质量》作者，国内早出版的Git图书《版本控制之道——使用Git》译者。 雷涛，一位温文尔雅的大侠，DevOps标准核心编写专家，华佑科技CTO，《Jenkins 2指南》联合译者，Jenkins全球大使。 翻译外文图书非常辛苦，我们目睹了DevOps三剑客字斟句酌、精益求精的翻译过程，感谢三位译者石雪峰、董越、雷涛以及博文视点编辑付睿同学付出的非凡努力，你们为国内读者们奉上了这本高价值的图书，向侠之大者致敬。 里斯本的罗卡角位于欧亚大陆西端，号称世界的尽头，大航海时代无数先驱望着罗卡角的灯塔，航向大海。“陆止于此，海始于斯。”《能团队模式：支持软件快速交付的组织架构》就像一座灯塔，指引我们从固态组织（陆）航向动态组织（海），期待科技组织大航“海”时代的到来。 萧田国 运维社区创始人 DAOPS基金会全球理事 景韵 DevOps时代社区联合创始人 DAOPS基金会首席布道师 译者序 2019年初冬，我与本书的另一位译者雷涛、发起人景韵有幸作为Jenkins社区有价值贡献者的代表，受邀来到葡萄牙里斯本参加DevOps World | Jenkins World Lion大会，同全球专家们一起探讨DevOps的未来发展。欧洲人固有的浪漫主义在此次大会中体现得，也正是在会后Party上，我邂逅了本书的作者Manuel，他一边吃着比萨，一边随意地拉了张桌子签名送书，这给我留下了深刻的印象。没错，这本书正是呈现在你面前的《能团队模式》一书的英文原书。 其实在很多年前，网上就开始流传本书的前身DevOps拓扑相关内容。彼时DevOps刚在国内起步，作为一个新鲜玩意儿，大家都不清楚DevOps应该是哪个团队的职责，以及怎样才能在组织内部实践和推广DevOps。DevOps拓扑的出现恰逢其时，它用浅显易懂的图形总结了企业中实践DevOps的几种模式与反模式。是，DevOps拓扑针对组织是否应该组建一个独立的DevOps团队给出了负面的观点，这一时间成为业内争论的热门话题。 随着行业内DevOps知识体系的不断成熟，以及多年以来在企业中身体力行的实践，我越发感受到一个深刻的道理，那就是：很多时候，技术能够解决的问题都不是问题，而的问题在人身上，确切地说是在由个人构成的组织身上。引用我非常尊敬的一的话来说：“所有的事情归根结底都是人的事情，只要人对了，那么事情就都对了，所以组织重要的事情是去发现人、培养人、激发人心中的火花。”对此，我深以为然，可见组织和人的问题才是“Being DevOps”的障碍。 道理虽如此，但组织的问题往往也是难解决的问题。这也是为什么纵观行业内的大会分享主题，大部分人关注的是可以快的自动化工具，而忽略了组织和文化的变革，毕竟组织和文化的变革难以可视化，也更难度量有效性。每家企业所处的行业环境、竞争模式、产品形态和人才结构都不尽相同，组织变革也没有一条普适的“路径”，那么何谈总结出一套通用的组织类型和交互模式呢？于是乎，DevOps中重要的组织和文化渐渐成了一种迷思，即便一些广为流传的案例，也被认为是“别人家的事情，对我们来说并不适用”。可回避问题真的就是解决问题的方法吗？Manuel和Matthew对此给出的答案就在本书中。 我次阅读本书的英文原书是在去年国内疫情为严重的时候，封闭在家，但也多了很多自己的时间。我不得不承认，整个阅读过程充满了艰辛，一方面欧洲作者的艺术气息让整本书充满了大量难懂的词汇和复杂的嵌套语句，另一方面书中涉及的多元文化，大量的人文、社会学知识像一条巨大的鸿沟。回想起我当年次看《持续交付》一书的时候，也是同样的感觉，认知的差距让我很难轻松理解书中的观点和理念。 随着翻译工作的，在逐字逐句的推敲过程中，书中很多闪耀光辉的观点开始慢慢显现，这本书就像一个隐藏的宝藏，总能让你获得感同身受的惊喜及对实际工作的启发。我想说的是，这本书并非一本快餐读物，而是需要结合实际工作场景，静下心来细细品味的作品。无论你是团队管理者、架构师，还是平台产品经理、普通的研发技术人员，都能从书中汲取思想的养分，享受属于你自己的知识盛宴。你会不停地反思组织设计、交互、角色、职责等方面的观点，并且身体力行地在项目行实践。相信我，随着工作经历的丰富，你会慢慢感受到与作者思想同频的愉悦感，而且这本书也能为个人和团队的发展指明方向。 翻译过程历时一年，前后大改了三稿，以行了无数次字斟句酌的优化。很庆幸在整个翻译团队的相互鼓励下本书终于接近完成。在这个过程中，我也深刻地感受到了团队的力量，那就是大家为了共同的目标、共同做成一件事而努力。其中董老师老顽童一般笑看人生的境界，对工作流程的精益求精，雷老师严谨细致的工作作风，对细节的追求，都让我受益良多，我充分感受到了团队协作的魅力。当我写下这段文字的时候，回顾过去一年，内心感慨良多。我们一直秉承追求、谨言慎行的态度，希望你在阅读本书的时候，也能够感受到我们的用心。 感谢博文视点付睿编辑的专业指导和精雕细琢，她是本书的幕后英雄。感谢运维社区的景韵和萧总促成了本书的和出版，他们共同书序是如此文采飞扬、激荡青春。感谢我的家人的支持与理解，正是他们教会了我心中要充满热爱。 “道阻且长，行则将至。”这句话出自《诗经》及《荀子·修身》，意思是前行的道路漫长并充满阻碍，只要坚持心中的火花，就一定能够抵达目的地。组织效能是企业永无止境的追求，愿本书能够陪伴你在这条道路上不断披荆斩棘，在成就他人的过程中也收获属于自己的成长。 石雪峰 2021年5月

1.运维社区创始人萧田国、DevOps时代社区联合创始人景韵联合作序，业内多名专家力荐。 2.全面介绍能团队模式——团队拓扑，为组织设计和团队交互总结了四类团队类型与和三种交互模式，结合案行了的、深入的阐述，对数字化转型中的企业参考价值。 3.本书适合关注软件系统开发和运维过程效率的公层括CTO、CIO、CEO、CFO等）、经理、部门主管、软件和系统架构师，以及所有参与构建和运行软件系统的人阅读，适用于想让系统的交付和运行变得更的任何人。 本书针对以下典型场景并提供了一些建议的阅读方法： √ 希望了解不同的团队类型，以及哪种类型非常。 √ 希望解耦一个巨大的单体软件系统。 √ 希望软件系统架构。 √ 希望提升软件开发团队的效率。 √ 希望提升团队的士气和效率。 √ 希望了解在哪些方面投入可以实现预期的增长。 √ 希望了解如何持续团队拓扑以适应业务变化的需求。