系統的架構會被固化在開發它的那些團隊的形態之中。

——魯絲・馬蘭（Ruth Malan），〈Conway’s Law〉

把團隊類型收斂成四種#

許多組織裡團隊類型五花八門，甚至有團隊同時扮演多重角色（例如「基礎設施與工具團隊」）。這種蔓生讓所有人都難以看清整體組織地景：

• 我們配置了對的團隊嗎？
• 有沒有哪些領域缺乏能力、沒有任何團隊在處理？
• 團隊在自主性與「來自其他團隊的支援」之間，取得必要的平衡了嗎？

只要把團隊變體收斂成四種基本團隊拓撲，這些問題就容易回答得多：

• 流動對齊團隊（stream-aligned team）
• 賦能團隊（enabling team）
• 複雜子系統團隊（complicated-subsystem team）
• 平台團隊（platform team）

只要謹慎使用，建造與營運現代軟體系統就只需要這四種拓撲。搭配有效的軟體邊界（第 6 章）與團隊互動（第 7 章），把團隊類型限制成這四種，就成為有效組織設計的強力範本。

這四種基本拓撲應當作為所有團隊類型的「磁極」。所有團隊都該朝這四個磁極之一移動——也就是說，我們偏好這些類型，並致力讓組織中的每個團隊都採用這些基本類型的目的、角色、職責與互動行為。

把團隊類型簡化到只剩這四種，有助於減少組織內的模糊性。羅（Jiao Luo）與同僚 2018 年發表的研究指出，減少組織角色上的模糊性，是現代組織設計成功的關鍵之一。

大型或中型組織很可能每種基本拓撲都有一到多個團隊：多個流動對齊團隊是起點；此外可能有數個平台團隊、幾個目的各異的賦能團隊（也許一個處理 CI/CD、另一個處理基礎設施或架構），以及——若真有嚴格必要——一兩個複雜子系統團隊。

基本拓撲裡沒有「Ops」團隊或「支援」團隊，而這是刻意的。建造系統的長壽團隊非常貼近其所建系統的線上運作，不存在交接給獨立 Ops 或支援團隊這回事；即使採用 SRE 樣式（見第 4 章），團隊之間也是緊密對齊的。

流動對齊團隊遵循良好的軟體交付實踐（如持續交付與可運作性），並對線上運作負責，即使當下寫的程式碼很少。實際上，Ops 與支援大體上也是與流對齊的。

流動對齊團隊#

「流」（stream）是與某個業務領域或組織能力對齊的持續工作流動。持續流動需要目的與職責的清晰，好讓多個團隊得以共存，各有自己的工作流動。

流動對齊團隊是與單一、有價值的工作流對齊的團隊——可能是單一產品或服務、單一組功能、單一使用者旅程，或單一使用者輪廓（persona）。更進一步，該團隊被賦權去盡可能快速、安全、獨立地建造並交付顧客或使用者價值，不需要交接部分工作給其他團隊。

流動對齊團隊是組織中的主要團隊類型，而其他三種基本拓撲存在的目的，就是減輕流動對齊團隊的負擔：

• 賦能團隊的任務，是幫助流動對齊團隊取得所欠缺的能力，代為承擔研究與試驗的心力，並建立起成功的實踐。
• 平台團隊的任務，是把較低層次的細節知識（如佈建、監控、部署）卸載掉，並圍繞它們提供易於消費的服務，藉此降低流動對齊團隊的認知負荷。

因為流動對齊團隊涵蓋交付的完整光譜，他們必然更貼近顧客，能在監控自家軟體於正式環境運行的同時，快速納入顧客回饋。這樣的團隊能近乎即時地對系統問題做出反應，隨需要調整工作方向。用萊納特森（Don Reinertsen）的話說：「在產品開發中，當我們用的是一支高技能的小團隊而非大團隊時，我們能更快地改變方向。」

一個組織中可以並存多種流：特定顧客流、業務領域流、地理流、產品流、使用者輪廓流，甚至（在高度受監管產業中的）法遵流。一個流甚至可以是大公司內部的微型企業，有獨立的焦點與目的（例如在尚不存在的產品上創新）。

無論流動對齊團隊對齊的是哪一種變更流，該團隊都應以長期、可持續的方式被資助，作為某個投資組合或工作方案的一部分——而非一個轉瞬即逝的專案。

在現代軟體組織中，我們預期多數團隊都是流動對齊的。工作流動清晰，每個流都有穩定、可預期的工作流動供該團隊排序。這與傳統的工作分派形成鮮明對比：後者是把「單一顧客的大型請求」或「多個顧客的一堆小請求」翻譯成一個專案；專案一旦核准並取得資金，就會有數個團隊（前端、後端、DBA 團隊）被捲進來，還得把新工作硬塞進既有待辦清單。

