蔣煒航:敏捷開發的實戰經驗

發表於2013-01-23

來源:創事記(感謝@雅楠七月 的推薦)

網易有道筆記負責人蔣煒航談敏捷開發的實戰經驗:什麼時候適合使用“敏捷開發”呢?我們的經驗是需要兩點:一、團隊有三名或以上的研發工程師;二、團隊內有一名合適的Scrum Master。

有道雲筆記團隊成立於從2010年,從成立伊始我們就一直積極地在實踐中嘗試Scrum(敏捷開發的一種專案管理方法)的做法。到2012年底,3.0釋出時,我們在5個主要平臺(PC、iPhone、Android、iPad、Web)上總共釋出了46個版本,累計了近千萬啟用使用者。在這個過程中,我們逐漸摸索出一套適合以產品和技術創新為核心的中等規模(數十人)研發團隊的Scrum實踐經驗。

蔣煒航:敏捷開發的實戰經驗

1、Scrum不是萬能藥,要在時機成熟時推行。

什麼時候算時機成熟呢?我們的經驗是需要兩點:一、團隊有三名或以上的研發工程師;二、團隊內有一名合適的Scrum Master。

剛開始的時候,一個開發團隊可能只有一名或者兩名研發工程師。這時候並沒有全面推行Scrum的必要,而可以借鑑Scrum中的一些做法。比如有道雲筆記的Web團隊最初就是這個情況。當Web團隊只有一名研發工程師時,我們就儘可能地尊重他的工作方式。同時為了保證專案進度可控,我們引入了Scrum的sprint機制——以sprint為開發週期,每個sprint進行一次Web產品演示。這不但能夠讓工程師有一個以sprint為期限的壓力,還能夠讓其他同事即時地瞭解專案的進展,以便做出相應調整。當Web團隊擴充為兩名工程師時,我們又引入了結對程式設計、持續整合、相互程式碼稽核等做法。直到Web團隊的規模進一步擴張時,我們才開始考慮全面啟用Scrum。

當團隊內無法找到合適的Scrum Master時,不要輕易推行敏捷。如果你的團隊是由新人組成,或者即使有資深員工但是他並不瞭解或認同敏捷開發的話,那麼你需要等待合適的Scrum Master出現。

合適的Scrum Master需要具備幾個特質:首先,他要認可敏捷開發這種方式;其次,他要熟悉業務,起到教練的作用,能帶領團隊走正確的流程;並且,當團隊遇到問題時,他要有能力和擔當引導團隊做出決定,在團隊成員遇到困難時,他要協助成員解決;最後,他要能識別重要和緊急的事情,而並不是事無鉅細的反饋到產品負責人那裡。

敏捷開發雖然希望團隊自我管理,但是這需要一個過程,開始的時候,一個合適的Scrum Master至關重要。有道雲筆記的Web團隊在成立一年多以後才開始推行Scrum,很大的一個原因是在培養合適的Scrum Master。依據我們的經驗,最勝任Scrum Master的人選是技術主管。我們也曾嘗試過讓產品經理擔任Scrum Master,但是由於產品經理本身往往擔當產品負責人,兼任Scrum Master會影響他在產品機會和產品體驗等方面的投入。

2、限制Scrum團隊的規模,建立Scrum團隊之間的協作機制。

隨著業務的發展,團隊會變大。這個時候不拆分團隊的話,效率會變低。

有道雲筆記移動端團隊就經歷過這樣一個過程。很長一段時間Android和iOS的研發工程師組成一個Scrum團隊,有共同的產品負責人和Scrum Master。但是隨著移動端團隊人數的增長,Scrum會議的效率卻降低了。雖然Scrum會議只有不到半小時,但是當說一個平臺的事情的時候,另一個平臺的工程師會覺得無所事事。發現了這個情況後,我們把移動端團隊按照平臺拆分成了兩個Scrum團隊,以確保Scrum會議上說的是每一名參與者都關心的事情。總的來說,參加Scrum會議的所有人,包括產品、開發和測試,不應該超過9個人。

按照平臺拆分團隊,限制了Scrum團隊的規模,提高了Scrum的效率。與此同時,多個Scrum團隊之間必須進行有效的協作。

