敏捷開發的實戰經驗介紹

　　網易有道筆記負責人談敏捷開發的實戰經驗：什么時候適合使用“敏捷開發”呢?我們的經驗是需要兩點：一、團隊有三名或以上的研發工程師;二、團隊內有一名合適的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會議上說的是每一名參與者都關心的事情?？偟膩碚f，參加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走的?；诔掷m交付的原則，一次發布包含一個或者多個sprint的內容，而這些內容是由團隊整體決定的，而不是產品經理個人決定。產品經理只是定義了功能需求的優先級，這些功能需求與代碼重構、開發工具、以及市場運營等的推廣支持等需求一起排期，最后由整個團隊決定一個sprint做哪些東西。

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

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

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

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