《高效能团队模式：支持软件快速交付的组织架构（全彩）》_项目管理书籍_

用户名密码

·VIP会员申请
·施工企业管理
·联盟特刊下载
·工程软件光盘

新闻 | 文库 | 培训 | 软件 | 书籍 | 专题 | 认证 | 招聘 | 下载 | PM俱乐部

联盟访谈电子杂志个人专栏新闻专题 PROJECT 互动： 案例咨询论坛博客

职业认证: PMP NPDP PgMP IPMP P2 MPM 建造师 行业应用: 基础工程软件制造活动研发

服务区	网站登录：个人会员企业会员专家企业服务：PMP培训内训课公开课工具箱：发表文章提问题交案例

搜索： 项目管理者联盟PMP培训班（2018年度）项目管理者联盟NPDP培训班（2018年度）

邮购方法

发邮件到:member@mypm.net
a. 姓名
b. 通信地址/邮编(您收书的地址)
c. 书籍购买信息：什么书多少本
d. 汇款信息：汇款方式汇款时间汇款金额
汇款至项目管理者联盟
方式 A：在线支付
方式 B：邮局汇款
收款人：华琰
汇款地址：北京市西城区德外新丰街2号A座705室
邮编:100088
方式 C：银行汇款
开户名：宣晓锋
开户行：工商银行北京市西城区黄寺大街储蓄所
帐号：0200219601020858639
工作人员核对汇款信息与购买信息后，即日发书
备注:
1.每单收5元邮寄费用
2.汇款总金额=书籍总金额+5元
3.书籍用挂号寄出,约2周左右寄到
4.如需使用快递购买,快递费由买方支付
5.如需开具发票,请提供发票开头.并加付书籍总金额5％的费用.
6.电话咨询：010-82273401/11/37-11

经典书籍


	原价 49元

书名：《项目百态—软件项目管理面面观》

原价
48元

书名：《项目思维:为什么很好的项目经理会做出糟糕的项目决策》

原价
108 元

书名：《项目管理最佳实践方法达成全球卓越表现》

邮购热线：

member@mypm.net

010-82273401-11

市场价：￥89元

本站优惠价：￥0元

高效能团队模式：支持软件快速交付的组织架构（全彩），*

【译者】
【著者】	（英）Matthew Skelton（马修·斯凯尔顿），（西班牙）Manuel Pais（曼纽尔·派斯）
【书号】	9787121410826
【出版日期】	2021年08月
【出版社】	电子工业出版社

【字数千】
【页数】
【所属行业】	综合应用
【所属主题】	项目团队管理

本站优惠价 0("0"表示无存货)邮购热线:member@mypm.net；010-82273401-11

内容简介

高效能软件开发团队是任何组织能够持续交付价值的关键。

本书主要介绍了高效能团队模式——团队拓扑，为组织设计和团队交互提供了一种实用的、分步的、适应性的模型，将团队视为交付的基础，团队结构和沟通路径能够随着技术和组织成熟度的发展而演变。

在本书中，IT顾问Matthew Skelton和Manuel Pais为读者展示了软件组织设计方面的重大进展。通过行业案例和专项研究，他们设计了一种良好定义的团队间交互和关联方式，这有助于软件架构更清晰、更持续，并将团队间的问题转化为有价值信号，为自治团队提供指导。

本书适合关注软件系统开发和运维过程效率的公司领导层、软件和系统架构师，以及参与到构建和运行软件系统的任何人阅读。

作者介绍

本书作者：

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权威指南》联合译者，曾先后就职于新浪网、摩托罗拉、诺基亚、爱立信、乐视致新等国内外知名企业，专注于互联网、电信、金融、无人驾驶汽车等行业的软件工程效率提升。

图书目录

序言前言

目录
第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等公司的实践。这些组织的规模和交付速度使他们有可能从组织结构和团队交互的变化中看到真正的收益，这个过程往往需要持续数月到数年之久。

当你浏览本书时，我们希望你可以获得一些启发，这本书可以改变你对团队、团队结构及团队功能方面的认知。

发表评论

书籍评论

如转载本站文章，必须于文章开头处注明转自“项目管理者联盟”，并注明原作者