描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121410826
1.高效运维社区创始人萧田国、DevOps时代社区联合创始人景韵联合作序，业内多名专家力荐。
2.全面介绍高效能团队模式——团队拓扑，为组织设计和团队交互总结了四类团队类型与和三种交互模式，结合案例进行了递进的、深入的阐述，对数字化转型中的企业极具参考价值。
3.本书适合关注软件系统开发和运维过程效率的公司领导层（包括CTO、CIO、CEO、CFO等）、经理、部门主管、软件和系统架构师，以及所有参与构建和运行软件系统的人阅读，适用于想让系统的交付和运行变得更高效的任何人。
本书针对以下典型场景并提供了一些建议的阅读方法：
√ 希望了解不同的团队类型，以及哪种类型非常高效。
√ 希望解耦一个巨大的单体软件系统。
√ 希望改进软件系统架构。
√ 希望提升软件开发团队的效率。
√ 希望提升团队的士气和效率。
√ 希望了解在哪些方面投入可以实现预期的增长。
√ 希望了解如何持续改进团队拓扑以适应业务变化的需求。
高效能软件开发团队是任何组织能够持续交付价值的关键。
本书主要介绍了高效能团队模式——团队拓扑，为组织设计和团队交互提供了一种实用的、分步的、适应性的模型，将团队视为交付的基础，团队结构和沟通路径能够随着技术和组织成熟度的发展而演变。
在本书中，IT顾问Matthew Skelton和Manuel Pais为读者展示了软件组织设计方面的重大进展。通过行业案例和专项研究，他们设计了一种良好定义的团队间交互和关联方式，这有助于软件架构更清晰、更持续，并将团队间的问题转化为有价值信号，为自治团队提供指导。
本书适合关注软件系统开发和运维过程效率的公司领导层、软件和系统架构师，以及参与到构建和运行软件系统的任何人阅读。
目录
第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和Manuel Pais利用他们丰富的经验，在本书中不仅描述了如何帮助这些多样化形式的团队获得成功，也强调了实际应用中的变量，识别设计本质，指出那些需要回避的反模式。他们非常慷慨地提供了相关工作的指引和洞察，并通过大量的学习案例进一步充实了本书的内容。
《高效能团队模式》通过对这些关键组织模式、动态交互模式及组织进化方面细致入微的展示，丰富了我们对于组织结构的理解。而正是因为本书的清晰和聚焦，使本书可以作为一个实用指南，在组建团队时赋予团队面对挑战迎难而上的能力，帮助现有团队在响应价值交付方面变得更加有效。
——Ruth Malan，Bredemeyer Consulting公司架构咨询师
前言
［现代］组织设计……是基于用户的协作设计。
——Naomi Stanford，摘自 Guide to Organization Design
团队总有忙不完的事情，但如果将团队和业务关联，那么它就成了持续不断交付价值的选择。理想情况下，团队应该长期存在、自我管理并拥有充满热情的成员。但实际上，团队并非孤立存在的，团队需要明白什么时候、如何跟其他人产生交互。而这些交互方式也会随着时间不断演进，从而支持产品和技术在整个生命周期不同阶段的探索和运转。简而言之，组织不仅要努力做到团队自治，还要不断地思考和与时俱进，以便快速地向客户交付价值。
本书提供了一种实用的、分步的、适应性的组织设计模型，我们在不同成熟度的公司业务中都曾实践和观察过这种模型，团队拓扑由此而来。
然而，团队拓扑并非成功构建和运行软件系统的通用模式。即便有些团队的动态组织形式和本书描述和推荐的差异巨大，也并不妨碍他们取得巨大的成功（特别是在那些拥有优秀文化和实践的组织中）。
团队拓扑希望提供一种清晰明了的模式，以满足不同团队和组织的参考和解释的需要，而不是指导大家应该如何操作。我们愿意将团队拓扑看作管弦乐队或大型乐团中的一系列音乐篇章，而不是一个爵士乐小号手的旋律。印刷出来的乐谱有助于大型乐团获得成功，但却无法覆盖一场成功表演的方方面面。大量的细节仍然有待于乐团根据不同的场合、地点，甚至不同的演奏者来即兴发挥。同样地，为了实现完美的软件交付，统一团队语言和共同协作方式所带来的价值是巨大的。
团队拓扑方法希望能够帮助那些纠结于寻找一种合适的方法来优化团队结构的组织，或者那些还没有意识到团队设计可以带给业务产出和实际软件系统良好影响的组织，从而帮助他们获得更加快速和持续的成功。
本书适用于那些关注软件系统开发和运维过程效率的公司领导层（包括CTO、CIO、CEO、CFO等）、经理、部门主管、软件和系统架构师，以及所有参与构建和运行软件系统的人，他们都想要让系统的交付和运行变得更加高效。
我们为什么要写这本书
2013年，为一家英国企业引入DevOps和持续交付的时候，Matthew在博文What Team Structure Is Right for DevOps to Flourish?中早提出了DevOps拓扑模式。那个时候，他提供咨询服务的公司正在努力采用现代软件交付方法，而他创造的拓扑模式为该公司提供了一种与众不同的探索选项。
2015年，Manuel在伦敦举办的QCon软件开发大会上采访了Matthew，当时Matthew作为分享嘉宾介绍了康威定律和早期的DevOps拓扑模式。根据这次分享的内容，后来InfoQ平台发表了文章How Different Team Topologies Influence DevOps Culture？，并且该文章被翻译成多种语言。在此之后，Manuel进一步拓展了DevOps拓扑模式，并融合了来源于社区的贡献。
从此之后，DevOps拓扑模式开始广为流传，在演讲、文章和分享中不断地被引用。它们帮助了世界范围内不同规模和不同领域的组织，思考团队和团队交互如何影响组织文化和软件架构的关系。
随着时间的推移，我们意识到初的DevOps拓扑提供了团队相互关系的静态视图，尽管这对于初期讨论有所帮助，但却难以扩展。通过我们和来自世界各地的培训和咨询机构合作发现，有些团队更适合独立和自治的形式，而另一些团队则通过紧密协作获得了更好的工作效果。于是，我们问自己这是为什么，并通过客户的反馈不断改进我们的想法。
终，这些想法通过《高效能团队模式》一书呈现在你的面前，这是一种动态的、不断发展的组织设计方法，基于不同地域和行业的真实场景总结而来的。
如何使用这本书
《高效能团队模式》是一本工具书，我们的初心是提供交互性的内容，并在有限的篇幅中传递尽可能多的真知灼见。为了达到这个目标，我们进行了精心的设计来帮助你更好地浏览这本书。
首先，本书分为三个部分。
第Ⅰ部分探索了康威定律，阐述了组织交互方式是如何限制我们的系统设计的，以及应该如何顺势而为并将其转变成我们的优势。接下来，我们定义了什么是团队，并研究了那些影响团队协作效率的现实约束。
第Ⅱ部分研究了一组已经在业界被证明了的静态团队模式，以及如何结合康威定律和组织的实际情况来选择其中一种模式。这部分内容可以帮助你思考适合所在组织的团队拓扑，并且提供了如何将团队映射到系统中的指导原则，进一步思考了康威定律和基础团队拓扑。
后，第Ⅲ部分研究了组织设计的进化方法，提供了强大的创新能力和快速交付能力来应对快速变化的外部环境。这部分内容解释了如何使用团队拓扑方法来建立一个对市场和用户需求具有敏感度的组织，并提供了相关的人员招聘和技能方面的指导。
每个部分在开始汇总了所属章节的核心观点。图示和编号贯穿章节始终，这些是你需要了解和掌握的关键信息。我们还提供了一些简单易懂的场景、案例学习和针对不同场景的建议。
后，在本书的配图中，你可以发现各种形状、颜色和模式，它们在本书中拥有一致的含义，说明如图0.1所示。
为了全面了解这些团队类型和交互模式，你应该通读本书，因为本书的主题是随章节层层递进的。不过，我们在编写内容的时候也尽量保证了每一章节的独立性。
为了实现这个目标，针对典型场景，我们提供了一些推荐的阅读方法。
√ 若希望了解不同的团队类型，以及哪种类型效，请查看第 1 章（概览）、第 4 章（静态拓扑）和第 5 章（基本拓扑）。
√ 若希望解耦一个巨大的单体软件系统，请查看第 6 章（边界）和第3 章（团队）。
√ 若希望改进软件系统架构，请查看第 2 章（康威定律）、第 4 章（静态拓扑）和第 6 章（边界）。
√ 若希望提升软件开发团队的效率，请查看第 3 章（团队）、第 6 章（边界）和第 5 章（基本拓扑）。
√ 若希望提升团队的士气和效率，请查看第 3 章（团队）和第 5 章（基本拓扑）。
√ 若希望了解在哪些方面投入可以实现预期的增长，请查看第 1 章（概览）和第 5 章（基本拓扑）。
√ 若希望了解如何持续改进团队拓扑以适应业务变化的需求，请查看第 7 章（动态方面）和第 8 章（拓扑改进和组织意识）。
影响本书的关键因素
除我们自身的经验外，本书还受到了以下几个相关方法和思维方式的强烈影响。首先，我们假设一个组织是一个社会技术系统或一个生态系统，这个系统由个体和团队之间的交互塑造而成。也就是说，一个组织应该是人和技术共同作用的结果。在这方面，本书和以下领域不谋而合：控制论［特别是将组织视为一个“感知系统”，这个理论早可以追溯到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。他们在其中强调了技术影响力并不是恒定的，而是取决于团队和组织如何看待这项技术）。
其次，我们假设“团队”会根据个体的集合和团队在发展运行中得到的培养和支持程度的不同而不同。在这个方面，我的想法来源于Bruce Tuckman（他在1965年发表的论文Developmental Sequence in Small Groups中提出了四个阶段：建模-构造、震荡、规范和表现），Russ Forrester和Allan Drexler（他们在1999年发表的论文A Model for Team-Based Organization Performance中提出了基于团队的组织绩效），Pamela Knight（她在2007年发表的论文Acquisition Community Team Dynamics: The Tuckman Model vs. the DAU Model中发现的证据表明，stroming贯穿于团队生命周期始终），Patrick Lencioni（在他那影响深远的书The Five Dysfunctions of a Team: A Leadership Fable中，他发现了常见的交互问题），以及类似的以团队为核心的理论和研究。
再次，我们假设康威定律（或是与它类似的定律）是软件产品形态的强大动力，组织能够正视这些定律并从中获益。在这个部分，我们借鉴了梅尔·康威、软件架构咨询师和团队组织设计奖得主Ruth Malan、ThoughtWorks技术总监和“逆康威定律”的支持者之一James Lewis，以及其他作者和实践者的作品和思想。
后，我们借鉴了源自大规模开发和运行软件系统的成功实践，包括Adidas、Auto Trader、Ericsson、Netflix、Spotify、TransUnion等公司的实践。这些组织的规模和交付速度使他们有可能从组织结构和团队交互的变化中看到真正的收益，这个过程往往需要持续数月到数年之久。
当你浏览本书时，我们希望你可以获得一些启发，这本书可以改变你对团队、团队结构及团队功能方面的认知。
团队作为IT组织基础的能力单元，是IT治理的坚实着力点。在围绕IT运营转型、IT价值洞察、科技风险治理三大领域的IT新治理模式中，团队组织设计与交互模式是必谈的话题。企业在落地DevOps、FinOps的过程中，需要打造集合业务、财务、科技（开发、测试、运维）的高效能团队模式，构建以价值为导向、兼顾风险、敏捷精细的IT新治理能力。
——杨玲玲，中国信息通信研究院云计算与大数据所治理与审计部副主任（主持工作）
近年来，金融行业广泛通过实施DevOps来进行数字化转型。DevOps的核心在于通过企业级的工具与标准，消除员工个体的差异，快速实现企业级能力的提升。但在实践DevOps的过程中，我们发现团队能力的提升和组织模式的演进依然无法回避，团队作为企业小也是核心的作战单元，终决定了整个企业数字化转型的成效。我们都是企业组织结构的局中人，也应该成为企业组织结构的破局者。本书系统地描述了组织设计模型，包括四类团队类型和三种交互模式，这对我们打造高效能团队很具参考价值。
——温建波，中国工商银行软件开发中心项目办总经理
数字化转型要求企业具备超强的感知、洞察能力，由全方位数据支撑的明智决策能力，快速创新、复制、组装的研发上线能力。如何快速研发上线？精益、敏捷、DevOps、产品制、部落制等都离不开高内聚、松耦合的IT架构，以及与之匹配的开发组织结构。本书以康威定律为基础，结合邓巴理论，通过正向推导、逆向演绎、深入浅出，提供了建立一个灵活、高效团队的方法论，为企业数字化转型建设打下了坚实基础。
——廖 定，锦州银行信息技术部联席总经理
在云原生、DevOps和精益敏捷的大浪潮下，软件开发模式也发生了深刻的变革，然而支撑软件开发的组织架构却多年没有明显变化，已经变得越来越难适应。作为传统金融机构的金融科技负责人，我在企业数字化转型的过程中反复思考我们作为强监管的金融机构，在拥抱新模式时应该用什么样的组织形式来推动有价值的产品开发。本书是少有的介绍敏捷组织架构的图书，全书围绕康威定律阐述了我们需要什么样的组织架构才能更好地推动、提升端到端价值交付的效率，非常值得一读。
——何 波，中泰证券股份有限公司金融科技委员会主任&科技研发部总经理
在DevOps变革中，企业必须选择合适的团队拓扑来提升各个团队之间的协作效能，进而提高DevOps变革的成功概率。康威定律告诉我们有什么样的团队拓扑就会有什么样的软件架构，换言之，团队拓扑设计会在一定程度上限制技术方案的可能性。如果你想深入了解团队拓扑设计与团队协同提效之间的制约与关系，或者你对团队拓扑设计和研发效能提升两者之间的相关性有所疑惑，那么本书都会是你的不二选择。
——茹炳晟，腾讯技术工程事业群基础架构部T4级专家，腾讯研究院特约研究员
评论
还没有评论。