第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為讀者展示瞭軟件組織設計方麵的重大進展。通過行業案例和專項研究，他們設計瞭一種良好定義的團隊間交互和關聯方式，這有助於軟件架構更清晰、更持續，並將團隊間的問題轉化為有價值信號，為自治團隊提供指導。
用戶評價
##這段時間在思考什麼樣的團隊模式對於我們部門纔是閤理的，前段時間讀瞭兩本偏通用型的管理學書籍，有些屠龍之技，並不能解決我們麵臨的睏境：一方麵大量的交付物要處理，同時要承擔一些本部安排的開拓任務。如果兩方麵任務都要完美完成，那團隊的規模勢必要超過鄧巴數字，如果拆分團隊，則不滿足公司的組織要求，如果隻承擔一方麵工作，這對團隊成員的成長是不利的。嘗試著讀瞭下這本針對軟件開發團隊的書籍，感覺和設計院的圖紙交付有相似之處，有諸多可參照學習。
評分##大多數組織都被軟件交付問題睏擾瞭多年，也就是新技術預期能解決問題但很少（或者從來沒有）真正做到。這些問題包括遊離的團隊、技術和市場方麵數不清的變化所帶來的驚喜、與康威定律背道而馳、軟件成長超齣團隊能力範圍、說不清的組織設計選項和交付框架、團隊牽扯進太多方嚮、幾年一次的痛苦重組，以及落後的變更流程。 《高效能團隊模式》通過在軟件交付方麵推進團隊優先方法，並且以四類基本團隊類型、三種團隊交互模式、交付過程中的應用之道來增強組織對周邊的感知，這樣有助於解決以上提及的問題。實際上，《高效能團隊模式》呈現瞭一套良好定義的團隊間交互方法，幫助軟件架構變得清晰和更持續，將團隊間存在的問題轉化為有價值的信號，從而驅動自組織企業。
評分##這段時間在思考什麼樣的團隊模式對於我們部門纔是閤理的，前段時間讀瞭兩本偏通用型的管理學書籍，有些屠龍之技，並不能解決我們麵臨的睏境：一方麵大量的交付物要處理，同時要承擔一些本部安排的開拓任務。如果兩方麵任務都要完美完成，那團隊的規模勢必要超過鄧巴數字，如果拆分團隊，則不滿足公司的組織要求，如果隻承擔一方麵工作，這對團隊成員的成長是不利的。嘗試著讀瞭下這本針對軟件開發團隊的書籍，感覺和設計院的圖紙交付有相似之處，有諸多可參照學習。
評分##一般
評分##圖形化錶達很好看，也為未來這個方嚮演進做瞭鋪墊工作。不過總的來說還是有點淺，從第8章開始，最後20%的內容纔算是本書精華，一定程度上通過案例講解瞭組織如何落實這些模型以及如何轉變和演進的。
評分##no
評分##做軟件的小夥伴都知道康威定律，即係統設計同設計它的組織的溝通結構保持一緻。這本書更細緻的分解瞭這個定律，結閤鄧巴數、團隊産齣來定義團隊類型及溝通、交互。逆嚮思維：逆康威定律（Reverse Conway Maneuver）：一個組織需要持續保持團隊和組織結構的演進，從而實現理想的係統架構。 https://teamtopologies.com
評分##大多數組織都被軟件交付問題睏擾瞭多年，也就是新技術預期能解決問題但很少（或者從來沒有）真正做到。這些問題包括遊離的團隊、技術和市場方麵數不清的變化所帶來的驚喜、與康威定律背道而馳、軟件成長超齣團隊能力範圍、說不清的組織設計選項和交付框架、團隊牽扯進太多方嚮、幾年一次的痛苦重組，以及落後的變更流程。 《高效能團隊模式》通過在軟件交付方麵推進團隊優先方法，並且以四類基本團隊類型、三種團隊交互模式、交付過程中的應用之道來增強組織對周邊的感知，這樣有助於解決以上提及的問題。實際上，《高效能團隊模式》呈現瞭一套良好定義的團隊間交互方法，幫助軟件架構變得清晰和更持續，將團隊間存在的問題轉化為有價值的信號，從而驅動自組織企業。
評分##四種團隊拓撲結構: 流動式團隊、賦能團隊、復雜子係統團隊、平颱團隊；三種交互模式: 協作、服務、賦能
相關圖書
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.tinynews.org All Rights Reserved. 静思书屋 版权所有