瘋狂

微軟澳大利亞的解決方案架構(gòu)師Tom Hollander，在TechEd Australia大會上舉行了一場題為“敏捷團隊中的架構(gòu)師角色”的演講。在演講中，他討論了他作為領(lǐng)導敏捷團隊的架構(gòu)師所做的工作。

在談到架構(gòu)師的角色時，Hollander指的是“解決方案架構(gòu)師”或者應用架構(gòu)師。他不是指企業(yè)架構(gòu)師或者其他的專業(yè)人士（專精于特定的領(lǐng)域，例如消息或基礎(chǔ)設(shè)施）。

Hollander的團隊采納了由4周迭代以及最后的穩(wěn)定階段（幾天代碼凍結(jié)的時間）組成的流程，實施了每日站立會議、每日構(gòu)建與自動化測試的持續(xù)集成等實踐，并采用了許多角色：

• PjM——項目經(jīng)理，類似于Scrum Master，確保團隊遵循了流程
• PdM——產(chǎn)品經(jīng)理，也被稱為客戶或Product Owner，決定產(chǎn)品應該是什么樣子
• 架構(gòu)師——解決方案/應用架構(gòu)師
• 開發(fā)人員——開發(fā)團隊
• 測試人員——測試團隊
• 用戶體驗設(shè)計人員（UX）——用戶體驗團隊
• 發(fā)布人員——承擔構(gòu)建和發(fā)布的職責，負責維護構(gòu)建的流程

Hollander針對解決方案架構(gòu)師如何在敏捷團隊中取得成功，提出了最重要的十件事情：