Amazon 的兩個披薩團隊模型正是流動對齊團隊的例子：團隊高度獨立、擁有自己的服務、並對自己所寫軟體的執行期成敗負責。Amazon 使用這個模型超過十七年這件事本身，就顯示了「讓團隊對齊到獨立的變更流」有多有效。

流動對齊團隊內部的能力#

一般而言，每個流動對齊團隊都需要一組能力，才能把工作從最初的（需求）探索階段推進到正式環境。這些能力包括（但不限於）：

• 應用安全
• 商業與維運可行性分析
• 設計與架構
• 開發與編碼
• 基礎設施與可運作性
• 度量與監控
• 產品管理與擁有權
• 測試與品質保證
• 使用者體驗（UX）

關鍵是不要假設每項能力都對應到團隊裡的一個角色——那意味著團隊至少要有九人才湊得齊上述清單。

我們談的是：團隊作為一個整體，有能力理解上述面向並據以行動。這可能意味著由一批通才加上少數專才混合組成。若只有專業分化的角色，那麼每當某件工作依賴某個當下正忙的專才時，就會出現瓶頸。

由 Google 首創的網站可靠性工程（SRE）團隊，其實是一種特殊的流動對齊團隊——就「他們對正式環境中大規模應用的可靠度負責」這層意義而言。SRE 團隊主要與一個或多個負責開發應用的流動對齊團隊互動，而軟體變更的流動也高度與某個流對齊。

為什麼叫「流動對齊」，而不是「產品」或「功能」團隊？#

過去許多軟體交付框架用「產品團隊」或「功能團隊」來指稱那些「有權交付有價值之端到端軟體增量」的團隊。但如今，談「流」比談「產品」或「功能」更合理：

• 強化對流動的關注——把團隊的目的與一個流對齊，有助於在組織層級強化對流動的重視；一個流應當暢行無阻。
• 端到端體驗已然不同——隨著 IoT、無處不在的嵌入式裝置與整體性的服務管理取徑興起，顧客互動的對象不再只是一段離散的軟體，而是一系列運行著各類軟體的產品與裝置（從行動、嵌入式到語音操控）。顧客也透過多重通路（面對面、社群媒體、網站、電話）與品牌互動，期待一致的回應與介面。
• 「產品」的意義過於分歧——在這種多通路、高度連結的脈絡下，「產品」可以指涉極為不同的東西，使人難以理解「產品團隊」的職責究竟是什麼。例如在製造業公司，產品可能是一個由工程團隊建造數年、待其被取代後團隊即解散的定壽實體裝置。
• 並非所有軟體情境都需要產品或功能（尤其是那些聚焦於提供公共服務的情境），但所有軟體情境都能從「對齊流動」中獲益。

在《Designing Delivery》中，蘇斯納（Jeff Sussna）談到團隊需要納入「持續設計」（continuous design）能力來迎接這些挑戰：透過持續設計，我們「把服務、回饋、失敗與學習這類想法當作一等概念來對待」。而要促成這件事，最好的方式正是採取一種強調流動的、流動導向的變更視角。

預期的行為#

流動對齊團隊的任務，是確保特定流的工作順暢流動（通常與某個業務領域相關，但不總是如此）。一個有效的流動對齊團隊，我們預期看到什麼行為與成果？

• 目標是產出穩定的功能交付流動
• 能依據最近變更的回饋快速修正航向
• 對產品演化採取實驗性取徑，期待不斷學習與調適
• 把交接給其他團隊的工作降到最少（理想上是零）
• 評量的依據是它所產出可持續的變更流動（並輔以若干技術與團隊健康度指標）
• 必須有時間與空間處理程式碼品質的變更（有時稱「技術債」），以確保變更程式碼仍然安全且容易
• 主動且定期接觸支援性的基本拓撲團隊（複雜子系統、賦能、平台）
• 成員感覺自己已達成、或正走在達成「自主、精熟、目的」的路上——依品克（Daniel Pink）的說法，這是投入型知識工作者的三個關鍵要素

賦能團隊#

《Accelerate》告訴我們，高效能團隊會持續改善自身能力以保持領先。但一個負有端到端擁有權的流動對齊團隊，要從哪裡擠出空間去研究、閱讀、學習與練習新技能？他們同時還承受著快速交付與快速回應變化的持續壓力。

賦能團隊由某個技術（或產品）領域的專家組成，用以彌合這道能力落差。 這類團隊橫跨各個流動對齊團隊，並擁有必要的餘裕去研究、試驗選項，並就合適的工具、實踐、框架，以及應用堆疊周邊的生態系選擇提出有依據的建議。這讓流動對齊團隊得以取得並演化能力，而不必自行投入相應的心力。

依作者經驗，這類心力及其對團隊其餘部分的衝擊，往往被低估了十到十五倍。

