高效能团队模式

作者:Matthew Skelton

页数:232

译者:石雪峰

出版时间:2021-8-1

价格:89.00元

装帧:平装

isbn号码:9787121410826

具体描述

高效能软件开发团队是任何组织能够持续交付价值的关键。 本书主要介绍了高效能团队模式——团队拓扑，为组织设计和团队交互提供了一种实用的、分步的、适应性的模型，将团队视为交付的基础，团队结构和沟通路径能够随着技术和组织成熟度的发展而演变。 在本书中，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一书的合著者。

目录信息

目录
第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
· · · · · · (收起)

读后感

这本书提出了一个很有意思的观点 ---- 改进组织架构以改善对用户提供的解决方案。该书的理论基础是[Conway's Law]。 “organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations...

这本书提出了一个很有意思的观点 ---- 改进组织架构以改善对用户提供的解决方案。该书的理论基础是[Conway's Law]。 “organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations...

这本书提出了一个很有意思的观点 ---- 改进组织架构以改善对用户提供的解决方案。该书的理论基础是[Conway's Law]。 “organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations...

这本书提出了一个很有意思的观点 ---- 改进组织架构以改善对用户提供的解决方案。该书的理论基础是[Conway's Law]。 “organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations...

这本书提出了一个很有意思的观点 ---- 改进组织架构以改善对用户提供的解决方案。该书的理论基础是[Conway's Law]。 “organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations...

用户评价

这本书，说实话，拿到手里的时候，我对它的期望值其实是比较高的，毕竟“高效能”这三个字在如今这个快节奏的工作环境中，简直就是圣经一样的存在。我当时心里盘算着，这本书肯定会像一本操作手册，手把手地教我如何搭建起一个无懈可击的团队架构，里面少不了各种流程图、KPI设定标准，以及如何运用最新的敏捷开发或者项目管理工具来压榨出团队每一滴潜力。我甚至想象了里面会详细分析那些“独角兽”企业成功的秘诀，比如谷歌、亚马逊那些耳熟能详的案例，把他们的组织结构图扒得底干净净，然后告诉我们普通公司该如何照猫画虎。我期待看到的是一种冰冷而精确的科学，一种可以量化的、可复制的“高效”公式。毕竟，大家都想找到那个能让团队效率瞬间提升的“开关”，而不是那种虚无缥缈的“文化建设”或者“凝聚力”之类的空话。我希望它能给我提供一些立竿见影的战术层面的指导，比如如何组织一次高效的站会，如何处理那些拖后腿的成员，以及如何通过激励机制快速激发士气。读完后，我发现它似乎更侧重于一种更高维度的思考，而不是我最初期望的那种具体工具箱。

坦白说，这本书的深度和广度超出了我最初的预估。我原本以为它顶多也就是一本关于“人际沟通技巧”或者“目标设定方法论”的进阶读物，但它实际上探讨的问题更加宏大，触及到了组织哲学的层面。作者似乎花了大量的篇幅去解构“协作”的本质，探讨了信任的建立究竟是一个心理学问题，还是一个系统设计问题。他没有满足于给出“要多沟通”这样的老生常谈，而是深入挖掘了信息流在团队内部是如何被扭曲、阻碍和有效利用的。读到后面，我感觉自己像是在拆解一个复杂的时钟，作者耐心地向我展示了每一个齿轮——从个体动机到跨部门协作，每一个环节是如何相互咬合，共同驱动整个机器运转的。这种对底层逻辑的追问，让我开始反思自己过去几年里对“团队”这个概念的理解，发现很多自以为是的基础认知可能并不牢固。

这本书的行文风格，初看起来非常具有煽动性，它开篇就抛出了一些非常尖锐的观点，直指当前许多企业在团队建设上的积弊，那种感觉就像是请了一位资深顾问，在你面前毫不留情地撕开那些光鲜亮丽的报告背后的真相。作者似乎非常擅长用讲故事的方式来引导读者进入他的思维框架，而不是堆砌枯燥的理论。我印象最深的是他描述“无效会议”的那一段，那种描绘简直是栩栩如生，让人看了忍不住在心里给自己的老板和同事对号入座，甚至会心一笑，因为我们都曾深陷其中。它不像那种学术著作，需要你查阅大量背景资料才能理解，反而更像是与一位经验丰富、略带愤世嫉俗但绝对真诚的前辈在深夜把酒言欢，听他倾诉这些年趟过的那些坑。他的语气中带着一种对平庸的厌倦和对卓越的执着追求，这种情绪很容易感染读者，让人读着读着就觉得自己的血液都在加速流动，恨不得马上放下书本，去改造自己的部门。

这本书最让我印象深刻的，是它对于“失败”的态度。很多关于团队管理的书籍都会将重点放在如何规避错误，如何追求完美，仿佛成功是唯一的出路。但这本书却花费了相当大的篇幅来探讨一个组织如何安全、有效地从失败中学习，以及如何将“可接受的失败”嵌入到日常的工作流程中去。作者并没有将失败描绘成洪水猛兽，而是将其视为一种高价值的“数据采集点”。他详细分析了那些成功的创新型团队，并非因为他们犯错少，而是因为他们能以极快的速度从每次小挫折中提取出关键信息，并迅速调整方向。这种“拥抱不确定性”的视角，极大地缓解了我在日常工作中对于风险的过度恐惧。它提供了一种更健康的心态，去面对工作中必然出现的偏差和不如意，将压力转化为一种对更优解的探索动力。这本书的价值在于，它教人如何在充满变数的现实世界中，保持前进的韧性。

这本书的阅读体验是极其不连贯的，但这种“不连贯”恰恰是它的魅力所在。有时候，你会读到一些非常实用的、可以直接抄作业的“即插即用”工具，比如如何设计一个有效的反馈循环，或者一个针对跨文化团队的简易冲突解决流程；但下一章节，作者可能又会突然跳跃到对领导力与谦逊之间辩证关系的哲学思辨上，让你不得不停下来，陷入沉思，甚至开始怀疑自己是不是真的够“谦逊”。这种在“战术执行”和“战略思考”之间的大幅摆动，使得这本书的阅读曲线非常富有张力。它迫使你不断地在“我该怎么做”和“我为什么这么做”之间进行切换和校准，而不是让你沉溺于任何一个单一的层面。对于那些习惯于线性阅读的人来说，这可能会造成一定的阅读障碍，但对于渴望全面提升的读者，这种跳跃反而能带来更深层次的启发。

行文和翻译都很流畅，很多案例。在经历过很多团队，需要理解团队、组织和软件交付的关系以及如何高效时很有帮助，尤其不能轻视的是平台团队、赋能团队如何与流式团队交互，以及如何组织或拆分这些团队。边界的划分和沟通效率很重要，及时察觉和调整演进也很重要。

一般

一般吧

这段时间在思考什么样的团队模式对于我们部门才是合理的，前段时间读了两本偏通用型的管理学书籍，有些屠龙之技，并不能解决我们面临的困境：一方面大量的交付物要处理，同时要承担一些本部安排的开拓任务。如果两方面任务都要完美完成，那团队的规模势必要超过邓巴数字，如果拆分团队，则不满足公司的组织要求，如果只承担一方面工作，这对团队成员的成长是不利的。尝试着读了下这本针对软件开发团队的书籍，感觉和设计院的图纸交付有相似之处，有诸多可参照学习。

行文和翻译都很流畅，很多案例。在经历过很多团队，需要理解团队、组织和软件交付的关系以及如何高效时很有帮助，尤其不能轻视的是平台团队、赋能团队如何与流式团队交互，以及如何组织或拆分这些团队。边界的划分和沟通效率很重要，及时察觉和调整演进也很重要。