在初期,我們鼓勵研發工程師通過面對面地商量,快速推進來處理平臺之間協作的需求。但是隨著業務的發展,這樣的協作越來越多,也越來越複雜,這樣面對面的討論往往會疏忽細節需求。比如說,有道雲筆記3.0版本中的待辦事項功能,就需要PC、Web、Android、iPhone以及Server等多個Scrum團隊一起,對這個功能進行產品定義和確定技術方案。這樣複雜的協同需求需要額外的機制來保證。這個機制就是Scrum Master的定期會議。在這個會議上,我們會討論各個Scrum團隊相互依賴的專案,安排好各Scrum團隊的開發順序。對某一件具體的事情,其中的一位Scrum Master會被指定為具體負責人來驅動跨Scrum團隊的協作。同樣,只有當Scrum團隊間的協作任務比較複雜的時候才需要引入這個機制。

3、產品經理和研發工程師要擁抱Scrum帶來的變化。

在引入Scrum之前,一般的專案管理方式是版本式(瀑布式)的,產品經理決定下一個版本做什麼,預期釋出的時間,然後由產品負責人或者技術負責人來兼做專案經理。這個時候遇到的問題是專案往往會延期,但是產品經理會有一種對專案把控的感覺。

引入敏捷開發之後,這個事情變了,釋出是跟著sprint走的。基於持續交付的原則,一次釋出包含一個或者多個sprint的內容,而這些內容是由團隊整體決定的,而不是產品經理個人決定。產品經理只是定義了功能需求的優先順序,這些功能需求與程式碼重構、開發工具、以及市場運營等的推廣支援等需求一起排期,最後由整個團隊決定一個sprint做哪些東西。

從表面上看起來,產品經理對產品的把控小了,為此,團隊一位資深產品經理有過質疑。最後,我們還是說服了他接受敏捷。事實上,接受Scrum並不困難。這樣,產品經理可以把重心放在對產品需求的把握上,而不必整天問這個咋樣了那個咋樣了。而且,團隊的開發效率,功能點完成的速度並沒有因此而降低。

研發工程師同樣要擁抱Scrum,調整自己的工作方式。Scrum不鼓勵過度設計,而採用湧現式設計。這意味著開始往往不會把技術架構做得大而全,而是鼓勵快速出成果。當然這並不是說程式架構能夠設計得很糟糕,而是說不要花太多的精力在未知的事情上,小步快跑。為此,程式碼重構是必須的(編者注:在不改變軟體現有功能的基礎上,通過調整程式程式碼改善軟體)。我們並不建議整個sprint都去做重構,更建議持續重構,把程式碼調整也分解成任務,每個sprint做一些。在一些大版本釋出之後,重構任務的比例可以適當高一些。

4、量化衡量團隊的執行力的指標:完成度、評估準確度、計劃合理度

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

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

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

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

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

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

蔣煒航:敏捷開發的實戰經驗

當Scrum團隊不大的時候,可以依靠主觀感覺來評估執行力。團隊擴大後,詳細的數值評估必不可少。

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的任務管理,我們採用過不同的專案管理工具,包括白板、開源軟體等等。總的來說,工具只是簡化了一些統計,Scrum最重要的還是敏捷開發本身的思想。

編者注:名詞詳細解釋(感謝李瑋對本文編輯的貢獻)

敏捷開發:相對於傳統的版本式(瀑布式)開發模式。以往的開發模式中,一次會做一個大版本,在這個版本的開發過程中定義需要開發哪些功能,需要多少資源,需要多長週期,最終一次性交付這樣一個版本。敏捷開發則是將一個很大的版本儘量細分為小的功能、模組或階段,每次做其中一部分,做完以後立即釋出一個小版本給使用者。

Scrum:敏捷開發的一種專案管理方法,通常表示敏捷開發所承擔的一個階段性任務,做完這個任務就可以釋出小版本。在做這個任務的過程中團隊稱作Scrum團隊,負責人是Scrum Master。這種Scrum團隊和以往的團隊相比,要求每一個團隊成員掌握更全面的知識,而不是以往軟體開發不懂測試,軟體測試不懂開發。每個人都需要有獨立解決問題的能力。對Scrum Master來說,需要了解整個Scrum的全貌,並具備整個過程中各個領域的知識,因此通常是技術牛人,而不是專案管理者去做Scrum Master。

Sprint:表示Scrum中的一個階段,是對Scrum繼續的細分。比如分給某個人開發50行程式碼的一個任務,他的第一個sprint可以是閱讀需求文件,第二個是寫程式碼,第三個是debug。好的敏捷開發中每個Sprint的任務量需要有較好的定義,不能太少,也不能讓人做不完,因為每個Sprint的時間是固定的。

 

相關文章