賦能團隊具有強烈的協作性質；他們積極去理解流動對齊團隊的問題與不足，以便提供有效的引導。艾克斯坦（Jutta Eckstein）稱之為「技術顧問團隊」——這個定義相當貼合我們對顧問團隊的期待：提供引導，而非代為執行，無論其位於組織內或組織外。

賦能團隊積極避免自己變成知識的「象牙塔」，去指定技術選擇讓其他團隊照辦；同時仍協助團隊理解並遵循組織層級的技術限制。這近似於「僕人式領導」的想法，只是套用在團隊互動而非個人身上。

賦能團隊的終極目標，是先聚焦於流動對齊團隊的問題本身、而非解法本身，藉由培育其能力來提升其自主性。

如果賦能團隊做得好，它所協助的團隊在幾週或幾個月後就不該再需要它的協助——不該存在對賦能團隊的永久依賴。

用格林里夫（Robert Greenleaf）的這組啟發法來引導賦能團隊的行為與動力：「被服務的人，作為人是否成長了？他們在被服務的同時，是否變得更健康、更有智慧、更自由、更自主？」

單一賦能團隊可以對應到前述流動對齊團隊能力清單中的任一項（使用者體驗、架構、測試等），但他們往往聚焦於更特定的領域，例如建置工程、持續交付、部署，或特定客戶端技術（桌面、行動、網頁）的測試自動化。舉例來說，賦能團隊可能會架起一副部署管線的「走路骨架」（walking skeleton），或一個結合自動化工具與若干初始情境和範例的基礎測試框架。

賦能團隊與流動對齊團隊之間的知識轉移，可以是暫時性的（例如流動對齊團隊要導入容器化這類新技術時），也可以是長期性的（針對建置更快、測試執行更快這類持續改善的面向）。對於定義基礎設施即程式碼這類實踐，結對會相當有效。

預期的行為#

賦能團隊的任務，是幫助流動對齊團隊取得所欠缺的能力，通常圍繞某個特定技術或產品管理領域。一個有效的賦能團隊，我們預期看到什麼行為與成果？

• 主動尋求理解流動對齊團隊的需要，建立定期檢查點，並共同商定何時需要更多協作
• 在自身專業領域內走在曲線前面，遠早於流動對齊團隊出現實際需求之前，就掌握新取徑、工具與實踐。過去這曾是架構團隊或創新團隊的任務，但「聚焦於賦能其他團隊」帶來更好的動態
• 既當好消息的信差（例如「有個新的 UI 自動化框架可以把我們的自訂測試碼減少 50%」），也當壞消息的信差（例如「我們大量使用的 Javascript 框架 X 已不再積極維護」）。這有助於技術生命週期的管理
• 偶爾，賦能團隊可以充當代理，去對接那些當前對流動對齊團隊而言太難直接使用的外部（或內部）服務
• 不只在賦能團隊內部、也在各流動對齊團隊之間促進學習，擔任策展者，在組織內促成適切的知識分享（支撐狄馬克與李斯特所稱的「關鍵學習職能」）

賦能團隊的首要目的，是幫助流動對齊團隊以可持續、負責任的方式交付可運作的軟體。

賦能團隊的存在，不是為了修補流動對齊團隊因實踐不良、優先序選擇不良或程式碼品質不良而產生的問題。

流動對齊團隊應當預期只與賦能團隊合作短期（數週或數月），以提升自身在某項新技術、概念或取徑上的能力。當新技能與理解被嵌入流動對齊團隊之後，賦能團隊就會停止與其日常互動，把焦點轉向另一個團隊。

賦能團隊 vs. 實踐社群#

賦能團隊與實踐社群（community of practice, CoP）都能提升其他團隊的意識與能力，但兩者有別：

韋伯（Emily Webber）在《Building Successful Communities of Practice》中說：「實踐社群為社會化學習、經驗式學習與全面的課程創造了適當環境，帶來成員學習的加速。」

兩者目的與動態略有不同，因此可以並存。當然，數個賦能團隊本身也可以有自己的「賦能團隊實踐社群」！

複雜子系統團隊#

複雜子系統團隊負責建造與維護系統中高度依賴專家知識的一部分——依賴到多數團隊成員都必須是該知識領域的專家，才能理解並變更該子系統的程度。

這個團隊的目標，是降低那些包含或使用該複雜子系統之流動對齊團隊的認知負荷。該團隊透過通常難以尋覓或培養的特定能力與專業，來處理子系統的複雜性。我們不能指望把必要的專才嵌入所有使用該子系統的流動對齊團隊——那既不可行、不符成本效益，也不合乎流動對齊團隊的目標。

複雜子系統的例子包括：影片處理編解碼器、數學模型、即時交易對帳演算法、金融服務的交易申報系統，或人臉辨識引擎。