1. “正好足夠”的預先設(shè)計——除了非常簡單的項目，一定時間的預先設(shè)計（例如，1到2周）是絕對必要的，其時間長短會取決于應用的類型——網(wǎng)絡(luò)應用程序、智能客戶端（smart client）、移動或批處理，基本的功能需求是什么，是長期的解決方案抑或是折衷的、暫時的方案，都要弄清楚。預先設(shè)計的目的是要決定：使用什么技術(shù)——例如，ASP.NET或MVC，應用程序是什么類型——2層、3層抑或是面向服務(wù)的應用，如何訪問數(shù)據(jù)庫——存儲過程、實體框架、LINQ、依賴注入（DI）。一篇簡短的文檔就可以包含所有這些信息以供大家參考。
2. 從垂直分片開始——是指從一小塊功能開始（例如登錄頁面），盡可能地在垂直方向把它切分為很多層，從而把前一階段所決定的所有技術(shù)結(jié)合在一起。這將驗證設(shè)計決策的正確性，而且所有的技術(shù)可以一起工作，并且將向開發(fā)者展示在開發(fā)新代碼時可以遵循的模式。如果發(fā)現(xiàn)最初的設(shè)計決策不當，此時是一個合適的修改時間。
3. 在每次迭代中的Just-in-time設(shè)計——在每個4周迭代的中段，項目經(jīng)理、產(chǎn)品經(jīng)理和架構(gòu)師應該聚在一起討論在下一個迭代中要完成的需求，確保他們每一位都同意這些需求，重要性更高的事情放在了前面處理，而且每個人對一切事情都非常清楚。這些討論在當前迭代中會以不太明顯的方式延續(xù)一個星期。接下來的一周，也即當前迭代的最后一周，架構(gòu)師復審下一次迭代的需求，作出必要的設(shè)計決策，以便團隊可以在下一個星期基于這些決策開展工作。如果需求與以往相當不同，那么，架構(gòu)師會開發(fā)一些原型，編寫一些代碼來證明概念，繪制一些圖表，然后把所有這些東西集編為5頁的文件以供參考。這不是為了制定出有利于開發(fā)人員的詳細設(shè)計方案，而是要確保新的需求滿足全局的要求。
4. 信任你的團隊...但要跟他們在一起——這關(guān)乎架構(gòu)師與開發(fā)人員的關(guān)系。架構(gòu)師需要確保他沒有逾越自己的角色，沒有獨占所有“做決定”的樂趣，使得開發(fā)人員的工作變得無聊。與此同時，架構(gòu)師需要給團隊提供指導，解決那些可能會導致開發(fā)人員停頓的困難問題。架構(gòu)師每天都應該與每位開發(fā)人員接觸，獲悉他們在做什么，并且在他們遇上編程問題的時候給予幫助。特別是當開發(fā)人員不喜歡尋求幫助，試圖花上整整一個禮拜的時間來自行解決問題的時候，這種幫助尤為需要。這種關(guān)系也適用于PjM和測試/構(gòu)建/發(fā)布團隊。
5. 編寫代碼！——架構(gòu)師應該知道代碼的質(zhì)量如何，這樣才會對他做出的決定所產(chǎn)生的影響有更好的理解。他也可以整明白何時重構(gòu)是必須的。 編寫代碼的架構(gòu)師在開發(fā)團隊中有更好的聲譽。也就是說，Hollander并不認同（設(shè)計和開發(fā)）職責的涇渭分明。他還認為，架構(gòu)師仍然是架構(gòu)師，他不一定要像普通的開發(fā)人員一樣擅長于編寫代碼。
6. 參與一切——架構(gòu)師參與所有與項目有關(guān)的會議：設(shè)計、開發(fā)、代碼評審、需求規(guī)劃等，這是有好處的，因為他能夠以更廣闊、更清晰的視角看待正在發(fā)生的事情，而且他能夠通過告知產(chǎn)品經(jīng)理其決定的潛在后果，從而幫助他/她避免在早期階段做出錯誤的決定。
7. 推動質(zhì)量文化——一個成功的團隊，一個人人都想成為其中一分子的團隊，是建立在質(zhì)量文化之上的：沒有人偷工減料；沒有人提交拙劣代碼；如果設(shè)計中有一個重大的缺陷，它絕不會不知不覺地混過關(guān)；所有人都是誠實和開放的，尋求整個團隊達到最佳的結(jié)果。Hollander承認，建立這樣一個團隊很難，但并非不可能。首先，架構(gòu)師應該在一開始就創(chuàng)建一些規(guī)則，這些規(guī)則不會因為開發(fā)人員不喜歡就隨著時間而改變。比如決定編寫單元測試，再比如在每次提交以前都要進行代碼評審，包括由架構(gòu)師提交的代碼。如果評審人員（可以是團隊中的任意一位）不認可代碼，代碼就不能提交。
8. 知道何時需要改變——架構(gòu)師應該非常靈活，隨時準備好在設(shè)計需要改變的時候去改變設(shè)計。早期的解決方案也許不再適合，抑或是新的需求需要不同的方法。
9. 屏蔽來自外部的隨機請求——雖然這通常是項目經(jīng)理/Scrum master的職責，但架構(gòu)師可以保護團隊不受外部請求的影響，這些影響往往會分散團隊的精力和浪費真正工作的時間。舉個例子：業(yè)務(wù)團隊可能想要以某種特定的方式完成某些特定的事情，而他們的請求并不全然合理，也并不是必須實現(xiàn)。 
10. 撰寫文檔...但只有當有人需要閱讀它們的時候——Hollander并不提倡記錄一切，也不提倡根本不撰寫任何文檔。他認為有必要取得一個平衡——只編寫一定數(shù)目真正有幫助的、有人會去閱讀的文檔。文檔在記錄詳細設(shè)計的決定（比如數(shù)據(jù)模型）方面是很好的載體。迭代的設(shè)計決定，雖然它們由整個團隊在迭代開始之初討論得出，但我們?nèi)匀唤ㄗh將它們記錄在5頁的文檔之中，以備開發(fā)人員日后不記得架構(gòu)師言論的時候進行查閱。而當最開始的開發(fā)人員和架構(gòu)師離開項目、加入其他項目之后，新加入項目工作的人也能借助于這些文檔理解某些決定的來龍去脈。 

綜上所述，Hollander指出，架構(gòu)師應該確保他從理論上和實踐上都是團隊的一分子。架構(gòu)師不應該編寫所有的代碼，而只是其中一小部分，他不去測試或部署這些代碼，但他要確保整個流程的順利進行。
轉(zhuǎn)載自：http://www.infoq.com/cn/news/2010/09/Tips-Architect-Agile-Team