給敏捷團隊中的架構師的10個建議

微軟澳大利亞的解決方案架構師Tom Hollander，在TechEd Australia大會上舉行了一場題爲“敏捷團隊中的架構師角色”的演講。在演講中，他討論了他作爲領導敏捷團隊的架構師所做的工作。
from：http://www.infoq.com/cn/news/2010/09/Tips-Architect-Agile-Team

在談到架構師的角色時，Hollander指的是“解決方案架構師”或者應用架構師。他不是指企業架構師或者其他的專業人士（專精於特定的領域，例如消息或基礎設施）。

Hollander的團隊採納了由4周迭代以及最後的穩定階段（幾天代碼凍結的時間）組成的流程，實施了每日站立會議、每日構建與自動化測試的持續集成等實踐，並採用了許多角色：

• PjM——項目經理，類似於Scrum Master，確保團隊遵循了流程
• PdM——產品經理，也被稱爲客戶或Product Owner，決定產品應該是什麼樣子
• 架構師——解決方案/應用架構師
• 開發人員——開發團隊
• 測試人員——測試團隊
• 用戶體驗設計人員（UX）——用戶體驗團隊
• 發佈人員——承擔構建和發佈的職責，負責維護構建的流程

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

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

綜上所述，Hollander指出，架構師應該確保他從理論上和實踐上都是團隊的一分子。架構師不應該編寫所有的代碼，而只是其中一小部分，他不去測試或部署這些代碼，但他要確保整個流程的順利進行。
 

Tom Hollander, a Solutions Architect at Microsoft Australia, held a presentation entitled The Role of an Architect in an Agile Team at TechEd Australia where he discussed  what he does as an architect leading an agile team.

When talking about the role of an architect, Hollander means a “solution architect’ or an application architect. He does not refer to an enterprise architect or a specialist one (specialized on a specific field like messaging or infrastructure). 

Hollander’s team has a 4 week iteration process with a stabilization period – code freeze for a few days - at the end, practices daily stand-up meetings, continuous integrations with daily builds followed by automated tests, and is employing a number of roles:

• PjM – is the Project Manager, similar to a Scrum Master, making sure the team is following the process.
• PdM – is the Product Manager, also known as the Customer or the Product Owner, determining what the product is supposed to be
• Architect – a solution/application architect
• Dev – the development team
• Test – the test team
• UX – the User Experience team
• Release – the Build and Release role taking care of the building process

Hollander has come up with a top 10 list of things for a solution architect to be successful in an agile team:

1. “Just enough” upfront design – except for very simple projects, a certain amount of upfront design – 1-2 weeks - is absolutely needed based on what type of application is - web app, smart client, mobile or batch –, what are the basic functionality requirements, a long term solution or an intermediary, temporary one. The purpose of the upfront design is to decide: what technology to use – for example, ASP.NET or MVC –, what type of application - a 2-tier, a 3-tier or a service-oriented application –, accessing the DB – stored procedures, Entity Framework, LINQ, DI. All that can be contained in a short document for reference.
2. Start with a vertical slice – means starting with a small piece of functionality – a logon page, for example – which cuts as many vertical layers as possible in order to tie together all the technology pieces decided during the previous phase. This will demonstrate that the design decisions are correct and all pieces are working together, and will represent a pattern for developers to follow when developing the additional code. If the initial design decisions turn out to be inappropriate, now it is a good time to change them.
3. Just-in-time design each iteration – At the middle of a 4-week iteration, the project manager, the product manager and the architect should meet to discuss the requirements to be addressed during the following iteration, to make sure they all agree on them, what is more important is put up in front, and everything is understood. That discussion goes on for a week in the background of the current iteration. The following week, the last of the current iteration, the architect reviews the requirements for the next iteration, making the necessary design decisions so the team can start working on them the following week. If the requirements are quite different from previous ones, then the architect does some prototyping, writing some code as a proof of concept, writing some diagrams and putting it all together in a 5-page document for reference. This is not meant to do detailed design decisions made for the developer, but rather to make sure the new requirements fit into the big picture.
4. Trust your team… but be there for them – this has to do with the relationship architect-developer. The architect needs to make sure he does not overstep his role, making the developer’s job boring by taking all the fun of decision making. In the same time, the architect needs to be a mentor for the team, solving difficult problems that might bog down the developers. The architect should be in contact with every developer each day, knowing what they are doing and helping them if there is a coding problem. This is especially needed when dealing with developers that don’t like to ask for help and try to solve problems on their own with the price of spending an entire week with that. This kind of relationship also applies to the PjM and test/build/release team.
5. Write code! – The architect should know what’s in the code in order to have a better idea on the impact of his decisions. He can also figure out when a refactoring is needed. A code writing architect has better credibility with the development team. That being said, Hollander does not believe in role dissolution. He still thinks an architect remains an architect, and he’s not necessarily as good at writing code as a regular developer.
6. Be involved in everything – It is good for the architect to be involved in all meetings related to his project: design, development, code reviews, requirements planning, etc., because he can have a larger and more clear perspective on what is going on, and he can help the product manager to avoid making wrong decisions in an early stage by informing him/her on their possible outcome.
7. Drive a culture of quality – A successful team, one that anyone would like to be part of is one built on a culture of quality: nobody cuts corners, nobody checks-in sloppy code, if there is a major flaw in the design it won’t pass unnoticed, all are honest and open, looking for the best outcome of the entire team. Hollander admits that it is hard to build such a team, but it is possible. Firstly, the architect should establish some rules in the beginning, rules are are not going to change over time because a developer happens to not like them. One example is the decision to write unit tests. Another is having a code review before each check-in, including the code submitted by the architect. If the code is not accepted by the reviewer, which can be anybody in the team, the code is not checked-in.
8. Know when changes are required – The architect should be very flexible and ready to make design changes when they are required. It may be that an early solution is no longer appropriate, or new requirements demand a different approach.
9. Shield the team from external randomization – While this is usually the job of a project manager/Scrum master, the architect can get involved in protecting the team from external requests that tend to divert the team’s focus and take time from actual work. One example could be various requests coming from the operations team wanting certain things to be done in a certain way, and their requests are not always reasonable or something that has to be implemented.
10. Write docs … but only if someone needs to read them – Hollander is not the adept of documenting everything, nor one of writing no documentation. He thinks there is necessary to have a balance, writing the amount of documentation that is actually helpful and is read by someone. Documents are good to remember detailed design decisions like a data model. Iteration design decisions, while they are discussed with the team at the beginning of the iteration, it is recommended to be saved in a 5-pages document for the developers to go to if one of them does not remember what the architect said. This also helps new people working on the project long after the initial developers and architect moved to another project to understand why some of the decisions were made. 

As a conclusion, Hollander said the architect should make sure he is part of the team in theory and in practice. The architect is not supposed to write all the code, only a small portion, he is not testing or deploying it, but he is rather making sure the entire process runs smoothly.