傳統元件團隊（在某子系統被辨識為「正被或預期將被多個系統共用」時成立）與複雜子系統團隊的關鍵差異在於：

複雜子系統團隊只有在某個子系統需要以特化知識為主時才成立。這個決定由團隊認知負荷驅動，而不是由「看起來有共用元件的機會」驅動。

因此，相較於傳統結構中元件團隊的數量，我們預期在團隊拓撲驅動的組織中，複雜子系統團隊只會有寥寥幾個。

預期的行為#

複雜子系統團隊的任務，是把那些需要由一群專家開發的、特別複雜的子系統，從流動對齊團隊身上卸下來。一個有效的複雜子系統團隊，我們預期看到什麼行為與成果？

• 留意子系統當前所處的開發階段並據以行動：在早期探索與開發階段與流動對齊團隊高度協作；子系統穩定後的較晚階段則減少互動，聚焦於子系統介面、功能演化與使用方式
• 該子系統的交付速度與品質，明顯高於「（拆分決定之前）由流動對齊團隊自行開發」時的水準
• 正確地排序並交付即將到來的工作，尊重使用該複雜子系統之流動對齊團隊的需要

平台團隊#

平台團隊的目的，是讓流動對齊團隊能以高度自主的方式交付工作。 流動對齊團隊仍完整保有「在正式環境中建造、運行與修復自家應用」的擁有權；平台團隊則提供內部服務，以降低流動對齊團隊「自行開發這些底層服務」所需的認知負荷。

這個「平台」定義與波徹（Evan Bottcher）對數位平台的定義一致：

數位平台是一組自助式 API、工具、服務、知識與支援所構成的基礎，並被編排成一個引人使用的內部產品。自主的交付團隊可以運用該平台，以更高的步調交付產品功能，同時減少協調成本。

這種取徑已在許多網路時代的組織中成功採用。平台團隊的知識最好透過網頁入口與／或可程式化 API 的自助能力提供出來（而不是冗長的操作手冊），讓流動對齊團隊能輕鬆消費。

「易用性」是平台能否被採用的根本，它反映了一件事：無論消費者是內部或外部顧客，平台團隊都必須把自己提供的服務當作可靠、可用、合乎目的的產品來對待。

艾克斯坦（Jutta Eckstein）有句貼切的建議：「技術服務團隊應當始終把自己視為領域團隊的純粹服務提供者。」

前 Prezi 平台工程師紐馬克（Peter Neumark）強調平台團隊與其所支援之流動對齊團隊之間目的對齊的必要：「平台團隊的價值，可以用它提供給產品團隊之服務的價值來衡量。」

實務上，平台團隊應當聚焦於提供數量較少但品質可接受的服務，而非數量龐大卻有一堆韌性與品質問題的服務。投入的心力與品質之間永遠需要平衡。

就像商業產品一樣，平台可以提供不同的服務等級。如果所有流動對齊團隊都要求「頂級」服務（零停機、自動擴展、故障自我復原），平台團隊很可能就無法應付需求了。

萊納特森建議使用內部訂價（針對基礎設施與服務）來調節需求，避免每個人都來要頂級服務。一個做法是依團隊或服務追蹤雲端基礎設施成本。

平台的邊界範圍相當寬廣：

• 厚平台可能由數個內層平台團隊組合而成，提供林林總總的服務
• 薄平台可能只是疊在廠商解決方案之上的一層

堆疊較低層的平台例子，可以從「佈建一個新伺服器實例」到「提供存取管理與資安落實的工具」。有了這些，流動對齊團隊便可放心採用這些樣式，而不必擔心自己缺乏深入技能或沒有心力去習得。

我們常見的平台，是把堆疊較低層的基礎設施、網路及其他橫切能力抽象掉。這是很好的第一步，但平台也可以指涉更高層次的抽象。

預期的行為#

平台團隊的任務，是提供流動對齊團隊「交付更高層次服務或功能」所需的底層內部服務，從而降低其認知負荷。一個有效的平台團隊，我們預期看到什麼行為與成果？

• 透過與流動對齊團隊的強力協作來理解其需要
• 倚賴快速原型技術，並讓流動對齊團隊成員參與，以快速取得「什麼可行、什麼不可行」的回饋
• 高度聚焦於自家服務的可用性與可靠度（把平台當產品對待），並定期評估這些服務是否仍合乎目的、是否仍好用
• 以身作則：（適用時）自己也使用自己提供的服務、與流動對齊團隊及賦能團隊結盟，並盡可能消費（其他平台團隊擁有的）更低層平台
• 理解內部新服務的採用不是立即的，而是沿著一條採用曲線演進

平台由其他基本團隊的群組構成#

