四種基本團隊拓撲#

• 流動對齊團隊（stream-aligned team）：對齊到單一、有價值之工作流的團隊。
• 賦能團隊（enabling team）：由某個技術（或產品）領域專家組成的團隊，用以彌合能力落差。
• 複雜子系統團隊（complicated-subsystem team）：負責建造與維護「高度依賴專家知識」之系統部分的團隊。
• 平台團隊（platform team）：使流動對齊團隊得以高度自主地交付工作。

三種團隊互動模式#

• 協作模式（collaboration mode）：團隊與另一個團隊緊密地一起工作。
• X 即服務模式（X-as-a-Service mode）：以最少的協作消費或提供某物。
• 促進模式（facilitating mode）：協助（或被協助）另一個團隊排除障礙。

核心概念#

• 團隊拓撲（Team Topologies）：一套組織設計模型，為現代軟體密集企業提供一個技術中立的關鍵機制，用以感知何時需要改變策略（無論從業務或技術觀點）。
• 康威定律（Conway’s law）：由梅爾・康威提出的定律，指出系統設計會複製設計它的那個組織的溝通結構。
• 反向康威操作（reverse Conway maneuver）：組織應當演化其團隊與組織結構，以達成所欲的架構。
• 團隊 API（team API）：環繞每個團隊的一組介面。
• 組織感知（organizational sensing）：把團隊及其內外部溝通當作組織的「感官」（視、聽、觸、嗅、味）。
• 變更流動（flow of change）：對某軟體服務或系統一連串相關的更新或變動，通常對齊到使用者目標或業務的其他核心焦點。
• API（application programming interface，應用程式介面）：關於「如何以程式方式與軟體互動」的描述與規格。

認知負荷#

• 認知負荷（cognitive load）：工作記憶中所使用的量。
• 內在認知負荷（intrinsic cognitive load）：關乎問題空間中根本的任務面向。例如：「Java 類別的結構是什麼？」「我要怎麼建立一個新方法？」
• 外在認知負荷（extraneous cognitive load）：關乎任務執行所處的環境。例如：「這個元件要怎麼部署來著？」「這個服務要怎麼設定？」
• 相關認知負荷（germane cognitive load）：關乎為了學習或高效能而需要特別注意的任務面向。例如：「這個服務應當如何與 ABC 服務互動？」
• 領域複雜度（domain complexity）：正透過軟體解決的那個問題有多複雜。
• 鄧巴數（Dunbar’s number）：由人類學家鄧巴（Robin Dunbar）提出，指出 15 是一個人所能信任之人數的上限；其中只有約 5 人能被親近地認識與信任。
• 布魯克斯定律（Brooks’s law）：由布魯克斯（Fred Brooks）提出的定律，指出加新人到團隊裡不會立刻提升團隊的產能。

邊界與單體#

• 限界上下文（bounded context）：把較大的領域（或系統）模型切分成較小部分的單位，每個部分代表一個內部一致的業務領域區塊。
• 斷層面（fracture plane）：軟體系統中一道自然的「接縫」，讓系統能被輕易切成兩個以上的部分。
• 最薄可行平台（thinnest viable platform）：一種審慎的平衡——既讓平台保持精簡，又確保它確實在加速並簡化「建立其上之團隊」的軟體交付。
• 應用單體（application monolith）：一個龐大的單一應用，帶著眾多依賴與職責，可能對外暴露許多服務與／或不同的使用者旅程。
• 資料庫相連的單體（joined-at-the-database monolith）：由數個應用或服務組成，全部耦合到同一個資料庫綱要，使它們難以分別變更、測試與部署。
• 單體式建置（monolithic build）：用一個巨大的持續整合（CI）建置來取得某個元件的新版本。
• 單體式發布（monolithic release）：把一組較小的元件綁在一起成為一個「發布」。
• 單體式模型（monolithic model）：軟體試圖在許多不同的上下文中強加單一領域語言與表述（格式）。
• 單體式思維（monolithic thinking）：對團隊採取「一體適用」的思維，導致對團隊之間的技術與實作取徑施加不必要的限制。
• 單體式工作場所（monolithic workplace）：在同一地理位置上，對所有團隊與個人採用單一的辦公室配置樣式。