翻譯自 Martin Fowler 大師的 TeamTopologies 。

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

該框架中的主要團(tuán)隊(duì)類型是流程對(duì)齊團(tuán)隊(duì)（stream-aligned team），這是一個(gè)以業(yè)務(wù)能力為中心的團(tuán)隊(duì)，負(fù)責(zé)一個(gè)業(yè)務(wù)能力的軟件。這些團(tuán)隊(duì)運(yùn)行時(shí)間較長，將自己的努力視為提供增強(qiáng)業(yè)務(wù)能力的軟件產(chǎn)品。

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

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

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

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

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

然而，平臺(tái)團(tuán)隊(duì)需要將它們的服務(wù)構(gòu)建為產(chǎn)品本身，并深入了解客戶的需求。這通常需要使用另一種交互模式，即協(xié)作模式，在構(gòu)建該服務(wù)時(shí)進(jìn)行更密切的合作。協(xié)作模式是一種更為密集的合作方式，并應(yīng)被視為一種臨時(shí)方法，直到平臺(tái)足夠成熟，可以轉(zhuǎn)入?X-as-a-Service?模式。

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

《Team Topologies》的一個(gè)關(guān)鍵洞察是平臺(tái)的主要好處，也就是減輕流程對(duì)齊團(tuán)隊(duì)的認(rèn)知負(fù)擔(dān)。

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

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

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

《Team Topologies》包括一組圖形符號(hào)來說明團(tuán)隊(duì)及其關(guān)系。這里展示的圖形符號(hào)與書中使用的圖形符號(hào)有所不同。最近的一篇文章詳細(xì)介紹了如何使用這些圖表。

《Team Topologies》明確地承認(rèn)了康威定律的影響。它鼓勵(lì)的團(tuán)隊(duì)組織方式考慮到人與軟件組織之間的相互作用?！禩eam Topologies》的支持者希望其團(tuán)隊(duì)結(jié)構(gòu)能夠塑造軟件架構(gòu)未來的發(fā)展方向，使其能夠與業(yè)務(wù)需求相適應(yīng)，具有響應(yīng)性并且解耦。

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

致謝

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 在我們的內(nèi)部郵件列表上討論了這篇文章的初稿，并提供了寶貴的反饋意見。

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

進(jìn)一步閱讀

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

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

《Team Topologies》中的模型與我在本網(wǎng)站上發(fā)表的關(guān)于軟件團(tuán)隊(duì)組織的思考相契合。你可以在“ team organization ”標(biāo)簽下找到這些內(nèi)容。

注釋

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

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