在大型組織中，建造與運行一個平台需要不只一個團隊（某些情況下，各個獨立的流甚至可能各有自己的平台）。此時，平台是由其他基本團隊類型的群組所構成的：流動對齊、賦能、複雜子系統與平台。是的：平台本身也建立在一個平台之上。

不過，平台團隊所對齊的「流」，與那些建造主要（創造營收或面向顧客）產品與服務之團隊的「流」並不相同。在平台內部，流關乎平台之內的服務與產品，例如日誌與監控服務、建立測試環境的 API、查詢資源使用量的設施等。

從平台產品負責人的視角看，平台內部存在清晰的內部價值流，供流動對齊團隊對齊，好讓他們把價值交付給平台的顧客——也就是使用平台的那些團隊。

這實際上在平台之內創造了巢狀或「碎形」的團隊——作者稱之為內層拓撲（inner topologies）。

如沃馬克（James Womack）與瓊斯（Daniel Jones）所說：「監督整個產品的產品線經理，可能會與數位較低層級的價值流經理合作，由後者各自負責價值流的不同環節。」我們只是在平台邊界之內，套用同一套基本團隊拓撲的建議與準則。

從開發團隊的視角看，平台是一個單一實體，透過 API 提供他們單純消費的服務：機器或容器佈建、網路設定等。然而在平台團隊內部，其實有數個不同的團隊（處理網路、環境、度量等），他們自己也與其他平台團隊協作或為其提供服務。

這種「巢狀」取徑，類似資深技術人厄克哈特（James Urquhart）依其在 Sun Microsystems 與 Cisco 的經驗所勾勒的「分層 Ops」取徑：一個團隊提供基礎設施硬體（實體與虛擬），第二個團隊則專注於在基礎設施之上運行支援性服務。

避免變更流動上的團隊穀倉#

一般而言，若我們想快速且安全地交付軟體，就應避免「只由單一職能專長者組成」的團隊。傳統上，許多組織透過把人員按專長歸類，製造出一座座職能專業的孤島或「穀倉」：

• 測試或「品質保證」（QA）
• 資料庫管理（DBA）
• 使用者體驗（UX）
• 架構
• 資料處理（如 ETL）

多年來，許多組織用一個專責的「維運」團隊管理線上／正式系統的所有面向，這在「建造軟體的團隊」與其之間造成明確交接，加上接受變更的延遲，阻擋了變更的流動。

這個模型對安全且快速的變更流動同樣運作不佳。取而代之的做法是：

流動對齊團隊（在正式環境中支援並營運軟體）＋ 平台團隊（為前者提供底層「基質」）。

為安全快速的變更流動而最佳化的組織，傾向使用「與變更流動對齊的混合學科／跨職能團隊」——也就是流動對齊團隊。有時某個領域確實複雜到需要專責的複雜子系統團隊；但這類團隊從不坐落在變更流動之上，而是為流動對齊團隊提供服務。工作永遠不會為了流動中較晚的階段而被交接給另一個團隊。

使用跨職能、流動對齊的團隊有一個非常有用的副作用：正因為流動對齊團隊由具備各種技能的人組成，在任何情境下都存在一股強烈驅力去尋找最簡單、最好用的解法。 那些需要在單一領域具備深厚專業的解法，很可能會輸給「更簡單、更易理解、對流動對齊團隊全體成員都行得通」的解法。

好的平台「剛好夠大」#

一個設計良好、運作良好的平台——使用克尼伯格所稱的「顧客驅動的平台團隊」——可以成為組織內軟體交付的重大「力量倍增器」。但必須小心確保平台始終服務於消費它的應用與服務之需要，而不是反過來。

好的平台提供標準、模板、API 與經過驗證的最佳實踐，供開發團隊快速有效地創新。好的平台應當讓開發團隊「以對組織而言正確的方式，輕易地做正確的事」——這適用於各類產品開發，不只是涉及軟體的那些。

太常見的情況是：平台被丟給過去的系統管理員去建造與運行，卻沒有使用定義良好的軟體開發技術（敏捷實踐、TDD、持續交付、產品管理等）；或者它從組織得到的資助與關注太少，以致從未幫上其他團隊，只有礙事。

最薄可行平台#

最簡單的平台，純粹就是 wiki 頁面上一份「消費端軟體所使用之底層元件或服務」的清單。若那些底層元件與服務始終可靠運作，就沒必要有一支全職的平台團隊。

然而，當底層基質變得更複雜時——即使所有元件與服務仍是外包的——一支平台團隊便能在平台細節之上提供有價值的管理抽象，處理新增與棄用之 API 與元件的協調。若組織需要建造客製解法並整合進平台以滿足開發團隊的需要，平台團隊的活動範圍就會進一步擴大。

在所有情況下，我們都應以「最薄可行平台」（thinnest viable platform, TVP）為目標，避免讓平台主導了整個論述。

