敏捷開發團隊的10個最佳提示

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指出,架構師應該確保他從理論上和實踐上都是團隊的一分子。架構師不應該編寫所有的程式碼,而只是其中一小部分,他不去測試或部署這些程式碼,但他要確保整個流程的順利進行。

 

Scrum References

Scrum Events

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章