架構師如何賦能程式設計師團隊？ - esilva

本文啟發來自 Gregor Hohpe的一篇文章（關於架構策略的參考，有許多關於此主題的著作和書籍）。
在該文中，Gregor 涉及一個非常重要的主題：我們可以採用的拓撲（模型/形式）來處理我們組織團隊中的架構。
這是許多組織處理不當或採取靜態/極端方法的主題，即：

在極端情況下，象牙塔架構師負責指揮和控制團隊內外的所有“重要決策”（格雷戈爾模型中的“仁慈的獨裁者”） ;
或者另一個極端，沒有架構師（“因為我們很敏捷”），因此我們不關心團隊中的架構紀律（Gregor 模型中的“隱式架構”）。

非常重要的是，我們在團隊中處理架構的方式也將隨著團隊和周圍環境的變化而發展。
下面我分享一些關於 Gregor 分享的模型的筆記和見解；接近架構的拓撲結構；進化模式；然後是關於架構範圍的一些見解和註釋。

團隊內架構
Gregor 分享的模型特別強調“團隊範圍架構”，即：如何在團隊擁有的系統中處理架構。所呈現的模型具有四種基本拓撲。可能會有變化和組合，但我認為這四種拓撲提供了一個很好的基礎。

#1：仁慈的獨裁者”

架構師“告訴團隊該做什麼”（與團隊的單向互動）。這是一個相當經典的建築師定義/原型（我什至會說我在談論建築師時從人們那裡聽到的最常見的聯想之一）。正如 Gregor 所說，“應謹慎使用此模型”，並且很可能僅在短時間內對架構成熟度較低的團隊和組織有意義。即使真的需要它，我也會說在儘可能短的時間內保持這種拓撲結構。然後將元素放置到位以移動到#2（以及何時/如果可能的話）#3。當此拓撲用於其他目的時（例如：控制重要決策），

#2：Primus inter pares（架構師 - 作為功能 - 在團隊中）

架構師成為另一個團隊成員 - 同行 - 在團隊中。該模型修復了模型#1 中存在的單向互動模式。這使得架構活動在團隊中更加明確。這意味著團隊將有更多的能力來應對和解決他們在日常活動中面臨的“重要決策”，這應該會帶來更高的敏捷性和適應性（或者正如Michael Nygard 所說的“更高的機動性”) 對他們的環境做出反應。雖然這個模型確保架構在團隊中得到明確的解決，但它仍然定義了只有團隊中的一個人專注於架構（這裡會有灰色區域——因為大多數時候人們都參與架構，但這個模型定義了一個架構師在團隊中發揮作用，這會產生某些動態，例如團隊中有一個架構決策的守門人）。因此，我們可能也不想“永遠”保持這種模式。

#3：沒有架構師的架構（多個/所有團隊成員之一的架構師角色）

沒有人具有架構師的功能，多人（甚至團隊中的每個人）扮演架構師的角色。該模型減輕了模型 #2 可能存在的“中心化瓶頸”。這是一個強大的地方，因為團隊可以擴充套件他們處理架構的方式。我之前講過這個並稱之為“每個人的架構師”，雖然這是一個難以實施的模型，但純粹的努力（並確保每個人都關心“重要決策”）能夠建立強大的團隊最終共享架構所有權。

#4“隱式架構”

（沒有人具有架構師的功能，也沒有架構師的角色）：這是一個危險的領域，因為沒有人在看架構（即使顯然有）。這（以及混合模型 #1 的模型）是一個相當普遍的模型，尤其是在錯誤解釋敏捷原則的團隊和組織中。

進化模式
我真正喜歡這篇文章的另一部分是 Gregor 進入“進化模式”這一事實。承認這一點至關重要，因為我們的架構方法取決於許多不斷變化的因素（團隊成熟度、組織文化、周圍系統等）。這對於確保我們的架構方法不斷髮展以更好地支援團隊及其環境中的新條件至關重要（即：我們的架構方法與組織中正在發生變化的其他動態不衝突）。
Gregor 有兩種常見的模式（但可能還有其他模式）：

右移：當我們從團隊之外的架構師（例如：首席架構師）開始時，例如架構被長期忽視時，就會發生這種情況；但隨後我們採取措施將架構師（職能）整合到團隊中；一旦團隊成熟，多人可以在團隊中扮演架構師的角色。在這種模式中，Gregor 建議停留在模型 #3，即：不要走得太遠，沒有明確地處理團隊中的架構。
Bounce Back：當“Shift to Right”模式不成功時會發生這種情況，即：我們嘗試在團隊中有一個架構師，或者甚至團隊中有多個人扮演架構師的角色，但效果不佳. 在那些時刻，我們可能會“恢復”讓外部經驗豐富的架構師明確為團隊/與團隊一起解決架構問題。這可能又是一個臨時活動，以解決在先前迭代中不起作用的點。這聽起來像是倒退了一步，但在一個複雜的系統中，您不知道系統將如何反應，因此您必須採取行動來學習（正如Cynefin 框架所提倡的那樣）。

還有其他進化模型，如果我們考慮團隊周圍的範圍，這將變得更加明確。觀察這些演化模式不僅很重要，而且在團隊所屬的系統中“連線範圍”也很重要——這是架構的關鍵。在下一節中，我將提供有關此特定主題的一些意見。

架構作用域
檢視團隊範圍周圍的範圍以全面解決團隊範圍並將其連線到周圍的範圍（和系統）是關鍵。
事實上，這是由 Gregor 在其他關於他的“建築師電梯”比喻的文章中廣泛發展的——即：“將頂層公寓與機房連線起來”。也在文章“系統級架構設計存在意義：極簡主義架構 ”中

賦能架構師
將這個特定的團隊定義為“結構賦能團隊”。原因來自這樣一個事實，即一般來說，這是一個賦能團隊（根據書籍定義）存在的時間有限。另一方面，架構團隊往往會無限期地存在。
這種“架構作為賦能團隊”的定位也意味著我們在組織中有一個架構師網路，具有明確的使命（使能團隊），他們可以在領域知識上進行協作，也可以交流做架構的知識，從而培養架構師的技能。在組織中做架構（在架構師之間，以及與他們合作的團隊）。這將意味著我們處理架構的方式也將不斷髮展（例如：新人加入，新挑戰出現等）並且我們明確關注迎合架構（即使在特定時刻我們有不那麼明確的架構師職能） - 例如：如果這只是文化的一部分，我們需要正式的架構師在場）。

例如，一個人可能具有架構師職能，在多個相關團隊中工作，這些團隊共同構建產品或為客戶的共同價值流做出貢獻（例如：公司產品組合中的產品）。下圖描繪了這個想法（注意：這是一個簡化的表示，旨在展示架構師在此拓撲中的可能定位方式）。

架構師如何賦能程式設計師團隊？ - esilva
正如我們在圖中看到的，這個人（在這種情況下我稱她為“產品架構師”）在“產品範圍”（圍繞團隊範圍的系統）工作。她將與團隊（以及領域以下範圍）在產品範圍的架構上保持一致。此外，她還可以在指導和支援每個團隊在團隊範圍內（存在不同的應用程式）處理架構方面發揮作用。因此，這成為 Gregor 共享的拓撲 #1 版本的一種升級（具有雙向互動），但同時團隊（應該）負責團隊自己範圍架構（即：使用拓撲#3，或在某些情況下#2）。這種組合可以接近解決架構所需的不同範圍。

架構師如何賦能程式設計師團隊？ - esilva

相關文章