敏捷開發的實戰經驗介紹(2)

　　當Scrum團隊不大的時候，可以依靠主觀感覺來評估執行力。有道云筆記團隊在初創的一年內，對sprint的完成情況是沒有量化的評估的。

　　Scrum教材對執行力的量化評估用的是故事點和速率。由于團隊成員實際上都是有道云筆記的用戶，能夠直觀理解產品經理提出的需求。因此我們省去了用戶故事，由產品經理提產品需求，而團隊把需求分解成任務。經過一段時間的探索，我們定義了幾個量化指標，其中最重要的是完成度，我們用這個指標來衡量團隊的執行力：

　　完成度=1-計劃內未完成任務的剩余時間/計劃內任務評估時間

　　(完成度的數值在80~90%之間比較好。過高的完成度說明sprint計劃過于保守。)

　　有些管理者會懷疑完成度的準確性：第一是，團隊是否會把計劃內任務的評估時間評估得過長，使得完成度看起來高?事實上根據我們的經驗，團隊對計劃內任務的評估往往是偏樂觀的;第二是，計劃內未完成任務的剩余時間是如何出來的?這個是由團隊在sprint末尾評估出來的，因為這時技術設計多已完成，這個時間是比較準確的。我們也曾嘗試過燃盡圖，發現并不如完成度來得直觀。

　　另外，我們還定義了兩個指標來作為輔助參考。一個是評估準確度(計劃內任務評估時間/實際使用時間)，一個是計劃合理度(計劃內任務使用時間/計劃外任務使用時間)。這兩個指標的歷史數值可以讓我們更加了解團隊執行的情況。

　　5、高效的sprint計劃會的要素：預先梳理需求、合適的任務粒度、隨機認領任務、運營調研任務、任務評估。

　　Scrum開發中，最重要的會議是sprint計劃會。但是在這之前，產品經理和研發工程師可以預先梳理一下需求，以保證sprint計劃會可以更加高效和準確。我們嘗試過多種方式來預先梳理需求：發郵件、產品與研發面對面溝通、開需求梳理會。哪種方式更好，目前還沒有定論。

　　Sprint計劃會主要討論幾件事情：將需求分解成任務、評估每個任務的工作量、分配任務。每件事情都有各自的技巧。

　　首先，任務分解的粒度應該如何?Scrum開發一般認為任務分解得越細越好，但是在實際操作中我們發現如果分得太細的話是有問題的。比如說，認領任務、記錄每個任務的工時和完成情況，都會帶來時間消耗。我們經過較長時間的實踐，發現0.5至3天一個任務是一個合適的粒度范圍。

　　如何評估工作量和分配任務這兩個事情是關聯的，不同的人做同一個任務，往往時間會相差很大。所以這時候有一個艱難的選擇，是讓大家做自己熟悉擅長的事情，還是隨機認領任務以達到團隊人員對所有模塊都很熟悉的狀態。一個短期見效，另一個長期可發展。

　　有道云筆記PC平臺的Scrum團隊經歷了一個從前者轉向后者的過程。在開始很長一段時期里，Scrum團隊把自己PC客戶端按模塊進行拆分，每個模塊由一位研發工程師負責，工作量的評估也以這個人判斷為準。這個辦法幫助團隊快速開發了PC的第一個版本和后續幾個小版本。但是慢慢的，這種做法的瓶頸就出現了。之前的模塊劃分隨著項目發展變得有些過時，有的模塊出現了瓶頸。在最近的幾個sprint里，PC平臺的Scrum團隊已經開始隨機認領任務的方式。

　　此外，在實際研發工程中，往往會有一些由于團隊沒有相關的經驗而比較不確定的事情。對于這樣的事情，我們會先安排一個調研任務，并且將這個任務盡量安排在sprint的早期，并且憑借經驗會在計劃會上留出后續實際開發的時間。如果調研任務確定這個事情的復雜度可控，我們會在后續的sprint會議上根據調研成果分解出詳細的任務，另一方面，如果這個事情的復雜度太大，那么我們會把完不成的內容放到下個sprint。

　　任務評估的辦法，或者用紙筆寫下后同時公布或者用估算撲克，兩者本質上沒有區別。當有較大分歧時經過討論后再次評估，次數不宜過多，一般1-2次就好，不超過3次。如果討論不清楚，Scrum Master不妨先定一個時間，讓會議進行下去。后面實際開發過程中會越來越清楚。敏捷開發本來就是漸進的過程。

　　6、流水化安排開發環節與測試環節。

　　如何安排測試與開發，是從項目一開始我們就反復思考和嘗試的問題。經過一段時間的實踐，我們目前采用流水化的方式來安排開發環節與測試環節。具體來說，就是在開發sprint結束后再開始測試這個sprint的產出版本;而在開發的sprint內，開發團隊解決上一個sprint的產出版本測試出的bug。雖然這意味著開發團隊要在測試環節還未開始之時(Sprint計劃會上)，就要估計并預留出上個sprint產出版本的bug修改時間，但在實際操作中，開發團隊能夠通過歷史數據做出比較準確的估計。因此這種方式的效果是良好的。

　　7、版本發布基本按照sprint周期。

　　我們通常在一個或者多個sprint之后(在測試環節之后)發布版本。具體選取幾個sprint往往會參考一些市場情況的考慮，比如說將一個做了較多重構的sprint與一個做了較多新功能開發的sprint打包作為一個新版本發布出來。我們基本上不會為某個大版本打亂我們的sprint周期。

　　8、Scrum需要配備合適的工程實踐，例如單元測試、代碼審核、持續集成、項目管理工具。

　　我們要求研發工程師必須要寫單元測試和相互審核代碼。測試驅動開發和結對編程目前還有許多爭議，我們也不建議貿然嘗試。在實踐中，我們采用了簡化版本，對可以寫單元測試的模塊都要求測試覆蓋，并且通過測試覆蓋率來量化單元測試的力度。此外我們將研發工程師兩兩結對，相互檢查對方的代碼，只有經過檢查的代碼才能最終提交。

　　此外，我們對代碼進行了持續集成。每天凌晨持續集成系統會自動下載前一天的代碼，進行編譯和部署。Web端會直接部署到Web測試服務器，而客戶端(PC、iPhone、iPad、Android)會自動拷貝到一個內部服務器上。測試人員或者感興趣的人每一天一上班就可以用到最新的版本。

　　關于Scrum的任務管理，我們采用過不同的項目管理工具，包括白板、開源軟件等等?？偟膩碚f，工具只是簡化了一些統計，Scrum最重要的還是敏捷開發本身的思想。

原文轉自：http://tech.sina.com.cn/i/csj/2013-01-22/18528003613.shtml