建站
咨詢
售后
建站咨詢
新聞中心
[[62374]]
網(wǎng)易有道筆記負責人談敏捷開發(fā)的實戰(zhàn)經(jīng)驗：什么時候適合使用“敏捷開發(fā)”呢？我們的經(jīng)驗是需要兩點：一、團隊有三名或以上的研發(fā)工程師；二、團隊內有一名合適的Scrum Master。
10年的杭州網(wǎng)站建設經(jīng)驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。成都營銷網(wǎng)站建設的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調整杭州建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)公司從事“杭州網(wǎng)站設計”,“杭州網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。
作者：蔣煒航，網(wǎng)易有道筆記負責人
注：名詞詳細解釋見文末
有道云筆記團隊成立于從2010年，從成立伊始我們就一直積極地在實踐中嘗試Scrum(敏捷開發(fā)的一種項目管理方法)的做法。到2012年底，3.0發(fā)布時，我們在5個主要平臺(PC、iPhone、Android、iPad、Web)上總共發(fā)布了46個版本，累計了近千萬激活用戶。在這個過程中，我們逐漸摸索出一套適合以產(chǎn)品和技術創(chuàng)新為核心的中等規(guī)模(數(shù)十人)研發(fā)團隊的Scrum實踐經(jīng)驗。
1、Scrum不是萬能藥，要在時機成熟時推行。
什么時候算時機成熟呢？我們的經(jīng)驗是需要兩點：一、團隊有三名或以上的研發(fā)工程師；二、團隊內有一名合適的Scrum Master。
剛開始的時候，一個開發(fā)團隊可能只有一名或者兩名研發(fā)工程師。這時候并沒有全面推行Scrum的必要，而可以借鑒Scrum中的一些做法。比如有道云筆記的Web團隊最初就是這個情況。當Web團隊只有一名研發(fā)工程師時，我們就盡可能地尊重他的工作方式。同時為了保證項目進度可控，我們引入了 Scrum的sprint機制——以sprint為開發(fā)周期，每個sprint進行一次Web產(chǎn)品演示。這不但能夠讓工程師有一個以sprint為期限的壓力，還能夠讓其他同事即時地了解項目的進展，以便做出相應調整。當Web團隊擴充為兩名工程師時，我們又引入了結對編程、持續(xù)集成、相互代碼審核等做法。直到Web團隊的規(guī)模進一步擴張時，我們才開始考慮全面啟用Scrum。
當團隊內無法找到合適的Scrum Master時，不要輕易推行敏捷。如果你的團隊是由新人組成，或者即使有資深員工但是他并不了解或認同敏捷開發(fā)的話，那么你需要等待合適的Scrum Master出現(xiàn)。
合適的Scrum Master需要具備幾個特質：首先，他要認可敏捷開發(fā)這種方式；其次，他要熟悉業(yè)務，起到教練的作用，能帶領團隊走正確的流程；并且，當團隊遇到問題時，他要有能力和擔當引導團隊做出決定，在團隊成員遇到困難時，他要協(xié)助成員解決；最后，他要能識別重要和緊急的事情，而并不是事無巨細的反饋到產(chǎn)品負責人那里。
敏捷開發(fā)雖然希望團隊自我管理，但是這需要一個過程，開始的時候，一個合適的Scrum Master至關重要。有道云筆記的Web團隊在成立一年多以后才開始推行Scrum，很大的一個原因是在培養(yǎng)合適的Scrum Master。依據(jù)我們的經(jīng)驗，最勝任Scrum Master的人選是技術主管。我們也曾嘗試過讓產(chǎn)品經(jīng)理擔任Scrum Master，但是由于產(chǎn)品經(jīng)理本身往往擔當產(chǎn)品負責人，兼任Scrum Master會影響他在產(chǎn)品機會和產(chǎn)品體驗等方面的投入。
2、限制Scrum團隊的規(guī)模，建立Scrum團隊之間的協(xié)作機制。
隨著業(yè)務的發(fā)展，團隊會變大。這個時候不拆分團隊的話，效率會變低。
有道云筆記移動端團隊就經(jīng)歷過這樣一個過程。很長一段時間Android和iOS的研發(fā)工程師組成一個Scrum團隊，有共同的產(chǎn)品負責人和 Scrum Master。但是隨著移動端團隊人數(shù)的增長，Scrum會議的效率卻降低了。雖然Scrum會議只有不到半小時，但是當說一個平臺的事情的時候，另一個平臺的工程師會覺得無所事事。發(fā)現(xiàn)了這個情況后，我們把移動端團隊按照平臺拆分成了兩個Scrum團隊，以確保Scrum會議上說的是每一名參與者都關心的事情?？偟膩碚f，參加Scrum會議的所有人，包括產(chǎn)品、開發(fā)和測試，不應該超過9個人。
按照平臺拆分團隊，限制了Scrum團隊的規(guī)模，提高了Scrum的效率。與此同時，多個Scrum團隊之間必須進行有效的協(xié)作。
在初期，我們鼓勵研發(fā)工程師通過面對面地商量，快速推進來處理平臺之間協(xié)作的需求。但是隨著業(yè)務的發(fā)展，這樣的協(xié)作越來越多，也越來越復雜，這樣面對面的討論往往會疏忽細節(jié)需求。比如說，有道云筆記3.0版本中的待辦事項功能，就需要PC、Web、Android、iPhone以及Server 等多個Scrum團隊一起，對這個功能進行產(chǎn)品定義和確定技術方案。這樣復雜的協(xié)同需求需要額外的機制來保證。這個機制就是Scrum Master的定期會議。在這個會議上，我們會討論各個Scrum團隊相互依賴的項目，安排好各Scrum團隊的開發(fā)順序。對某一件具體的事情，其中的一位Scrum Master會被指定為具體負責人來驅動跨Scrum團隊的協(xié)作。同樣，只有當Scrum團隊間的協(xié)作任務比較復雜的時候才需要引入這個機制。
3、產(chǎn)品經(jīng)理和研發(fā)工程師要擁抱Scrum帶來的變化。
在引入Scrum之前，一般的項目管理方式是版本式(瀑布式)的，產(chǎn)品經(jīng)理決定下一個版本做什么，預期發(fā)布的時間，然后由產(chǎn)品負責人或者技術負責人來兼做項目經(jīng)理。這個時候遇到的問題是項目往往會延期，但是產(chǎn)品經(jīng)理會有一種對項目把控的感覺。
引入敏捷開發(fā)之后，這個事情變了，發(fā)布是跟著sprint走的?；诔掷m(xù)交付的原則，一次發(fā)布包含一個或者多個sprint的內容，而這些內容是由團隊整體決定的，而不是產(chǎn)品經(jīng)理個人決定。產(chǎn)品經(jīng)理只是定義了功能需求的優(yōu)先級，這些功能需求與代碼重構、開發(fā)工具、以及市場運營等的推廣支持等需求一起排期，最后由整個團隊決定一個sprint做哪些東西。
從表面上看起來，產(chǎn)品經(jīng)理對產(chǎn)品的把控小了，為此，團隊一位資深產(chǎn)品經(jīng)理有過質疑。最后，我們還是說服了他接受敏捷。事實上，接受Scrum并不困難。這樣，產(chǎn)品經(jīng)理可以把重心放在對產(chǎn)品需求的把握上，而不必整天問這個咋樣了那個咋樣了。而且，團隊的開發(fā)效率，功能點完成的速度并沒有因此而降低。
研發(fā)工程師同樣要擁抱Scrum，調整自己的工作方式。Scrum不鼓勵過度設計，而采用涌現(xiàn)式設計。這意味著開始往往不會把技術架構做得大而全，而是鼓勵快速出成果。當然這并不是說程序架構能夠設計得很糟糕，而是說不要花太多的精力在未知的事情上，小步快跑。為此，代碼重構是必須的(編者注：在不改變軟件現(xiàn)有功能的基礎上，通過調整程序代碼改善軟件)。我們并不建議整個sprint都去做重構，更建議持續(xù)重構，把代碼調整也分解成任務，每個sprint做一些。在一些大版本發(fā)布之后，重構任務的比例可以適當高一些。
4、量化衡量團隊的執(zhí)行力的指標：完成度、評估準確度、計劃合理度。
當Scrum團隊不大的時候，可以依靠主觀感覺來評估執(zhí)行力。有道云筆記團隊在初創(chuàng)的一年內，對sprint的完成情況是沒有量化的評估的。
Scrum教材對執(zhí)行力的量化評估用的是故事點和速率。由于團隊成員實際上都是有道云筆記的用戶，能夠直觀理解產(chǎn)品經(jīng)理提出的需求。因此我們省去了用戶故事，由產(chǎn)品經(jīng)理提產(chǎn)品需求，而團隊把需求分解成任務。經(jīng)過一段時間的探索，我們定義了幾個量化指標，其中最重要的是完成度，我們用這個指標來衡量團隊的執(zhí)行力：
完成度=1-計劃內未完成任務的剩余時間/計劃內任務評估時間
(完成度的數(shù)值在80~90%之間比較好。過高的完成度說明sprint計劃過于保守。)
有些管理者會懷疑完成度的準確性：第一是，團隊是否會把計劃內任務的評估時間評估得過長，使得完成度看起來高？事實上根據(jù)我們的經(jīng)驗，團隊對計劃內任務的評估往往是偏樂觀的；第二是，計劃內未完成任務的剩余時間是如何出來的？這個是由團隊在sprint末尾評估出來的，因為這時技術設計多已完成，這個時間是比較準確的。我們也曾嘗試過燃盡圖，發(fā)現(xiàn)并不如完成度來得直觀。
另外，我們還定義了兩個指標來作為輔助參考。一個是評估準確度(計劃內任務評估時間/實際使用時間)，一個是計劃合理度(計劃內任務使用時間/計劃外任務使用時間)。這兩個指標的歷史數(shù)值可以讓我們更加了解團隊執(zhí)行的情況。
當Scrum團隊不大的時候，可以依靠主觀感覺來評估執(zhí)行力。團隊擴大后，詳細的數(shù)值評估必不可少。
5、高效的sprint計劃會的要素：預先梳理需求、合適的任務粒度、隨機認領任務、運營調研任務、任務評估。
Scrum開發(fā)中，最重要的會議是sprint計劃會。但是在這之前，產(chǎn)品經(jīng)理和研發(fā)工程師可以預先梳理一下需求，以保證sprint計劃會可以更加高效和準確。我們嘗試過多種方式來預先梳理需求：發(fā)郵件、產(chǎn)品與研發(fā)面對面溝通、開需求梳理會。哪種方式更好，目前還沒有定論。
Sprint計劃會主要討論幾件事情：將需求分解成任務、評估每個任務的工作量、分配任務。每件事情都有各自的技巧。
首先，任務分解的粒度應該如何？Scrum開發(fā)一般認為任務分解得越細越好，但是在實際操作中我們發(fā)現(xiàn)如果分得太細的話是有問題的。比如說，認領任務、記錄每個任務的工時和完成情況，都會帶來時間消耗。我們經(jīng)過較長時間的實踐，發(fā)現(xiàn)0.5至3天一個任務是一個合適的粒度范圍。
如何評估工作量和分配任務這兩個事情是關聯(lián)的，不同的人做同一個任務，往往時間會相差很大。所以這時候有一個艱難的選擇，是讓大家做自己熟悉擅長的事情，還是隨機認領任務以達到團隊人員對所有模塊都很熟悉的狀態(tài)。一個短期見效，另一個長期可發(fā)展。
有道云筆記PC平臺的Scrum團隊經(jīng)歷了一個從前者轉向后者的過程。在開始很長一段時期里，Scrum團隊把自己PC客戶端按模塊進行拆分，每個模塊由一位研發(fā)工程師負責，工作量的評估也以這個人判斷為準。這個辦法幫助團隊快速開發(fā)了PC的第一個版本和后續(xù)幾個小版本。但是慢慢的，這種做法的瓶頸就出現(xiàn)了。之前的模塊劃分隨著項目發(fā)展變得有些過時，有的模塊出現(xiàn)了瓶頸。在最近的幾個sprint里，PC平臺的Scrum團隊已經(jīng)開始隨機認領任務的方式。
此外，在實際研發(fā)工程中，往往會有一些由于團隊沒有相關的經(jīng)驗而比較不確定的事情。對于這樣的事情，我們會先安排一個調研任務，并且將這個任務盡量安排在sprint的早期，并且憑借經(jīng)驗會在計劃會上留出后續(xù)實際開發(fā)的時間。如果調研任務確定這個事情的復雜度可控，我們會在后續(xù)的sprint會議上根據(jù)調研成果分解出詳細的任務，另一方面，如果這個事情的復雜度太大，那么我們會把完不成的內容放到下個sprint。
任務評估的辦法，或者用紙筆寫下后同時公布或者用估算撲克，兩者本質上沒有區(qū)別。當有較大分歧時經(jīng)過討論后再次評估，次數(shù)不宜過多，一般1-2 次就好，不超過3次。如果討論不清楚，Scrum Master不妨先定一個時間，讓會議進行下去。后面實際開發(fā)過程中會越來越清楚。敏捷開發(fā)本來就是漸進的過程。
6、流水化安排開發(fā)環(huán)節(jié)與測試環(huán)節(jié)。
如何安排測試與開發(fā)，是從項目一開始我們就反復思考和嘗試的問題。經(jīng)過一段時間的實踐，我們目前采用流水化的方式來安排開發(fā)環(huán)節(jié)與測試環(huán)節(jié)。具體來說，就是在開發(fā)sprint結束后再開始測試這個sprint的產(chǎn)出版本；而在開發(fā)的sprint內，開發(fā)團隊解決上一個sprint的產(chǎn)出版本測試出的bug。雖然這意味著開發(fā)團隊要在測試環(huán)節(jié)還未開始之時(Sprint計劃會上)，就要估計并預留出上個sprint產(chǎn)出版本的bug修改時間，但在實際操作中，開發(fā)團隊能夠通過歷史數(shù)據(jù)做出比較準確的估計。因此這種方式的效果是良好的。
7、版本發(fā)布基本按照sprint周期。
我們通常在一個或者多個sprint之后(在測試環(huán)節(jié)之后)發(fā)布版本。具體選取幾個sprint往往會參考一些市場情況的考慮，比如說將一個做了較多重構的sprint與一個做了較多新功能開發(fā)的sprint打包作為一個新版本發(fā)布出來。我們基本上不會為某個大版本打亂我們的sprint周期。
8、Scrum需要配備合適的工程實踐，例如單元測試、代碼審核、持續(xù)集成、項目管理工具。
我們要求研發(fā)工程師必須要寫單元測試和相互審核代碼。測試驅動開發(fā)和結對編程目前還有許多爭議，我們也不建議貿(mào)然嘗試。在實踐中，我們采用了簡化版本，對可以寫單元測試的模塊都要求測試覆蓋，并且通過測試覆蓋率來量化單元測試的力度。此外我們將研發(fā)工程師兩兩結對，相互檢查對方的代碼，只有經(jīng)過檢查的代碼才能最終提交。
此外，我們對代碼進行了持續(xù)集成。每天凌晨持續(xù)集成系統(tǒng)會自動下載前一天的代碼，進行編譯和部署。Web端會直接部署到Web測試服務器，而客戶端(PC、iPhone、iPad、Android)會自動拷貝到一個內部服務器上。測試人員或者感興趣的人每一天一上班就可以用到最新的版本。
關于Scrum的任務管理，我們采用過不同的項目管理工具，包括白板、開源軟件等等?？偟膩碚f，工具只是簡化了一些統(tǒng)計，Scrum最重要的還是敏捷開發(fā)本身的思想。
編者注：名詞詳細解釋(感謝李瑋對本文編輯的貢獻)
敏捷開發(fā)：相對于傳統(tǒng)的版本式(瀑布式)開發(fā)模式。以往的開發(fā)模式中，一次會做一個大版本，在這個版本的開發(fā)過程中定義需要開發(fā)哪些功能，需要多少資源，需要多長周期，最終一次性交付這樣一個版本。敏捷開發(fā)則是將一個很大的版本盡量細分為小的功能、模塊或階段，每次做其中一部分，做完以后立即發(fā)布一個小版本給用戶。
Scrum：敏捷開發(fā)的一種項目管理方法，通常表示敏捷開發(fā)所承擔的一個階段性任務，做完這個任務就可以發(fā)布小版本。在做這個任務的過程中團隊稱作Scrum團隊，負責人是Scrum Master。這種Scrum團隊和以往的團隊相比，要求每一個團隊成員掌握更全面的知識，而不是以往軟件開發(fā)不懂測試，軟件測試不懂開發(fā)。每個人都需要有獨立解決問題的能力。對Scrum Master來說，需要了解整個Scrum的全貌，并具備整個過程中各個領域的知識，因此通常是技術牛人，而不是項目管理者去做Scrum Master。
Sprint：表示Scrum中的一個階段，是對Scrum繼續(xù)的細分。比如分給某個人開發(fā)50行代碼的一個任務，他的第一個sprint可以是閱讀需求文檔，第二個是寫代碼，第三個是debug。好的敏捷開發(fā)中每個Sprint的任務量需要有較好的定義，不能太少，也不能讓人做不完，因為每個Sprint的時間是固定的。
原文鏈接：http://tech.sina.com.cn/i/csj/2013-01-22/18528003613.shtml
文章題目：蔣煒航：敏捷開發(fā)的實戰(zhàn)經(jīng)驗
瀏覽地址：http://m.5511xx.com/article/cdohjsj.html
