第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
· · · · · · (收起)
具体描述
高效能軟件開發團隊是任何組織能夠持續交付價值的關鍵。 本書主要介紹瞭高效能團隊模式——團隊拓撲，為組織設計和團隊交互提供瞭一種實用的、分步的、適應性的模型，將團隊視為交付的基礎，團隊結構和溝通路徑能夠隨著技術和組織成熟度的發展而演變。 在本書中，IT顧問Matthew Skelton和Manuel Pais為讀者展示瞭軟件組織設計方麵的重大進展。通過行業案例和專項研究，他們設計瞭一種良好定義的團隊間交互和關聯方式，這有助於軟件架構更清晰、更持續，並將團隊間的問題轉化為有價值信號，為自治團隊提供指導。
用户评价
##四种拓扑和三种交互在公司以前一个项目上全都体验过，这是一个高敏捷成熟度团队根据自己对于价值交付的理解而自发浮现出来的。 因为翻译要扣掉一星，stream-aligned team翻译成流动式团队太有误导性了，会让人觉得人员流动很大，而实际上人员的流动和随意组织恰恰是一种反模式。
评分##一般
评分##大多数组织都被软件交付问题困扰了多年，也就是新技术预期能解决问题但很少（或者从来没有）真正做到。这些问题包括游离的团队、技术和市场方面数不清的变化所带来的惊喜、与康威定律背道而驰、软件成长超出团队能力范围、说不清的组织设计选项和交付框架、团队牵扯进太多方向、几年一次的痛苦重组，以及落后的变更流程。 《高效能团队模式》通过在软件交付方面推进团队优先方法，并且以四类基本团队类型、三种团队交互模式、交付过程中的应用之道来增强组织对周边的感知，这样有助于解决以上提及的问题。实际上，《高效能团队模式》呈现了一套良好定义的团队间交互方法，帮助软件架构变得清晰和更持续，将团队间存在的问题转化为有价值的信号，从而驱动自组织企业。
评分##需要仔细研读！
评分##一般吧
评分##团队是交付的主体，对于复杂产品，高内聚低耦合的要求不仅针对软件架构，也是对组织的要求。
评分##基于康威定律对架构的影响，总结介绍了四种团队类型、三种团队间典型沟通交互的模式，为团队组织设计提供了抽象模型和理论基础。 总体来说来说值得一读。架构师和管理者的异同点引人深思，架构不再仅仅是技术上的事，团队组织结构将深深影响最终的宏观架构，想要做好大型系统的架构师，最终也必定需要组织和团队的管理设计能力。只有好的管理者，才能成为好的架构师。
评分##行文和翻译都很流畅，很多案例。在经历过很多团队，需要理解团队、组织和软件交付的关系以及如何高效时很有帮助，尤其不能轻视的是平台团队、赋能团队如何与流式团队交互，以及如何组织或拆分这些团队。边界的划分和沟通效率很重要，及时察觉和调整演进也很重要。
评分##这段时间在思考什么样的团队模式对于我们部门才是合理的，前段时间读了两本偏通用型的管理学书籍，有些屠龙之技，并不能解决我们面临的困境：一方面大量的交付物要处理，同时要承担一些本部安排的开拓任务。如果两方面任务都要完美完成，那团队的规模势必要超过邓巴数字，如果拆分团队，则不满足公司的组织要求，如果只承担一方面工作，这对团队成员的成长是不利的。尝试着读了下这本针对软件开发团队的书籍，感觉和设计院的图纸交付有相似之处，有诸多可参照学习。
相关图书
本站所有內容均為互聯網搜索引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 tushu.tinynews.org All Rights Reserved. 求知書站 版权所有