解散高效能團隊比破壞公物更糟：那是企業級的精神病態。

——艾倫・凱利（Allan Kelly），《Project Myopia》

為什麼從團隊開始#

組織行為專家數十年前就知道：現代複雜系統需要有效的團隊表現。德里斯科（Driskell）與薩拉斯（Salas）發現，面對知識密集、需要大量資訊的問題解決任務時，作為凝聚整體運作的團隊，表現遠勝於個人的集合。

即使是過去高度層級化的組織，例如美國陸軍，也已把團隊當作基本作戰單位。退役將領麥克里斯托（Stanley McChrystal）在暢銷書《Team of Teams》中指出，表現最好的團隊「能完成非凡壯舉，並非單純因為成員個人的資歷，而是因為那些成員融合成單一有機體」。

具體到軟體開發：現代軟體密集系統所需變更的速度、頻率、複雜度與多樣性，意味著團隊不可或缺。倚賴個人去理解並有效處理「建造與演化現代軟體所需資訊」的量與性質，是不可持續的。

Google 對自家團隊的研究發現：團隊裡有誰，不如團隊動態來得重要；而在衡量效能時，團隊比個人更重要。

因此，有效的軟體交付必須從團隊開始。有多個面向需要考量與滋養：團隊規模、團隊存續期、團隊關係，以及團隊認知。

以小而長壽的團隊為標準#

本書中的「團隊」有非常特定的意涵：一個由五到九人組成、作為一個單位朝共同目標努力的穩定群體。作者視團隊為組織內最小的交付實體。因此，組織永遠不該把工作指派給個人，只能指派給團隊。在軟體設計、交付與營運的所有面向上，我們都從團隊開始。

在多數組織中，有效團隊的規模上限約為七到九人。例如 Amazon 以「兩個披薩餵得飽」來限制其軟體團隊規模。這個上限（也是 Scrum 等流行框架的建議）源自群體辨識與信任的演化極限，即鄧巴數（Dunbar’s number，得名自人類學家鄧巴 Robin Dunbar）：

• 鄧巴發現 15 是一個人能深度信任之人數的上限
• 其中只有約 5 人能被真正親近地認識與信任

允許團隊成長超過那個神奇的七到九人規模，會危及該團隊所建軟體的可行性——因為信任會開始崩解，不合宜的決策可能隨之而來。組織需要最大化團隊成員之間的信任，而那意味著限制成員數量。

當快速交付變更時，明確地重視並設計出高信任至關重要。高信任是團隊得以創新與實驗的基礎；若信任因群體變大而缺失或減損，交付的速度與安全都會受害。

七到九人法則有例外，但相當罕見。若組織已孕育出極強的信任、互敬與接納失敗的文化，團隊或可運作到約十五人。然而依作者經驗，符合此條件的組織極少。

規模越小越能培養信任#

團隊規模的上限與鄧巴數同樣適用於團隊群組、部門、工作流、事業線等。除了鄧巴數本身，人類學研究顯示我們與人建立關係的類型與深度有明確極限：

有研究者指出，有效社會關係可能還有約 500 與 1,500 的層級（大致以三倍為乘數）。關鍵在於——不管我們喜不喜歡——任何組織內部有效群組的規模都存在自然限制。隨著群體規模增加，成員之間的動態與行為會出現微妙或劇烈的差異，在小規模行得通的樣式與規則，在大規模很可能失效。

因此，在建造與營運軟體系統的組織中，有意識地把團隊群組規模限制在鄧巴數之內相當重要：

• 單一團隊：約五到八人（依產業經驗）
  • 高信任組織：不超過十五人
• 家族（「部落」）：不超過五十人的團隊群組
  • 高信任組織：不超過一百五十人的群組
• 事業處／工作流／損益（P&L）線：不超過 150 或 500 人的群組

組織可以由這些符合鄧巴數的群組層層構成；當其中一個上限被觸及，就產生了「分出另一個半獨立群組」的需要。這種「依鄧巴數擴展」可以想像成一圈圈由小而大的同心圓。