如凱利（Allan Kelly）所說：「軟體開發者熱愛建造平台，而在缺乏強力產品管理投入的情況下，他們建出來的平台會比需要的更大。」

TVP 是一種審慎的平衡：既讓平台保持精簡，又確保它確實在加速並簡化那些「建立於其上之團隊」的軟體交付。

降低認知負荷、加速產品開發#

想想過去數十年間那些成功、廣受喜愛的軟體技術平台：IBM 8086 處理器、Linux 與 Windows 作業系統、Borland Delphi、Java 虛擬機、.Net Framework、Pivotal Cloud Foundry、Microsoft Azure，以及（近期的）IoT 平台 balena.io 與容器平台 Kubernetes。

這些平台大體上都成功地降低了底層系統的複雜度，同時仍暴露出足夠的功能，讓建立其上的團隊覺得有用。

這股「簡化開發者的人生」（康威語）與降低認知負荷（見第 3 章）的驅力，是好平台的根本面向。

藉由以「降低開發團隊認知負荷」為目標，好的平台幫助開發團隊聚焦於問題中相關（具差異化）的面向，提升個人與團隊層級的流動，並讓整個團隊更有效能。誠如康泰納仕國際（Condé Nast International）的柴田健一所說：「平台最重要的一點，是它是為開發者而建的。」

引人使用、一致、經審慎挑選的限制#

要避開「建出一個與團隊需要脫節的平台」這個太常見的陷阱，關鍵在於確保平台團隊聚焦於使用者體驗（UX），特別是開發者體驗（DevEx）。這意味著隨著平台規模增長，你應當預期要為平台團隊加入 UX 能力。

柴田說：「開發者有時候會有挫折感……應該要有一條管道，能就平台開發者以及平台整體表現給出回饋。少了這個，平台就會與公司其餘部分隔絕而活。採用充其量也只會困難重重。」

對良好 UX/DevEx 的關注，會讓平台變得引人使用，也讓 API 與功能的運作方式感覺一致。操作指南與其他文件會完備但不冗長、保持更新，並聚焦於完成特定任務，而非把平台的每個犄角旮旯都寫成文件。

平台應當設法「讓開路」給開發團隊，讓他們建造所需之物，而對「團隊該怎麼做那件事」抱持很少的預設。

檢驗 DevEx 的一個好方法：讓一位新開發者上手這個平台有多容易？

建立在底層平台之上#

每個軟體應用、每個軟體服務，都建立在一個平台之上。平台常常是隱含的、隱藏的，或未被建造軟體的團隊多加留意，但它始終在那裡。套一句哲學上的說法：一路都是烏龜（it’s turtles all the way down）。

在軟體脈絡中，這個比喻意味著每個平台本身也建立在另一個平台之上，即使那個底層平台是隱藏或隱含的。

若底層或較低層的平台定義不良或不穩定，上層平台本身也會不穩定，無法提供「加速組織其餘部分軟體交付」所需的穩固地基。

若底層平台有維運上的怪癖或效能問題，平台團隊群組就必須為那些維運問題建造隔離抽象與繞行方案，並／或向開發團隊宣告潛在問題，讓他們容易避開。

這呼應了比爾（Stafford Beer）在經典著作《Brain of the Firm》中描述的多層可行系統模型（viable systems model, VSM）。

為了釐清組織中使用的平台層次，把平台層次畫在一張大圖上。這有助於向內部平台團隊、以及使用該平台的團隊，準確說明平台提供了什麼、又依賴什麼。

當作線上產品或服務來管理#

平台有使用者（開發團隊），也有明確定義的活躍運作時段（只要開發團隊在使用它）。使用者會逐漸依賴平台的可靠度，並需要理解新功能何時出現、舊功能何時退場。因此，為了讓開發團隊使用者盡可能有效能，我們必須：

1. 把平台當作線上／正式系統對待，任何停機都經過規劃與管理
2. 使用軟體產品管理與服務管理技術

當我們把平台當作線上系統對待時，就必須承擔任何其他線上系統該有的一切常規活動與實踐：定義運作時段、定義事故與支援的回應時間、確保有值班輪班表支援平台、以合適的溝通管道（如服務狀態頁）管理事故與非預期停機等等。

隨著平台成長，重新審視「組織內團隊究竟需要什麼、哪些其實可以由外部提供」會很有用，從而降低平台團隊那不斷增長的維運支援負擔。誠如柴田所說：「平台團隊的主要客戶，就是產品團隊。」

那麼，我們如何管理一個有明確使用者與運作時段的線上軟體系統？答案是使用軟體產品管理技術：

