團隊拓撲

2023 年 7 月 25 日

任何大型軟體專案,例如大型公司的軟體資產,都需要許多人手,而每當你擁有人力時,你都必須找出如何將他們分組成有效率的團隊。組成以業務能力為中心的團隊有助於軟體專案回應客戶需求,但所需的技能範圍常常讓這些團隊不堪負荷。團隊拓撲是馬修·史凱爾頓和曼紐爾·派斯所開發的軟體開發團隊組織模型。它定義了四種形式的團隊和三種團隊互動模式。此模型鼓勵健康的互動,讓以業務能力為中心的團隊在提供穩定且有價值的軟體任務中蓬勃發展。

此架構中的主要團隊類型是串流對齊團隊,一個以業務能力為中心的團隊,負責單一業務能力的軟體。這些是長期運作的團隊,將其努力視為提供軟體產品以增強業務能力。

每個串流對齊團隊都是全堆疊且全生命週期的:負責前端、後端、資料庫、業務分析、功能優先順序、UX、測試、部署、監控,也就是軟體開發的全部。它們是以成果為導向的,專注於業務成果,而不是以活動為導向的團隊,專注於業務分析、測試或資料庫等功能。但它們也不應過大,理想情況下,每個團隊都是雙披薩團隊。大型組織將有許多這樣的團隊,儘管它們有不同的業務能力要支援,但它們有共同的需求,例如資料儲存、網路通訊和可觀察性。

像這樣的小團隊需要方法來減少他們的認知負擔,以便他們專注於支援業務需求,而不是(例如)資料儲存問題。這樣做的一個重要部分是建立一個處理這些非焦點問題的平台。對於許多團隊來說,平台可以是一個廣泛使用的第三方平台,例如用於資料庫後端 Web 應用程式的 Ruby on Rails。但是對於許多產品來說,沒有單一的現成平台可以使用,團隊必須找到並整合多個平台。在較大的組織中,他們必須存取一系列內部服務並遵循公司標準。

這個問題可以透過為組織建立一個內部平台來解決。這樣的平台可以整合第三方服務、近乎完整的平台和內部服務。團隊拓撲將建立這個(缺乏想像力但很明智地)平台的團隊分類為平台團隊

較小的組織可以與單一平台團隊合作,該團隊會在外部提供的產品集上產生一層薄層。然而,較大的平台需要的人員比兩個披薩所能餵飽的人還要多。因此,作者轉而描述由許多平台團隊組成的平台群組

平台的一個重要特徵是它被設計為以大多數自助服務的方式使用。與串流對齊的團隊仍然負責其產品的運作,並直接使用平台,而不會期待與平台團隊進行精細的協作。在團隊拓撲架構中,這種互動模式稱為X 即服務模式,其中平台充當與串流對齊的團隊的服務。

然而,平台團隊需要將他們的服務本身建構為產品,並深入瞭解客戶的需求。這通常需要他們使用不同的互動模式,也就是協作模式,同時建立該服務。協作模式是一種更密集的互動夥伴關係形式,並且應該被視為一種暫時的方法,直到平台成熟到足以轉移到 X 即服務模式為止。

到目前為止,該模型並沒有代表任何特別具有創意的東西。將組織分解為業務對齊和技術支援團隊是一種與企業軟體一樣古老的方法。近年來,許多作家表達了讓這些業務能力團隊負責全堆疊和全生命週期的重要性。對我來說,團隊拓撲的亮點見解是專注於擁有全堆疊和全生命週期的業務對齊團隊所帶來的問題,這表示他們經常面臨過度的認知負擔,這與小型、靈敏團隊的願景背道而馳。平台的主要好處是它減少了這種認知負擔

團隊拓撲中一個關鍵的見解是,平台的主要好處是減少與串流對齊團隊的認知負擔

這個見解有深遠的影響。首先,它改變了平台團隊應該如何思考平台的方式。減少客戶團隊的認知負擔會導致不同的設計決策和產品路線圖,這些平台主要用於標準化或降低成本。除了平台之外,這個見解引領團隊拓撲通過識別另外兩種團隊類型來進一步發展他們的模型。

有些能力需要專家,他們可以投入大量時間和精力來掌握對許多與串流對齊的團隊很重要的主題。安全專家可能會花更多時間研究安全問題並與更廣泛的安全社群互動,這對於串流對齊團隊的成員來說是不可能的。這樣的人聚集在支援團隊中,他們的角色是在其他團隊內培養相關技能,以便這些團隊可以保持獨立並更好地擁有和發展他們的服務。為了實現這一點,支援團隊主要使用團隊拓撲中的第三個也是最後一個互動模式。促進模式涉及指導角色,在這種角色中,支援團隊不在那裡撰寫和確保符合標準,而是教育和指導他們的同事,以便與串流對齊的團隊變得更加自主。

與串流對齊的團隊負責為其客戶提供完整的價值串流,但偶爾我們會發現與串流對齊團隊工作中某些方面要求非常高,需要一個專門的群組專注於此,這導致了第四個也是最後一個團隊類型:複雜子系統團隊。複雜子系統團隊的目標是減少使用該複雜子系統的與串流對齊團隊的認知負擔。即使該子系統只有一個客戶團隊,這也是一個有價值的部門。大多數複雜子系統團隊努力使用 X 即服務模式與其客戶互動,但需要在短時間內使用協作模式。

團隊拓撲包括一組圖形符號,用於說明團隊及其關係。這裡顯示的這些符號來自當前標準,與書中使用的標準不同。一篇最近的文章詳細說明瞭如何使用這些圖表。

團隊拓撲的設計明確承認了康威定律的影響。它鼓勵的團隊組織考慮了人類和軟體組織之間的相互作用。團隊拓撲的倡導者希望其團隊結構能將軟體架構的未來發展塑造成響應式和解耦的組件,並與業務需求保持一致。

喬治·博克斯巧妙地說:「所有模型都是錯誤的,有些是有用的。」因此,團隊拓撲是錯誤的:複雜的組織不能簡單地分解為僅四種類型的團隊和三種類型的互動。但像這樣的約束正是使模型有用的原因。團隊拓撲是一個工具,它促使人們將他們的組織發展成更有效率的運作方式,這種方式允許與串流對齊的團隊通過減輕他們的認知負擔來最大化他們的流程。

致謝

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 親切地提供了這篇文章的詳細評論,包括分享他們自寫書以來的部分最新想法。

延伸閱讀

對於團隊拓撲架構的最佳說明是同名書籍,於 2019 年出版。作者也維護團隊拓撲網站,並提供教育和培訓服務。他們最近關於團隊互動建模的文章是關於如何使用團隊拓撲(元)模型來建立和演進組織模型的良好介紹。[1]

團隊拓撲的很大一部分是基於認知負載的概念。作者在 Tech Beacon 中探討了認知負載。Jo Pearce 進一步說明了認知負載如何應用於軟體開發

團隊拓撲中的模型與我在本網站上發表的許多關於軟體團隊組織的想法產生了共鳴。您可以在團隊組織標籤中找到這些想法。

備註

1: 為了在建模語言中更嚴謹,我會說團隊拓撲通常作為元模型。如果我使用團隊拓撲來建立一家航空公司的軟體開發組織模型,那麼該模型會顯示根據團隊拓撲術語分類的航空公司中的團隊。然後我會說團隊拓撲模型是我的航空公司模型的元模型。