在由軟體系統賦能的產品與服務脈絡中，鄧巴數揭示的極限意味著：不同事業線或工作流中的人數也應被明確限制。當一個部門人數超過五十（或 150、或 500），其與其他群組的內外部動態就會改變。這反過來意味著軟體架構需要與新的團隊群組重新對齊，讓團隊能持續有效地擁有該架構。

這就是作者所稱的「團隊優先架構」（team-first architecture）的一個例子。對許多組織而言，這需要相當新的思考方式；但 Amazon 等公司（以其「兩個披薩」規則）已證明這可以是高度成功且可擴展的取徑。

請預期你需要改變軟體系統的架構，以配合鄧巴數所設下的人類互動極限。微服務這類取徑若以團隊優先的視角來套用，會有幫助。

讓工作流向長壽的團隊#

團隊需要時間才能成形並發揮效能。一個團隊通常需要兩週到三個月以上才能成為有凝聚力的單位。當團隊（若能）抵達那個特殊狀態，它可以比個人單打獨鬥有效數倍。既然要三個月才能高度有效，我們就得在團隊內外提供穩定性，讓它有機會抵達那個層次。

在一個六個月的專案結束、團隊才剛開始表現良好時，就把人重新指派到不同團隊，價值極低。

如布魯克斯（Fred Brooks）在經典著作《人月神話》中所指出的，加人到團隊裡不會立刻提升其產能——這後來被稱為布魯克斯定律。事實上，初期階段很可能反而降低產能：新人需要一段熟悉期，而團隊內的溝通線也隨每位新成員顯著增加。不僅如此，新舊成員都需要情緒上的調適，才能理解並容納彼此的觀點與工作習慣（塔克曼團隊發展模型中的「風暴期」）。

團隊存續期的最佳做法，是保持團隊穩定並「讓工作流向團隊」（如凱利在 2018 年《Project Myopia》所言）。團隊應當穩定但不僵固——只在偶爾且必要時才變動。

• 在高信任組織中，人們每年換一次團隊，對團隊效能不會有重大負面影響。例如在雲端軟體專家 Pivotal，「一位工程師大約每 9 到 12 個月換一次團隊」。
• 在信任程度較低的典型組織中，人們應在同一團隊待得更久（也許十八個月或兩年），並應給予團隊教練支援，以改善並維繫團隊凝聚力。

塔克曼模型以四階段描述團隊表現：形成（forming）、風暴（storming）、規範（norming）、表現（performing）。

然而近年來，奈特（Pamela Knight）等人的研究發現這個模型並不完全準確——風暴其實貫穿團隊的整個生命週期持續發生。組織應當持續滋養團隊動態，以維持高效能。

團隊擁有軟體#

有了小而長壽的團隊，我們就能開始改善軟體的擁有權（ownership）。團隊擁有權有助於提供現代系統所需的關鍵「照護連續性」（continuity of care），使系統保持可運作、合乎目的。

團隊擁有權也讓團隊能以多重「視野」思考——從探索階段到開發利用與執行——以更好地照顧軟體及其可行性。如《Lean Enterprise》所述：

• 視野一涵蓋近期未來，產品與服務在同一年內產出結果
• 視野二涵蓋接下來幾個週期，產品與服務的觸及範圍逐步擴張
• 視野三涵蓋數月之後，需要實驗來評估新服務、產品與功能的市場契合度與適用性

允許多個團隊變更同一個系統或子系統的危險在於：沒有人擁有那些變更，也沒有人擁有隨之而來的混亂。

反之，當單一團隊擁有該系統或子系統，且該團隊有自主權規劃自己的工作時，它就能在「知道自己幾週後會清掉任何權宜修補」的前提下，對短期修補做出明智決策。對這些不同時間視野的意識與擁有權，幫助團隊更有效地照顧程式碼。

軟體系統的每一部分都必須恰好由一個團隊擁有：

