給敏捷團隊中的架構師的10個建議
阿新 • • 發佈：2018-12-24
微軟澳大利亞的解決方案架構師Tom Hollander，在TechEd Australia大會上舉行了一場題為“敏捷團隊中的架構師角色”的演講。在演講中，他討論了他作為領導敏捷團隊的架構師所做的工作。
在談到架構師的角色時，Hollander指的是“解決方案架構師”或者應用架構師。他不是指企業架構師或者其他的專業人士（專精於特定的領域，例如訊息或基礎設施）。
Hollander的團隊採納了由4周迭代以及最後的穩定階段（幾天程式碼凍結的時間）組成的流程，實施了每日站立會議、每日構建與自動化測試的持續整合等實踐，並採用了許多角色：
- PjM——專案經理，類似於Scrum Master，確保團隊遵循了流程
- PdM——產品經理，也被稱為客戶或Product Owner，決定產品應該是什麼樣子
- 架構師——解決方案/應用架構師
- 開發人員——開發團隊
- 測試人員——測試團隊
- 使用者體驗設計人員（UX）——使用者體驗團隊
- 釋出人員——承擔構建和釋出的職責，負責維護構建的流程
Hollander針對解決方案架構師如何在敏捷團隊中取得成功，提出了最重要的十件事情：
- “正好足夠”的預先設計——除了非常簡單的專案，一定時間的預先設計（例如，1到2周）是絕對必要的，其時間長短會取決於應用的型別——網路應用程式、智慧客戶端（smart client）、移動或批處理，基本的功能需求是什麼，是長期的解決方案抑或是折衷的、暫時的方案，都要弄清楚。預先設計的目的是要決定：使用什麼技術——例如，ASP.NET或MVC，應用程式是什麼型別——2層、3層抑或是面向服務的應用，如何訪問資料庫——儲存過程、實體框架、LINQ、依賴注入（DI）。一篇簡短的文件就可以包含所有這些資訊以供大家參考。
- 從垂直分片開始——是指從一小塊功能開始（例如登入頁面），儘可能地在垂直方向把它切分為很多層，從而把前一階段所決定的所有技術結合在一起。這將驗證設計決策的正確性，而且所有的技術可以一起工作，並且將向開發者展示在開發新程式碼時可以遵循的模式。如果發現最初的設計決策不當，此時是一個合適的修改時間。
- 在每次迭代中的Just-in-time設計——在每個4周迭代的中段，專案經理、產品經理和架構師應該聚在一起討論在下一個迭代中要完成的需求，確保他們每一位都同意這些需求，重要性更高的事情放在了前面處理，而且每個人對一切事情都非常清楚。這些討論在當前迭代中會以不太明顯的方式延續一個星期。接下來的一週，也即當前迭代的最後一週，架構師複審下一次迭代的需求，作出必要的設計決策，以便團隊可以在下一個星期基於這些決策開展工作。如果需求與以往相當不同，那麼，架構師會開發一些原型，編寫一些程式碼來證明概念，繪製一些圖表，然後把所有這些東西集編為5頁的檔案以供參考。這不是為了制定出有利於開發人員的詳細設計方案，而是要確保新的需求滿足全域性的要求。
- 信任你的團隊...但要跟他們在一起——這關乎架構師與開發人員的關係。架構師需要確保他沒有逾越自己的角色，沒有獨佔所有“做決定”的樂趣，使得開發人員的工作變得無聊。與此同時，架構師需要給團隊提供指導，解決那些可能會導致開發人員停頓的困難問題。架構師每天都應該與每位開發人員接觸，獲悉他們在做什麼，並且在他們遇上程式設計問題的時候給予幫助。特別是當開發人員不喜歡尋求幫助，試圖花上整整一個禮拜的時間來自行解決問題的時候，這種幫助尤為需要。這種關係也適用於PjM和測試/構建/釋出團隊。
- 編寫程式碼！——架構師應該知道程式碼的質量如何，這樣才會對他做出的決定所產生的影響有更好的理解。他也可以整明白何時重構是必須的。編寫程式碼的架構師在開發團隊中有更好的聲譽。也就是說，Hollander並不認同（設計和開發）職責的涇渭分明。他還認為，架構師仍然是架構師，他不一定要像普通的開發人員一樣擅長於編寫程式碼。
- 參與一切——架構師參與所有與專案有關的會議：設計、開發、程式碼評審、需求規劃等，這是有好處的，因為他能夠以更廣闊、更清晰的視角看待正在發生的事情，而且他能夠通過告知產品經理其決定的潛在後果，從而幫助他/她避免在早期階段做出錯誤的決定。
- 推動質量文化——一個成功的團隊，一個人人都想成為其中一分子的團隊，是建立在質量文化之上的：沒有人偷工減料；沒有人提交拙劣程式碼；如果設計中有一個重大的缺陷，它絕不會不知不覺地混過關；所有人都是誠實和開放的，尋求整個團隊達到最佳的結果。Hollander承認，建立這樣一個團隊很難，但並非不可能。首先，架構師應該在一開始就建立一些規則，這些規則不會因為開發人員不喜歡就隨著時間而改變。比如決定編寫單元測試，再比如在每次提交以前都要進行程式碼評審，包括由架構師提交的程式碼。如果評審人員（可以是團隊中的任意一位）不認可程式碼，程式碼就不能提交。
- 知道何時需要改變——架構師應該非常靈活，隨時準備好在設計需要改變的時候去改變設計。早期的解決方案也許不再適合，抑或是新的需求需要不同的方法。
- 遮蔽來自外部的隨機請求——雖然這通常是專案經理/Scrum master的職責，但架構師可以保護團隊不受外部請求的影響，這些影響往往會分散團隊的精力和浪費真正工作的時間。舉個例子：業務團隊可能想要以某種特定的方式完成某些特定的事情，而他們的請求並不全然合理，也並不是必須實現。
- 撰寫文件...但只有當有人需要閱讀它們的時候——Hollander並不提倡記錄一切，也不提倡根本不撰寫任何文件。他認為有必要取得一個平衡——只編寫一定數目真正有幫助的、有人會去閱讀的文件。文件在記錄詳細設計的決定（比如資料模型）方面是很好的載體。迭代的設計決定，雖然它們由整個團隊在迭代開始之初討論得出，但我們仍然建議將它們記錄在5頁的文件之中，以備開發人員日後不記得架構師言論的時候進行查閱。而當最開始的開發人員和架構師離開專案、加入其他專案之後，新加入專案工作的人也能借助於這些文件理解某些決定的來龍去脈。
綜上所述，Hollander指出，架構師應該確保他從理論上和實踐上都是團隊的一分子。架構師不應該編寫所有的程式碼，而只是其中一小部分，他不去測試或部署這些程式碼，但他要確保整個流程的順利進行。