翻譯自 Martin Fowler 大師的 TeamTopologies 。

任何大型軟件項目，比如為大公司開發(fā)的軟件體系，都需要很多人的參與。而一旦有很多人，就需要考慮如何將他們分成有效的團隊。形成以業(yè)務能力為中心的團隊有助于軟件項目對客戶需求作出響應，但所需技能的范圍常常使得這樣的團隊難以應付。Team Topologies 是由 Matthew Skelton 和 Manuel Pais 開發(fā)的描述軟件開發(fā)團隊組織的模型。它定義了四種團隊形式和三種團隊交互模式。該模型鼓勵健康的交互方式，使以業(yè)務能力為中心的團隊在提供有價值的軟件時能夠蓬勃發(fā)展。

該框架中的主要團隊類型是流程對齊團隊（stream-aligned team），這是一個以業(yè)務能力為中心的團隊，負責一個業(yè)務能力的軟件。這些團隊運行時間較長，將自己的努力視為提供增強業(yè)務能力的軟件產品。

每個流程對齊團隊都是全棧和全生命周期團隊：負責前端、后端、數據庫、業(yè)務分析、功能優(yōu)先級、用戶體驗、測試、部署、監(jiān)控——整個軟件開發(fā)過程的全部方面。他們以結果為導向，專注于業(yè)務成果，而不是以活動為導向，專注于特定功能，比如業(yè)務分析、測試或數據庫。但是團隊也不應該太大，理想情況下，每個團隊應該是一個“兩個披薩”的團隊。一個大型組織將擁有許多這樣的團隊，雖然它們需要支持不同的業(yè)務能力，但它們有共同的需求，比如數據存儲、網絡通信和可觀測性。

像這樣的小團隊需要找到方法來減少認知負擔，以便他們可以專注于支持業(yè)務需求，而不是（例如）數據存儲問題。實現這一目標的一個重要部分是建立在一個能夠處理這些非核心問題的平臺上。對于許多團隊來說，這個平臺可以是一個廣泛可用的第三方平臺，比如用于數據庫支持的 Ruby on Rails 。但是對于許多產品來說，并沒有單一的現成平臺可供使用，一個團隊將不得不找到并整合幾個平臺。在一個較大的組織中，他們將不得不訪問一系列內部服務并遵循企業(yè)標準。

這個問題可以通過為組織構建一個內部平臺來解決。這樣的平臺可以整合第三方服務、幾乎完整的平臺以及內部服務?！禩eam Topologies》將構建這樣一個平臺的團隊（很不富有創(chuàng)意但很明智）劃分為平臺團隊。

較小的組織可以與一個單一的平臺團隊合作，該團隊為外部提供的產品集提供了一個薄薄的層。然而，較大的平臺需要比“兩個披薩”團隊更多的人。因此，作者們開始描述由許多平臺團隊組成的平臺組合。

平臺的一個重要特點是它被設計成在大多數情況下以自助方式使用。流程對齊團隊仍然負責其產品的運營，并在使用平臺時直接與平臺團隊進行簡單的協(xié)作，而不期望進行復雜的合作。在《Team Topologies》框架中，這種交互模式被稱為?X-as-a-Service?模式，其中平臺作為流程對齊團隊的服務。

然而，平臺團隊需要將它們的服務構建為產品本身，并深入了解客戶的需求。這通常需要使用另一種交互模式，即協(xié)作模式，在構建該服務時進行更密切的合作。協(xié)作模式是一種更為密集的合作方式，并應被視為一種臨時方法，直到平臺足夠成熟，可以轉入?X-as-a-Service?模式。

到目前為止，這個模型沒有表現出特別創(chuàng)新的東西。將組織分解為業(yè)務對齊團隊和技術支持團隊的做法早已是企業(yè)軟件的老生常談。近年來，很多作者都強調了讓這些業(yè)務能力團隊負責全棧和全生命周期的重要性。對我來說，《Team Topologies》的亮點是專注于問題，即讓業(yè)務對齊團隊在全棧和全生命周期的情況下，往往面臨過多的認知負擔，這與構建小而敏捷的團隊的愿望相沖突。平臺的關鍵好處在于它減少了這種認知負擔。

《Team Topologies》的一個關鍵洞察是平臺的主要好處，也就是減輕流程對齊團隊的認知負擔。