• 元件、函式庫或程式碼不應有共享擁有權
• 團隊可以在執行期使用共享服務，但每個運行中的服務、應用或子系統都只由一個團隊擁有
• 外部團隊可以向擁有團隊提交 pull request 或變更建議，但不能自行變更
• 擁有團隊甚至可以信任另一團隊到授予其一段時間的程式碼存取權，但擁有權仍屬原團隊

團隊對程式碼的擁有權不該是領地意識。團隊為程式碼負起責任並照顧它，但個別成員不應覺得這段程式碼是「我的、排除他人」。團隊應把自己看作管家或照護者，而非私有業主。

把程式碼想成園藝，而不是治安勤務。

成員需要團隊優先的心態#

交付的根本手段應是團隊而非個人。若採取這種團隊優先取徑，我們就必須確保團隊裡的人也具備（或發展出）團隊優先的心態。這對某些人可能陌生，但只要有適當的教練與學習時間，許多人都能適應。

要讓團隊運作，成員應把團隊的需要置於自身之上：

• 準時參加站立會議與其他會議
• 讓討論與調查保持在正軌上
• 鼓勵聚焦於團隊目標
• 在開始新工作之前，先協助排除其他成員的阻塞
• 指導新進或經驗較少的成員
• 避免「贏得」爭論，改為協議去探索各種選項

然而，即使有教練支援，仍有些人不適合團隊工作，或不願把團隊需要置於自身之上。這些人會摧毀團隊協作，極端情況下甚至摧毀團隊——他們是「團隊毒素」（team toxic），必須在造成傷害前移除。

這方面已有相當多研究。例如一項研究發現：「相較於自我中心的成員，具集體導向的團隊成員更可能在團隊互動中留意其他成員的任務投入，並提升自身表現。」

擁抱團隊中的多樣性#

在需求與技術快速變化的脈絡中，團隊必須持續找出新穎而具創意的方式來應對挑戰，並與其他團隊有效溝通。

近期在民間與軍事脈絡的研究都強烈顯示：成員背景多元的團隊，傾向更快產出更具創意的解法，也更擅長同理其他團隊的需要。

多元的人員組合似乎也能促成更好的結果，因為成員對軟體使用者的脈絡與需求做出的假設較少。《Peopleware》作者狄馬克（Tom DeMarco）與李斯特（Timothy Lister）觀察到：「一點點異質性，對於形成一支凝聚的團隊可以是巨大的助力。」在探索新可能性的脈絡下，擁有多樣的觀點與經驗，能幫助團隊更快地走遍解法的地景。誠如史丹佛（Naomi Stanford）所說：「人與組織都能從多元的勞動力中獲益，差異在其中激發正向能量。」

獎勵整個團隊，而非個人#

《轉危為安》（Out of the Crisis）作者、精實製造運動關鍵人物戴明（W. Edwards Deming），將「廢除年度或績效評等以及目標管理」列為其管理十四要點之一。

在現代組織中尋求獎勵個人績效，往往帶來糟糕的結果並損害員工行為。

個人獎金一個特別陰險的用法，是公司拿它來調節年終獲利。傑出的個人努力可能因為「今年是危機年」而只拿到很少甚至沒有獎金。這放大了個人功績與實得獎金之間的錯位，導致挫折與動機低落。

採取團隊優先取徑時，整個團隊因其共同努力而獲得獎勵。科技公司 Nokia 在 1990 至 2000 年代極為成功的那些年，其工作方式的一項定義性特徵就是：「組織內部的薪酬差異被刻意壓低。獎金金額小，且通常依團隊與公司整體績效發放，而非個人。」

同樣的原則也適用於訓練預算：整個團隊拿到單一筆訓練預算，而非每人各自一份。如果團隊想在一年內把同一個人送去六、七場研討會，因為他特別擅長回來向團隊分享，那應該是團隊自己的決定。

好的邊界最小化認知負荷#

既已確立團隊是交付的根本手段，組織也必須確保團隊的認知負荷不會過高。一個所負責的軟體系統需要過高認知負荷的團隊，無法有效擁有或安全演化那套軟體。

