什麼是DevOps團隊拓撲？ - atlassian

banq發表於2021-11-11
dev

工程團隊需要比以往任何時候都更快地為客戶提供價值。雲、SaaS 和永遠線上服務的興起意味著客戶期望新功能、更少的錯誤和 99.99%（或更高）的正常執行時間。 
為了跟上這些需求，組織採用了敏捷實踐和最近的 DevOps 實踐，這有望加快上市時間/交付週期、改進部署頻率、更好的團隊文化，並加強跨團隊/部門的協作。 
雖然採用 DevOps 實踐說起來容易做起來難，但《團隊拓撲》一書提供了組織可以將 DevOps 構建到他們公司中的有見地的方法，包括什麼樣的團隊可能最有效。本書為 Atlassian 如何看待團隊提供了一個起點。我們不想重申他們的發現，而是想分享我們自己對團隊型別的看法。
DevOps 轉型的第一步是確定適當的組織結構。然而，在當今任何一家公司，都有許多不同的團隊型別，在某些情況下，單個團隊承擔多個角色和職責。這種蔓延使領導者難以想象整個組織的格局，並回答以下問題：
  • 我們有合適的團隊嗎？
  • 我們是否缺乏任何團隊都沒有解決的某些領域的能力？
  • 團隊在自治和其他團隊的支援之間是否有必要的平衡？

開發和運營領導者可以透過團隊拓撲的視角觀察他們的組織，從而更好地瞭解是否有合適的團隊。我們建議將團隊變體的數量減少到四種基本的團隊拓撲結構，這些拓撲結構對於高層管理人員和實際團隊成員本身都很容易理解：
  • 流對齊的團隊
  • 平臺團隊
  • 複雜子系統團隊
  • 賦能團隊

請記住，這些團隊型別根據公司的規模和成熟度採用不同的形式。實際上，將不止一種型別的團隊組合在一起，或者將一個團隊轉變為另一種型別，通常是最好的方法。
 

流對齊的團隊
流對齊的團隊專注於單一的、有影響力的工作流。它可以是單個產品或服務、一組功能、單個使用者旅程或單個使用者角色。該團隊有權儘可能快速、安全和獨立地構建和交付客戶或使用者價值，而無需將工作交給其他團隊來執行部分工作。
因為流對齊的團隊致力於全方位的交付，所以他們必然更接近客戶並且通常已經很敏捷。該團隊將客戶反饋納入開發週期，同時在生產中維護軟體。 
雖然流對齊的團隊在許多軟體公司中很常見，但其他組織可能更熟悉按功能組織的團隊結構（即獨立的工程、設計、QA 團隊），而不是交付流。 
由於流對齊團隊是組織中最常見的團隊型別，因此其他團隊的角色是相對於流對齊團隊定義的。流對齊團隊應定期聯絡以下支援團隊（複雜的子系統、支援和平臺），以不斷提高其產品和服務的交付速度和質量。
 

平臺團隊
平臺團隊使流對齊的團隊能夠以極大的自主權交付工作。雖然流對齊團隊擁有在生產中構建、執行和修復應用程式的全部所有權，但平臺團隊提供流對齊團隊可以使用的內部服務。
平臺團隊建立的功能可供眾多流對齊的團隊使用，而且開銷很小。透過最佳化產品，平臺團隊最大限度地減少了流對齊團隊的資源和認知負載。這也有利於終端使用者，因為平臺團隊可以建立跨越不同使用者體驗或產品的有凝聚力的體驗。
在 Atlassian，平臺團隊構建我們所有產品（如身份管理）使用的服務，並有望為流對齊團隊提供文件、支援和諮詢。
 

複雜子系統團隊
一個複雜的子系統團隊負責構建和維護依賴於特定技能和知識的系統部分。大多數團隊成員必須是特定知識領域的專家才能理解子系統並對其進行更改。
該團隊的目標是減少在包含或使用子系統的系統上工作的流對齊團隊的負載。憑藉複雜子系統團隊的專業知識和能力，流對齊團隊不必在日常工作中過於複雜的領域構建能力。該團隊的團隊成員可能具有某些微服務（即計費服務）、演算法甚至人工智慧方面的專業知識。 
一個常見的陷阱是在每個使用子系統的流對齊團隊中嵌入專家。雖然這看起來很有效，但它最終不符合成本效益，並且超出了流對齊團隊的範圍。 
 

賦能團隊
流對齊的團隊一直承受著快速交付和響應變化的壓力，這使得尋找時間研究、學習和練習新技能變得具有挑戰性。
由特定技術（或產品）領域的專家組成的支援團隊有助於彌合這種能力差距。這些團隊專注於研究和實驗，以就影響工具堆疊的工具、框架和生態系統選擇提出明智的建議。
這讓流對齊的團隊有時間獲取和發展能力，而不會從他們的主要目標上花時間。賦能團隊主要透過關注問題而不是解決方案來提高他們的能力，從而主要增加流對齊團隊的自主權。
如果一個支援團隊的工作做得很好，它所協助的團隊在幾周左右後就不再需要幫助了。支援團隊永遠不應該處理永久依賴項。
 
注：當心團隊拓撲變為 SAFe
 

相關文章