這一洞察具有深遠的影響。首先，它改變了平臺團隊對平臺的看法。減輕客戶團隊的認知負擔導致不同的設計決策和產品路線圖，與主要用于標準化或降低成本的平臺截然不同。除此之外，這一洞察還使《Team Topologies》進一步發(fā)展，通過確定另外兩種團隊類型。

有些能力需要專家，他們可以花費大量時間和精力來掌握對許多流程對齊團隊都很重要的主題。與作為流程對齊團隊成員時可能的情況相比，安全專家可能會花更多的時間研究安全問題并與更廣泛的安全社區(qū)進行交流。這些專家聚集在“使能團隊”中，他們的角色是在其他團隊內部培養(yǎng)相關技能，以便這些團隊保持獨立，更好地擁有和發(fā)展自己的服務。為了實現這一目標，使能團隊主要使用《Team Topologies》中的第三種交互模式。促進模式涉及一種輔導角色，使能團隊的目標不是編寫和確保符合標準，而是教育和輔導同事，使流程對齊團隊變得更加自治。

流程對齊團隊負責為其客戶提供的所有價值流，但有時我們會發(fā)現流程對齊團隊的某些工作非常復雜，需要一個專門的團隊來專注處理，從而形成第四種類型的團隊：復雜子系統(tǒng)團隊。復雜子系統(tǒng)團隊的目標是減輕使用該復雜子系統(tǒng)的流程對齊團隊的認知負擔。即使只有一個客戶團隊使用該子系統(tǒng)，這也是一種值得的分工。通常，復雜子系統(tǒng)團隊努力以 X-as-a-Service 模式與其客戶進行交互，但在短期內可能需要使用協(xié)作模式。

《Team Topologies》包括一組圖形符號來說明團隊及其關系。這里展示的圖形符號與書中使用的圖形符號有所不同。最近的一篇文章詳細介紹了如何使用這些圖表。

《Team Topologies》明確地承認了康威定律的影響。它鼓勵的團隊組織方式考慮到人與軟件組織之間的相互作用。《Team Topologies》的支持者希望其團隊結構能夠塑造軟件架構未來的發(fā)展方向，使其能夠與業(yè)務需求相適應，具有響應性并且解耦。

George Box 曾經巧妙地說過：“所有的模型都是錯誤的，但有些是有用的?！币虼?，《Team Topologies》是錯誤的：復雜的組織結構不能簡單地歸結為只有四種團隊和三種交互方式。但是，正是這些限制使得模型變得有用?！禩eam Topologies》是一種工具，它推動人們將自己的組織發(fā)展成為一種更有效的運營方式，使流程對齊團隊通過減輕認知負擔來最大化其流程。

致謝

Andrew Thal, Andy Birds, Chris Ford, Deepak Paramasivam, Heiko Gerin, Kief Morris, Matteo Vaccari, Matthew Foster, Pavlo Kerestey, Peter Gillard-Moss, Prashanth Ramakrishnan 和 Sandeep Jagtap 在我們的內部郵件列表上討論了這篇文章的初稿，并提供了寶貴的反饋意見。

Matthew Skelton 和 Manuel Pais 友善地對本文提供了詳細的評論，包括分享自書籍出版以來的一些最新思考。

進一步閱讀

關于《Team Topologies》框架的最佳介紹是同名書籍，該書于 2019 年出版。作者們還維護著《Team Topologies》網站，并提供教育和培訓服務。他們最近發(fā)表的關于團隊交互建模的文章是一個很好的入門，介紹了《Team Topologies》元模型如何用于構建和演化組織的模型。[1]

《Team Topologies》的許多內容都基于認知負荷的概念。作者們在 Tech Beacon 上探討了認知負荷。Jo Pearce 則進一步闡述了認知負荷在軟件開發(fā)中的應用。

《Team Topologies》中的模型與我在本網站上發(fā)表的關于軟件團隊組織的思考相契合。你可以在“ team organization ”標簽下找到這些內容。

注釋

1：為了在建模術語上更為嚴謹，我會說《Team Topologies》通常作為一個元模型。如果我使用《Team Topologies》來構建一個航空公司軟件開發(fā)組織的模型，那么該模型將根據《Team Topologies》的術語對航空公司的團隊進行分類。然后我會說，《Team Topologies》模型是我對航空公司模型的一個元模型。

本文使用 文章同步助手 同步