限制團隊職責以匹配認知負荷#

現代軟體交付中最少被承認的摩擦來源之一，是團隊必須面對的程式碼庫規模與複雜度不斷增長，這在團隊身上製造出無界限的認知負荷。

認知負荷同樣適用於那些較少寫程式、較多執行任務的團隊，例如傳統的維運或基礎設施團隊——他們也可能在職責領域、需維運的應用數量、需管理的工具數量上承受過量認知負荷。

採取團隊優先取徑時，團隊的職責要匹配它所能承擔的認知負荷。這件事的正向漣漪效應，可以改變團隊如何被設計，以及它們在整個組織中如何彼此互動。

對軟體交付團隊而言，認知負荷的團隊優先取徑意味著限制團隊被期待處理的軟體系統規模；也就是說，組織不該允許某個軟體子系統成長到超出負責團隊的認知負荷。這對軟體系統的形態與架構有強烈且相當激進的意涵。

大致而言，為了有效交付與營運現代軟體系統，組織應當：

• 最小化內在認知負荷——透過訓練、良好的技術選型、招募、結對編程等
• 徹底消除外在認知負荷——那些無聊或多餘、留在工作記憶中價值甚低、且往往可自動化掉的任務或指令

如此便能為相關認知負荷留下更多空間，而那正是「加值思考」所在之處。

如前所述，建造與營運軟體系統的團隊有效上限為七到九人，因此任一團隊所能應付的認知負荷也存在上限。許多組織在指派軟體系統各部分的職責時並未考慮認知負荷，反而假設「多加幾個團隊到這個問題上，認知負荷就會被分攤」。實際上，這些團隊只會承受布魯克斯定律所提及的類似溝通與互動壓力。

如果我們讓團隊承擔超出其認知負荷容量的系統部分，它就不再表現得像一個高效能單位，而開始表現得像一群鬆散關聯的個人——每個人都試著完成自己的任務，卻沒有餘裕去思考那是否符合團隊的最佳利益。

限制團隊認知負荷意味著限制團隊工作範圍的子系統或區域大小。德里斯科與同僚在研究論文中也提出這項戰術：「在那些有效團隊協作至關重要的場景中，可能有必要重構任務以降低其要求（亦即透過委派子任務），使注意力得以維持在關鍵任務與團隊協作的線索上。」

同時，團隊也需要空間去持續嘗試降低當前必須應付的內在與外在負荷（透過訓練、練習、自動化及其他有用技術）。

用相對領域複雜度衡量認知負荷#

評估認知負荷有個簡單快速的方法：以不帶評判的方式問團隊：「你覺得自己有發揮效能、能及時回應被交辦的工作嗎？」

這雖非精準的度量，但答案能幫助判斷團隊是否感到超載。若答案明顯是否定的，組織可以套用一些啟發法來理解認知負荷是否過高、為何過高。若確實過高，組織必須採取必要步驟降低它，確保團隊能重新變得有效且主動。附帶的好處是，當成員在工作中看見更多價值與目的，團隊的動機水準也會提升。

試圖用程式碼行數、模組數、類別數或方法數這類簡單度量來判定軟體的認知負荷，是走偏了。

電腦研究者傑伊（Graylin Jay）與同僚在 2009 年發現，有些程式語言就是比其他語言冗長（而在微服務興起之後，多語言系統越來越常見）；且使用更多抽象化與程式碼重用的團隊，會擁有較小、但不必然更簡單的程式碼庫。

衡量認知負荷時，我們真正在意的是領域複雜度——我們試圖用軟體解決的問題有多複雜？「領域」是比「軟體規模」適用範圍更廣的概念。

例如，運行並演化一套支撐持續交付的工具鏈，通常需要相當程度的工具整合與測試，也會需要一些自動化程式碼，但其規模比建造面向顧客的應用所需的程式碼小上好幾個數量級。領域幫助我們全面思考，並使用共通的啟發法。