• 平台需要一份由產品管理實務工作者策展的路線圖，最好是共同創建，至少也要受使用者（開發團隊）需要的影響
• 平台團隊幾乎必然會為使用者建立使用者輪廓（例如「網頁開發者 Samir」「測試者 Jennifer」「產品負責人 Mani」「服務體驗工程師 Jack」），以幫助團隊同理平台典型使用者的需要、挫折與目標
• 平台團隊成員會定期與顧客（開發團隊及其他）互動，以理解他們的需要

關鍵在於：平台這個「產品」的演化，不是單純由開發團隊的功能請求所驅動，而是被策展並審慎地形塑，以滿足他們更長期的需要。

功能使用狀況會以指標追蹤，並用來形塑關於優先序的對話。平台不是一堆「開發團隊在過去某些時點剛好要過」的功能的集合，而是一個整體性的、精心打造的、一致的東西，它同時考量了整個產業的技術變化方向與組織不斷變化的需要。

好的平台也能減少資安與稽核團隊必須花在開發團隊身上的時間。

把常見團隊類型轉換為基本團隊拓撲#

許多組織會因為「提升團隊定義與目的之清晰度」而受益。事實上，作者認為多數組織若把每個團隊映射到四種基本拓撲之一，成效上會有重大收益——也就是辨識出四種基本拓撲中哪一種最能代表該團隊的良好工作方式，然後修改該團隊的職權範圍，使其採用該拓撲的目的與行為樣式。

轉向以流動對齊團隊為主，以取得長壽與彈性#

在為流動最佳化的組織中，多數團隊應當是長壽、多學科的流動對齊團隊。這些團隊擁有離散的功能切片或特定的使用者成果，並與業務代表及其他交付團隊建立強韌而持久的關係。流動對齊團隊可以期待：透過賦能團隊、平台團隊與複雜子系統團隊的支援與協助，讓認知負荷匹配自身能力。

基礎設施團隊 → 平台團隊#

傳統上，許多基礎設施團隊負責線上／正式基礎設施的所有面向，包括對部署於其上之應用的任何變更。

把基礎設施團隊轉換為平台團隊，能促成快速、安全的變更流動——既在平台之內，也（關鍵地）在流動對齊團隊之內。

從基礎設施團隊到平台團隊的轉變並不簡單或直截了當，因為平台是「以經過驗證的軟體開發技術當作產品來管理」的，而那些技術對基礎設施背景的人可能相當陌生。但如本章其他例子所示，這個取徑確實行得通。

元件團隊 → 平台或其他團隊類型#

既有的、基於某項技術元件而成立的團隊，應當解散（工作併入流動對齊團隊），或轉換成另一種團隊類型：

• 併入平台——若該元件是較低層的「平台」元件
• 轉為賦能團隊——若該元件簡單到流動對齊團隊自己就能處理
• 轉為複雜子系統團隊——若該子系統確實有必要，且確實複雜到流動對齊團隊無法處理

無論何者，該團隊都應採用對應的團隊行為與互動模式。

對於能快速且安全交付軟體的成功組織而言，多數團隊都是流動對齊的，只有大約每七到十個團隊中會有一個不是。

也就是說，依成功組織的回報，流動對齊團隊與其他類型團隊的比例，大約應在 6:1 到 9:1 之間。

具體例子：

• DBA 團隊通常可以轉為賦能團隊——只要他們停止在軟體應用層級做事，改為向流動對齊團隊擴散資料庫效能、監控等方面的意識。也有組織成功把 DBA 團隊轉為平台的一部分，圍繞資料庫效能、組態、可用性等提供特化服務，但DBA 團隊不再負責綱要變更或應用層級的資料庫事務。
• 「中介軟體」團隊同樣可以轉為平台團隊——只要他們讓系統的那些部分對流動對齊團隊更好用，透過客製化、簡化，或把中介軟體包裝成「與組織關鍵目標對齊、易於消費的自助服務」，來降低開發者的認知負荷。

工具團隊 → 賦能團隊或平台的一部分#

若一支工具團隊最初的職權範圍不夠明確、或沒有時間界限，它很容易隨時間變成一支穀倉化的工具維護團隊。

除了對工具鏈的情感依附之外，成員的技術技能也可能過時，心力浪費在「由慣性而非真實需要所主導」的枝微末節改善上。

工具團隊通常更適合以下列兩種方式運行：賦能團隊（職權範圍短命且高度聚焦），或平台的一部分（有清晰、資訊充分的路線圖）。

轉換支援團隊#

傳統上，許多組織用單一的跨服務團隊支援線上／正式環境的應用與服務。當變化速度與系統複雜度都低時，這個模型讓組織得以在支援團隊的人數與技能上最佳化成本。

然而，面對軟體系統快速而持續的變化，成功的組織如今正重新檢視支援團隊的組成與配置，以促成快速且安全的變更流動。一致表現最好的 IT 支援模型有兩個面向：

