瘋狂

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

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

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

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

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

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

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