雖然認知負荷沒有公式，我們仍可評估某團隊所負責之領域的數量與相對複雜度（相對於組織內部而言）。

限制每個團隊的領域數量與類型#

必須說清楚：「這個團隊的領域數量與類型是否恰當？」沒有終極答案。領域不是靜態的，團隊的認知容量也不是。但圍繞相對領域複雜度的推理，能幫助形塑團隊的職責與邊界。

對某個領域的複雜度有疑慮時，永遠優先看負責團隊自己的感受。為了把更多領域「塞進」單一團隊而淡化其複雜度（例如「持續交付的工具多得是，這不難啦」），只會導向失敗。

起手式：辨識出每個團隊必須面對的各個獨立領域，並將它們分類為：

• 簡單（simple）——多數工作有清楚的行動路徑
• 繁雜（complicated）——變更需要被分析，可能需要在解法上迭代幾次才能做對
• 複雜（complex）——解法需要大量實驗與探索

接著透過跨團隊兩兩比較領域來微調分類：領域 A 相對於領域 B 如何？兩者複雜度相近，還是其中一個明顯更複雜？目前的分類反映出這件事了嗎？

四項啟發法：

1. 把每個領域指派給單一團隊。 若某領域對一個團隊而言太大，不要把單一領域的職責拆給多個團隊，而應先把該領域拆成子領域，再把每個新子領域指派給單一團隊（拆解大領域的方法見第 6 章）。
2. 單一團隊（以七到九人的黃金規模計）應該可以容納兩到三個「簡單」領域。 這類領域相當程序化，回應較為機械，領域間情境切換的成本因而較可承受。此脈絡下，一個「簡單」領域可能是只有零星、偶發、直截了當變更的舊系統。不過這裡有個風險：工作性質較例行，可能減損成員動機。
3. 負責「複雜」領域的團隊不應再被指派任何其他領域——連簡單的都不行。原因在於打斷工作流動的成本（解決複雜問題需要時間與專注），以及優先排序的問題（人會傾向一有簡單、可預測的問題進來就先解決，導致複雜問題的解決進一步延宕，而後者往往才是對業務最重要的）。
4. 避免讓單一團隊負責兩個「繁雜」領域。 在八、九人的較大團隊看似可行，但實務上該團隊會表現得像兩個子團隊（各顧一個領域），卻仍被期待每個人都懂兩個領域，這反而推高認知負荷與協調成本。更好的做法是（再招募一到兩人後）拆成兩個五人團隊，使各自更聚焦、更自主。

這些終究只是建議，不是通往成功的既定路徑。請把它們當作起點，隨組織演化與學習而調整。永遠記得：即使領域分配看起來合理，只要做事的團隊仍感到不堪負荷，壓力就會累積、士氣就會削弱，最終導致糟糕的結果。

讓軟體邊界大小匹配團隊認知負荷#

要讓軟體交付團隊保持有效、能夠擁有並演化軟體系統的各部分，我們必須對子系統的規模與邊界配置採取團隊優先取徑。與其抽象地設計系統，我們該做的是設計系統及其軟體邊界，以配合交付團隊可用的認知負荷。

不要在「單體架構」與「微服務架構」之間二選一，而要設計軟體以配合團隊認知負荷的上限。唯有如此，我們才有希望達成可持續、安全、快速的軟體交付。

這種軟體邊界的團隊優先取徑，會導向偏好某些軟體架構風格，例如小而解耦的服務。

要擴大團隊所能負責的子系統或領域規模，就得調校團隊所處的生態系，以最大化其認知容量（降低內在與外在負荷）：

• 提供團隊優先的工作環境（實體或虛擬）
• 限制會議、減少郵件、指派專責團隊或人員處理支援詢問，以最小化團隊在工作週中的干擾
• 改變管理風格——溝通目標與成果，而非執著於「怎麼做」，即麥克里斯托在《Team of Teams》中所稱的「Eyes On, Hands Off」
• 透過良好文件、一致性、良好 UX 及其他開發者體驗實踐，提升其他團隊使用你團隊程式碼與 API 時的開發者體驗（DevEx）品質
• 使用一個明確為「降低其上建造軟體之團隊的認知負荷」而設計的平台