1. 支援團隊與變更流對齊
2. 以動態的跨團隊活動解決線上服務事故

在這個模型中，若確實需要專責的支援團隊，他們會與變更流對齊，與建造軟體系統的團隊或小隊並肩。聚焦於支援的團隊坐落在「對齊到同一變更流」的團隊家族或部落之中。

在這個脈絡下，提供支援的團隊往往會發展出對「整個服務之使用者體驗」更強的意識，加入端到端的合成交易監控——在那些 IT 與軟體只佔次要地位的情境下尤其如此。

事實上，有些組織把這類團隊改名為「服務體驗團隊」，以反映「端到端使用者體驗涉及的遠不只 IT 系統」這件事。

事故處理流程：當線上正式系統發生事故時，支援團隊首先嘗試僅在流的範圍內解決問題。

• 若問題完全落在流之內，就不需要任何其他團隊介入
• 必要時，引入其他流動對齊的支援團隊協助診斷
• 若事故影響許多團隊，就從各支援團隊組成動態的「蜂擁」或「事故小隊」，由支援專家共同分診並盡快恢復服務

服務管理專家霍爾（Jon Hall）指出這還有額外好處：「讓經驗不足的第一線支援人員加入這些蜂擁，能讓他們接觸到原本得等升遷到更專業團隊之後才會開始取得的知識。」

這兩種支援觀點帶來兩個重要效果：

1. 維持流的獨立性——讓支援團隊與流對齊，會產生一股強烈誘因，去把每個流的系統設計成在執行期彼此獨立。實際上，我們藉此避免了正式環境中的康威定律「單體化」效應，而那正是「單一團隊負責支援所有正式系統」時傾向發生的事。
2. 快速分享新發現的限制與缺陷——使各個流的支援團隊能迅速把學到的東西回饋給建造系統的團隊。

需要透過電話或面對面與使用者直接互動的組織，仍會維持客服中心或服務台；但在概念上，服務台坐落在系統的側邊（遠離變更流動與來自線上系統的資訊流動），讓關於線上運行系統的資訊得以回流到流動對齊團隊。

轉換架構與架構師#

架構團隊最有效的樣式，是作為一支兼職的賦能團隊（如果真的需要的話）。

有些組織會從其他團隊成員中組成一個虛擬團隊，定期開會討論並演化系統的架構面向。這類似 Spotify 使用的分會或公會術語（見第 4 章）。

關鍵在於，對有效的現代軟體開發而言，架構團隊應當支援其他團隊、幫助他們盡可能有效，而不是把設計或技術選擇強加於其他團隊。如《Accelerate》所言：「架構師應當與他們的使用者——那些建造並營運『組織賴以達成使命之系統』的工程師——緊密協作，幫助他們取得更好的成果，並提供能促成這些成果的工具與技術。」

一支兼職、以架構為焦點之賦能團隊的關鍵角色，是發現團隊之間有效的 API，並帶著康威定律的視角去形塑團隊對團隊的互動（第 7 章會更深入探討架構的這個面向）。

本章總結：使用鬆散耦合、模組化的四種特定團隊類型群組#

許多在「快速、可持續的軟體交付」上苦戰的組織，都有一大堆不同類型的團隊，各自背負著（通常定義不良的）不同職責。

要避開這個問題，就把團隊限制在僅僅四種基本類型——流動對齊、賦能、複雜子系統、平台。這讓組織聚焦於那些已知能在個人與組織層級促進流動的團隊互動樣式。

今日開發並營運非平凡軟體系統的組織，必須為「安全且快速的變更流動」最佳化其團隊，且此最佳化必須強烈受到「線上正式系統如何運作（或失效）」的資訊所啟發。這意味著多數團隊必須鬆散耦合、與變更流動（「流」）對齊，並有能力在其所負責的產品、服務或使用者體驗上交付有用的增量。

協助流動對齊團隊達成這種高流動率的，是：

• 賦能團隊——辨識障礙與跨團隊挑戰，並簡化新取徑的採用
• 複雜子系統團隊——必要時，為系統特定部分帶入深厚的專家專業
• 平台團隊——提供底層「基質」，讓流動對齊團隊能以最小摩擦建造與支援軟體產品與服務

這種「對建造與營運軟體系統之團隊類型與職責的標準化」，藉由確保多數團隊都是流動對齊、並由賦能／複雜子系統／平台團隊提供支援性能力與技能，來提升流動。

平台本身則被當作產品或服務來運行：以成熟的軟體產品管理技術排序工作、定期與平台顧客（多為流動對齊團隊）互動、並高度聚焦於 UX 與 DevEx。平台本身也可能由內部的流動對齊團隊、賦能團隊、複雜子系統團隊，甚至更低層的平台團隊所構成——使用的是與「消費該平台之團隊」相同的團隊類型與互動。