反過來說，若組織沒有團隊優先的辦公空間、良好的管理實踐，尤其是團隊優先的平台，那麼團隊所能承接的軟體子系統規模就會更小。更多的小部件需要更多團隊來處理，成本更高。

以認知負荷為設計依據、對軟體子系統邊界採取團隊優先取徑，意味著更快樂的團隊，以及（最終）更低的成本。

對軟體邊界採取團隊優先取徑還有一項好處：團隊往往更容易對所處理的軟體發展出共享心智模型。研究顯示，團隊心智模型的相似度是團隊效能的良好預測指標——意味著更少的錯誤、更一致的程式碼、更快的成果交付。當我們越來越為團隊最佳化，好處便開始以正向方式複利累積。

「為他人最小化認知負荷」是良好軟體開發最有用的啟發法之一。

設計「團隊 API」並促進團隊互動#

既然把團隊視為交付的根本手段，我們就能開始圍繞團隊來設計其他事物。本節探討團隊 API 與定義良好的團隊互動，藉此產出一個連貫、動態、彼此乾淨溝通的團隊網絡。

定義涵蓋程式碼、文件與使用者體驗的「團隊 API」#

有了穩定、長壽、擁有特定軟體部件的團隊，我們就能開始建立穩定的團隊 API（team API）——環繞每個團隊的一組介面。API（應用程式介面）本是「如何以程式方式與軟體互動」的描述與規格，這裡把這個想法擴展到與團隊的全部互動：

• 程式碼：團隊產出的執行期端點、函式庫、客戶端、UI 等
• 版本化：團隊如何溝通其程式碼與服務的變更（例如以語意化版本 SemVer 作為「不破壞既有東西」的團隊承諾）
• Wiki 與文件：尤其是團隊所擁有軟體的操作指南
• 實踐與原則：團隊偏好的工作方式
• 溝通：團隊在聊天與視訊會議等遠端溝通工具上的做法
• 工作資訊：團隊現在在做什麼、接下來要做什麼、中短期的整體優先序
• 其他：其他團隊與之互動所需的任何事物

團隊 API 應當明確考慮其他團隊的可用性：

• 其他團隊與我們互動時，是輕鬆直接，還是困難而困惑？
• 一個新團隊要熟悉我們的程式碼與工作實踐有多容易？
• 我們如何回應其他團隊的 pull request 與各種建議？
• 我們的團隊待辦清單與產品路線圖，其他團隊容易看見與理解嗎？

要達成有效的團隊優先軟體擁有權，團隊必須持續定義、宣傳、測試並演化自己的團隊 API，確保它對該 API 的消費者（其他團隊）而言合乎目的。

許多構成良好團隊 API 的行為與樣式，同樣也構成良好的平台與良好的團隊互動（平台見第 5 章；承諾理論 promise theory 這種社會技術系統中以團隊為本的合作取徑見第 7 章）。

促進團隊互動以建立信任、覺察與學習#

提供時間、空間與經費，讓來自不同團隊、具備相似技能與專業的人聚在一起彼此學習、發展專業能力，是重要的。

藉由明確地為團隊與個人的相互溝通及學習挪出時間與空間，組織能把學習與信任建立變成促成有效團隊互動的節奏之一。有兩種關鍵方式能幫助團隊建立信任、覺察與學習新事物：

1. 有意識設計的實體與虛擬環境
2. 離開座位的時間——公會（guild）、實踐社群（communities of practice，一群人自願定期聚會，共同學習並分享某個關注領域的知識）、內部技術研討會等

由於這類團隊互動位於主要軟體系統的日常建造與營運之外，康威定律扮演的角色不那麼明顯，團隊之間得以發生更自由的交叉聯結。

關鍵在於：如艾克斯羅（Robert Axelrod）與伯吉斯（Mark Burgess）的開創性研究所發現，有機會在這些場合預演團隊互動的團隊，在實際建造與營運軟體系統時，往往更容易與其他團隊互動。

明確設計實體與虛擬環境以促進團隊互動#

有意識設計的實體與虛擬環境，是團隊學習與建立信任的必要條件。然而，不同的人在不同時候需要不同環境才能有生產力：

• 有些任務（例如實作並測試一個繁雜的演算法）可能需要全神貫注與低度噪音
• 有些任務則需要高度協作的做法（例如定義使用者故事與驗收條件）

整天戴著耳機工作的人會被視為不合群，其行為也不促進互動與協作；但實情很可能是辦公環境普遍嘈雜，而這些人需要安靜環境才能發揮效能。

個人隔間與全開放式座位，一般而言都不適合團隊——我們需要更好的東西。 團隊需要能夠頻繁地在內部協作，並只偶爾對外（與其他團隊）協作。這種平衡在開放式配置（團隊沒有專屬工作區）與個人工作間配置（相處時間得提前規劃、會議室又常常不夠）中都很難達成。

Spotify 在成長早期就認識到這點，並據此安排辦公空間以同時支持兩種需求。2012 年，時任 Spotify 的克尼伯格（Henrik Kniberg）與伊瓦森（Anders Ivarsson）談到：「一個部落中的小隊全都在同一間辦公室，通常緊鄰彼此，而附近的休憩區促進了小隊之間的協作。」

為有效軟體交付而做的辦公室設計，應當同時容納以下三種工作模式：

• 專注的個人工作
• 協作的團隊內工作
• 協作的團隊間工作

另外，讓工作區明確標示出正在進行的工作類型，也有助於減少干擾與不必要的打斷。

案例研究：CDL 以團隊為核心的辦公空間

——蘭伯特（Michael Lambert），CDL 開發部主管；魯比奧（Andy Rubio），CDL 開發團隊領導

CDL 是一家英國公司，在競爭激烈的零售保險業居市場領導地位。

CDL 的敏捷旅程讓他們在許多方面演化。從一開始，他們就有讓敏捷團隊共同辦公的餘裕。搬進新辦公室、又很快不敷使用之後，他們把許多開發專案團隊搬回舊總部，那裡有多間小型專案室可供開發團隊安家。他們喜歡這帶來的空間感與擁有感，但跨團隊溝通與對其他團隊的能見度則較不理想。因此在新家「The Codeworks」興建時，他們認真思考了開發區域的配置該長什麼樣。

設計原則與取捨：

• 一切都要可視化，所以大量磁性白板是必需品
• 喜歡舊建築給的團隊空間，但需要更少的團隊孤立
• 若團隊空間不足、或只有小隔間群集與緊湊的馬蹄形排列，會議室的可用性就會變成大問題
• 理想上兩者兼得：既有讓團隊把事情做完的團隊空間，也有讓團隊協作與分享的開放性

最終方案：「長桌隔間」（benched bay）——每個團隊一張長桌，兩側以白板隔板夾住。團隊若靠到端牆，就把牆漆上智慧塗料以便書寫。

關於團隊規模與成長：長桌配置讓成長變得容易，尤其在沒有支撐腳與桌下櫃擋路時——小團隊可以攤開，成長中的團隊可以擠一擠。當然這有極限：團隊太大時就一分為二，各自認領待辦清單功能上的一半。這麼做的妙處在於，每個團隊都帶著舊團隊的文化走，日後才逐漸分化成長；運氣好的話，還能跳過從零開始組隊的「風暴期」與「規範期」。他們也刻意設計了不同大小的隔間，可以多容納一兩張桌子。

持續調整：

• 一開始長桌置於白板隔板之間的正中央且左右對稱，但很快發現不對稱的配置好得多——長桌靠近其中一側隔板，一邊留出更多空間供團隊聚集，另一邊的白板仍能有效使用。
• 為新的數位團隊裝修頂樓時，他們沿用了這些心得。原本的隔板是昂貴、笨重、移動代價高的結構；新的數位空間改用大量大型、可移動但仍具份量的白板，團隊得以自行重新配置與分隔。

這個設計絕非完美——所有空間都在某方面有所妥協。他們也會做錯，但持續學習與調整。其中一項實驗是移除沿著團隊長桌中央的小型玻璃隔板；另一項則是在每組長桌末端設置可調高度的區段，供站立辦公或需要更多腿部空間的人使用。

如 CDL 的案例所示，實體工作環境對團隊「以有用方式互動」的能力有顯著影響。成功的組織會確實花時間與金錢，為員工打造良好的實體環境。

虛擬環境的設計#

隨著許多組織採用遠端優先政策，虛擬環境日益重要。虛擬環境包含 wiki、內外部部落格與組織網站、聊天工具、工作追蹤系統等數位空間。

有效的遠端工作不只是備齊必要工具。團隊還需要就工作時間、回應時限、視訊會議、溝通語氣等實務面向建立共同的基本規則——這些若被低估，即使工具一應俱全，也足以成就或摧毀一個分散式團隊。

從有效溝通的角度，虛擬環境應當易於導覽，快速引導人們找到正確答案。特別是聊天工具的頻道或空間名稱，應當易於預測與搜尋，並以前綴分組：

#deploy-pre-production
...
#practices-engineering
#practices-testing
...
#support-environments
#support-logging
#support-onboarding
...
#team-vesuvius
#team-kilimanjaro
#team-krakatoa

在虛擬環境中，於使用者名稱上採用命名慣例也很有用，能讓人輕易辨識誰在哪個團隊——尤其當該團隊是提供平台或元件的中央「X 即服務」團隊時（見第 5 章）。

與其在聊天工具與 wiki 中只顯示「Jai Kale」，不如用「[Platform] Jai Kale」來標示 Jai Kale 屬於平台團隊。

警告：工程實踐是地基#

歸根結底，技術團隊必須投資於已被驗證的團隊實踐：持續交付、測試優先開發，以及對軟體可運作性（operability）與可發布性（releasability）的重視。少了它們，所有投入於團隊優先取徑與流動的努力都會被大幅削弱，至少也是事倍功半。

• 持續交付實踐支撐假說驅動開發與自動化
• 可運作性實踐提供早期且持續的維運檢查與發現
• 可測試性實踐與測試優先開發提升解法的設計品質與合目的性
• 可發布性實踐確保交付管線被當作一等產品來對待

以上全部都是快速流動的關鍵，且需要所有工程團隊的持續投入。

本章總結：限制團隊認知負荷並促進團隊互動，才能更快#

在快速變化且充滿挑戰的脈絡中，團隊比個人的集合更有效。從美國軍方到大大小小的企業，成功的組織都把團隊視為完成工作的根本手段。團隊通常小、穩定且長壽，讓成員有時間與空間發展出自己的工作樣式與團隊動態。

重要的是，由於團隊規模有上限（鄧巴數），單一團隊所能承受的認知負荷也存在有效上限。這強烈暗示了任一團隊所應處理之軟體系統的規模與領域複雜度也應有上限。團隊必須擁有其所負責的系統或子系統；在多個程式碼庫上工作的團隊，缺乏擁有權，尤其缺乏理解並維持對應系統健康所需的心智空間。

團隊優先取徑為各種各樣的人在組織中發光提供了機會。

在一個把個人原子化的組織裡，人得靠厚臉皮或韌性才能存活；而在團隊優先的組織裡，人擁有在團隊脈絡中發展技能與實踐的空間與支持。

關鍵在於：日常工作的溝通重心從「個人之間」轉向「團隊之間」，組織因而能支持各種各樣的溝通偏好——從最擅長一對一交流的人，到喜歡大團體討論的人皆然。此外，過去具破壞性之個人的影響也被抑制。這種人本取徑，正是選擇團隊優先的一項巨大效益。