一個輕量級的軟體開發方法 

Scrum是一個敏捷開發框架，是一個增量迭代的開發過程.。在這個框架整個開發週期由若干個小的跌代週期，每個小的的跌代週期稱為一個Sprint，每個Sprint的長度2到4周。在每個Sprint中，Scrum的開發團隊拿到一個排列好優先順序的需求列表，我們稱它為使用者故事或者叫Sprint backlog， 所以我們先開發的是對客戶具有較高價值的需求。  在每個迭代結束後，都會開發完成可交付的產品。 
一個簡單的框架 

Scrum由三個角色，三種活動，3種交付物組成： 

三個角色： 

Product Owner 

Scrum Master 

Scrum Team 

三種活動: 

the sprint planning meeting 

daily scrum meetings 

sprint review meetings 

3種產物: 

the product backlog 

the sprint backlog 

a burndown chart 
一個經歷過時間考驗的開發過程 

Scrum最早由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA會議上形式化了Scrum開發過程，並向業界公佈。 

之後，Scrum成為領先的敏捷開發方法之一，目前世界上有超過500家公司在使用Scrum。 



Scrum的特點： 

    * Scrum是一個敏捷的流程，可用於管控研發工作。 
    * Scrum是現有設計流程的總結。 
    * Scrum以團隊為基礎，是一種在需求求迅速變化情況下迭代地、增量地開發系統和產品的方法。 
    * Scrum是一個控制由利益和需求衝突導致的混亂的流程。 
    * Scrum是改善交流並最優化合作的方式。 
    * Scrum是一種檢測產品開發和生產過程中障礙並將其去除的方式。 
    * Scrum是最大化生產率的一種方法。 
    * Scrum適用於單一的專案到整個組織。Scrum可以控制並組織多件具有相關性的產品開發以及擁有超過千名開發者和執行者的專案實施過程。 
    * Scrum能讓每個參與者都對自己所做的工作以及自己做出的貢獻感到驕傲，並讓他們發揮到最佳水平。 





      二 Scrum較傳統開發模型的優點 

      Scrum模型的一個顯著特點就是響應變化，它能夠儘快地響應變化。下面的圖片使用傳統的軟體開發模型(瀑布模型、螺旋模型或迭代模型)。隨著系統因素（內部和外部因素）的複雜度增加，專案成功的可能性就迅速降低。 


      下圖是Scrum模型和傳統模型的對比： 




Scrum有3個角色： Product Owner, ScrumMaster, and Scrum Team. 

Product Owner的職責： 

    * 確定產品的功能。 
    * 決定釋出的日期和釋出內容。 
    * 為產品的profitability of the product (ROI)負責。 
    * 根據市場價值確定功能優先順序。 
    * 在30天內調整功能和調整功能優先順序。 
    * 接受或拒絕接受開發團隊的工作成果。 

Product Owner參與Scrum planning。 

ScrumMaster 作為team leader和Product owner緊密地工作在一起，他可以及時地為團隊成員提供幫助。他必須: 

    * 保證團隊資源完全可被利用並且全部是高產出的。 
    * 保證各個角色及職責的良好協作。 
    * 解決團隊開發中的障礙。 
    * 做為團隊和外部的介面，遮蔽外界對團隊成員的干擾。 
    * 保證開發過程按計劃進行，組織 Daily Scrum, Sprint Review and Sprint Planning meetings。 

ScrumMaster 除了主持Daily Scrum meeting之外，還有三個主要職責： 

   1. 
      Scrummaster需要知道什麼任務已經完成，哪些任務已經開始，哪些新的任務已發現，和哪些估計可能已經發生變化。Scrummaster需要根據以上的情況更新反映每天完成的工作量以及還有多少沒有完成的Burndown Chart。 
      scrummaster還必須仔細考慮進展中的開放任務數，進展中的工作需要得到最小化，以實現精益生產率的收益。 
   2. 
      該scrummaster需要找出阻礙 Scrum的障礙和依賴。他們需要的優先次序和跟蹤。根據優先順序指定計劃解決這些障礙。其中有些問題可以在團隊內部解決，有些則要團隊之間的協調，還有的要管理層的介入來解決，甚至有些是公司的問題阻礙了團隊達到他們的生產力。比如：一個電信公司最近實施了Scrum，但後來發現只有兩個問題和scrum team有關，其他的全是公司的問題需要管理層關注。 
   3. 
      最後但並非最不重要， scrummaster可能會注意到，個人問題或衝突在Scrum裡是需要解決的。這些都需要被澄清，或通過內部的溝通解決，或向管理層和HR尋求幫助解決。Scrum Master 必須注意去確保團隊資源完全可被利用並且全部是高產出的。 

Scrum Team: 

    * 具有不同特長的團隊成員，人數控制在7個左右 
    * 確定Sprint目標和具體說明的工作成果。 
    * 在專案嚮導範圍內有權利做任何事情已確保達到Sprint的目標。 
    * 高度的自我管理能力。 
    * 向Product Owner演示產品功能。 



Scrum有三個儀式：Sprint規劃會，Sprint評審會，Scrum每日站會 
Sprint Planning Meeting（Sprint規劃會） 

根據Product Owner制定的產品或專案計劃在Sprint的開始時做準備工作。Product Owner可以是客戶或者客戶代表或代理。對於產品型的公司，客戶就是市場，Product Owner扮演市場代理的角色。一個Product Owner需要一個確定產品最終目標的遠景，規劃出今後一段時間產品發展的路線圖，以及根據對投資回報的貢獻確定的產品特性。他要準備一個根據商業價值排好序的客戶需求列表。這個列表就是Prodct Backlog，一個最終會交付給客戶的產品特性列表，它們根據商業價值來排列優先順序。 

當為一個Sprint定義好足夠多的Product Backlog，並且排列好優先順序後Scrum就可以開始了，Sprint規劃會是用來細化當前跌打得開發計劃的。規劃會開始的時候，Product Owner會和Scrum team一起評審版本，路線圖，釋出計劃，及Product Backlog。Scrum Team會評審Product Backlog中功能點的時間估計並確認這些估計儘可能的準確。Scrum Team會根據資源情況看有多少feature可以放在當前的Sprint中。Scrum Team按照優先順序的高低來確定開發的先後是很重要的。 

當Sprint backlog確定後，ScrumMaster帶領Scrum Team去分解這些功能點，細化成Sprint的一個個任務. 這些任務就是細化的來實施這些功能點的活動. Sprint Planning的這個階段需要控制在4個小時。 
Daily Scrum Meeting（每日站會） 

一旦計劃階段結束，30天週期的Sprint就開始了。ScrumMaster需要組織團隊成員每天開站會. 這個會議是用15分鐘的時間來讓大家過一下scrum的狀態。在會上，每個團隊成員需要問3個問題：我昨天做了什麼，今天做什麼，遇到哪些障礙。誰都可以參加這個會議，但只有Scrum團隊成員有發言權。這個會議的目標是得到一個專案的全域性觀，用於發現任何新的依賴，定位專案成員的要求，實時的調整當天開發計劃. 
Sprint Review Meeting（Sprint評審會） 

在Sprint結束的時候召開Sprint評審會. 這個會議最多不超過4個小時.會議的前一半時間用來演示在這個Sprint中開發的產品功能給Product Owner. Produc Owner會組織這階段的會議並且邀請相關的利益相關者參加。 業務，市場，技術都要做相關的評審。有Product Owner來決定Product Backlog中的哪些功能已經開發完成 ，還要和Scrum Team及相關的利益相關者討論下個Sprint中Product Backlog的優先順序。下個Sprint的目標在這個時候被確定下來。 

會議的下半部分，是由Scrum Master和Scrum Team一起回顧當前的Sprint。團隊評估大家在一起的工作方式，找出好的方式以後繼續發揚，找出需要做的更好的地方，想辦法提升。 

Sprint評審會結束後，新一輪的迭代又繼續開始，迭代會一直繼續，直到開發了足夠多的功能去交付一個產品。 



   燃盡圖（Burn down Charts） 

2    每日站會（Daily Scrum Meeting） 

3    障礙（Impediments） 

4    產品Backlog(Product Backlog) 

5    產品Backlog項（Product Backlog Item） 

6    產品backlog項的工作量（Product Backlog Item Effort） 

7    產品燃盡圖（Product Burn down Chart） 

8    產品負責人的角色 （Product Owner Role） 

9    釋出（Release） 

10   釋出燃盡圖 （Release Burn down Chart） 

11   Scrum角色（Scrum Roles） 

12   Scrum Master角色 

13   Sprint 

14   Sprint Backlog 

15   Sprint燃盡圖（Sprint Burn down Chart） 

16   Sprint 目標 

17   Sprint計劃會議 （Sprint Planning Meeting） 

18   Sprint評審會議（Sprint Review Meeting） 

19   Sprint任務（Sprint Task） 

20   團隊（Team） 

21   團隊成員（Team Member） 

22   速率（Velocity） 



　在這風起雲湧的年代，最為人們津津樂道的國內網際網路三巨頭無疑是騰訊、百度和阿里巴巴，比較湊巧，鄙人曾在其中兩家的研發部門任職。因為已離開Tencent，所以現在可以站在另一個角度冷靜思考，梳理回憶當年的所見所感，讓眾人一睹Tencent研發的崢嶸。 

　　Tencent的產業佈局主要在IM即時通訊、網際網路增值業務、網路遊戲、無線應用、網路媒體、電子商務和廣告業務，QQ註冊使用者超過7億、活躍使用者超過3億，依託QQ、Qzone、遊戲等平臺優勢，單一產品月收入過千萬的比比皆是，像會員、Qzone、寵物、QQShow等，盈利能力超乎想像的強，年Revenue達38億、市值超150億美金，稱其為吸金機器一點不為過，所以股價一直堅挺，在其他科技股紛紛低迷，卻被證券市場成熟的香港投資人持續追捧，這都說明大眾非常看好Tencent的業務前景和盈利能力。 

說完商業表現再說研發背後，Tencent現有員工約4K，其中約一半為研發，研發崗位主要有產品經理、專案經理、開發工程師、UI工程師、測試工程師、運維工程師以及專案管理工程師、SQA和CMO等，開發語言和工具以C++、PHP、Linux和MySQL為主。現有伺服器超1W臺，其中 QQ同時線上約4KW，Qzone同時線上約500W，ITIL可用性指標超99.9%，以其中約300人的事業部門為例，同時研發/運營100個以上子產品，每月釋出30個以上版本。 

　　回想起來，對Tencent研發影響深遠的有兩家公司，一家是Google，它影響的是Tencent的研發文化；另一家是ThoughtWorks，它影響的是Tencent的研發管理。至於Tencent是如何引入併發揚，且聽後續慢慢道來。 

　　Google是網際網路的傳奇，其獨特的開放和創新風格，奠定了它的世界級霸主地位。研究Google的人士都知道Google員工管理的十大黃金定律—— 

　　（1）組織委員會嚴把招聘關 

　　（2）滿足員工的所有需要 

　　（3）拉近員工距離 

　　（4）使合作簡單協調 

　　（5）身體力行，使用自己的產品 

　　（6）鼓勵創新 

　　（7）儘可能統一意見 

　　（8）不作惡 

　　（9）資料決定決策 

　　（10）有效地溝通交流 

　　事實證明這是管理知識型員工的最佳方式。當年Tencent CTO Tony曾帶隊赴美國Google總部，親身感受Google的文化魅力，回來後大加褒獎，立志效仿引進。在鄙人看來，Tencent吸納了Google 文化的精髓主要有四點：寬鬆文化、創新文化、體驗文化和精英文化。 

　　一、寬鬆文化： 

　　Google公司的辦公環境是很多IT白領嚮往的天堂，員工可以帶寵物、穿溜冰鞋上班，酒吧間、健身房、按摩房一應俱全，辦公大樓之間提供滑輪車通行，初來乍到的很多人可能會有錯覺，真不知道是不是進錯了地方。 

　　Tencent的辦公環境也堪稱一流，雖然自己的35層寫字樓在建，現在還租用著飛亞達約八層樓和華強若干層，但在環境裝修和硬體設施上絲毫不吝嗇，包括桌球廳、休閒吧、閱覽室，併入駐咖啡廳，辦公座位裝扮非常個性化，有大幅的海報、卡通玩具、綠色植物，甚至直接在辦公區中間擺上沙發和液晶電視，供看比賽、聽音樂或中午玩PSP。晚上八點提供免費晚餐，加班晚了不用擔心，全天固定40多路大巴通往城市各處。行政祕書MM人數所佔的比例是我經歷的公司中最多的，每個BU都有辦公室建制，她們為員工提供了很多後勤保障並營造氛圍激勵士氣。 

　　當然這是表象，讓員工感受寬鬆與否的除了辦公環境外還包括工作壓力，在Tencent要想表現績效、獲得肯定並非容易，KPI 是把雙刃劍，每季度的強制正態分佈讓不少人無奈，因為晉級的條件是必須連續兩次拿A或S。另外少數中層幹部“技而優則仕”，表現出來“管事不管人”，談工作多、談個人少，對人的內心關懷比較淡漠。 

　　二、創新文化： 

　　Google鼓勵員工動用20%的時間用於自主研究，然後從員工創意中挑選Top20採納應用，給與經費和資源轉化成產品，像Google的桌面搜尋、Orkut等產品都來源於當初員工的創新想法。 

　　Tencent也非常鼓勵創新，認為創新是網際網路技術的靈魂，並寫入了企業文化裡。在組織架構上，Tencent設立有創新中心，專門實驗網際網路上的新生事物和形態，作為新產品初創期的孵化器，成熟後再移交給業務部門運營壯大。在創新渠道上，Tencent每年舉辦創新大賽，由一線員工提出眾多構想，然後相互PK給與重獎。當然現在Tencent暫時還做不到騰出20%的時間出來讓員工自主發揮，因為產品的壓力持續存在著。 

　　三、體驗文化： 

　　Google深信使用者體驗的好壞決定了產品對使用者的粘性，因為同類型的產品實在太多，使用者遷移轉換的成本極低，所以如果自己用著都不爽，就更別說讓使用者來用了。 

　　在Tencent也是如此，從產品人員、設計人員到各級經理都非常在意互動體驗和設計，而對原型PK最多的也是這裡，細到每個流程、每個按鈕、每個圖示甚至每個文字。主要體現在： 

　　（1）使用者體驗小組，邀請客服人員和客戶代表對產品現場反饋，幾乎每個事業部都有。 

　　（2）使用者體驗室，裝有“眼動儀”以分析志願者眼球的轉動是否符合介面引導的初衷，以及長時間停留的區塊。 

　　（3）使用者體驗平臺，陳列所有產品供員工隨時反饋，並提供月度、季度積分排名。 

　　（4）產品內部公測，每個重大產品釋出之前都會發起，因為公司員工中不少就是QQ產品的忠實玩家。 

　　（5）灰度放量釋出，當不確定市場反應或使用者真實需求的時候，先讓部分使用者灰度使用，收集體驗反饋並修改完善後再放量釋出。 

　　四、精英文化： 

　　Google對員工的素質能力要求很高，據說招聘時需要6個人以上集體把關面試，另外在Google博士尤其受歡迎，比例也很高。 

　　Tencent的面試也很嚴格，T3（骨幹級）以上至少要過4關，並經副總裁和CTO面試認可。除了社招以外，Tencent 也非常重視校園招聘，每年都組織到各地高校宣講，“在一個好玩的地方實現自己的夢想”的校園招聘口號讓人印象深刻。另外近年Tencent也加大了吸引高階人才的力度，T5（資深專家級）不斷湧現。 

　　培訓也是Tencent對待員工職業發展的一項制度，培訓區分新人培訓、管理培訓和職業培訓，對管理幹部有潛龍、飛龍和EMBA體系，尤其讓鄙人難忘和受益的是一些精品課程，比如“六頂思考帽”、“高效能人士的七個習慣”、“帶人帶心的領導藝術”等等。 

　　從上述的比較中大家可以看到很多Google文化在Tencent的烙印，這也說明這是一家善於學習、開放包容的企業。就像 Tencent推出的眾多產品一樣，雖然剛開始可能是後來者，但只要放手去做馬上可以像模像樣，甚至超越、打垮先來者，這也是Tencent真正可怕的地方。 

　　ThoughtWorks公司是一家全球IT諮詢公司，它可能不像Google那麼響亮，但有一個名字我們技術人員不可能不知道—— Martin Fowler，堪稱軟體開發領域教父級的人物，他精通OO分析、架構設計和軟體工程，立著頗多，像《UML精粹》、《重構》、《分析模式》、《企業應用架構模式》等不少獲得Jolt大獎的著作都出自他的手筆，而他正是ThoughtWorks公司的首席科學家，同時也是敏捷聯盟的17個始創人之一、以及敏捷宣言的起草人之一。至2008年，ThoughtWorks公司已連續舉辦了三屆敏捷中國大會。 

　　那麼Tencent和ThoughtWorks兩個不同型別的公司又是如何結下淵源的呢，話要從2006年說起，那時 Tencent規模已經開始膨脹，開發模式急需規範和標準化，到底走IPD（整合產品開發）還是Agile（敏捷）的開發路線，公司管理層也在為拿不定主意而犯愁，之後研發管理部開始與ThoughtWorks公司接觸，逐漸將敏捷產品開發引入進來，並正式命名為TAPD（Tencent Agile Product Development）。 

　　接觸是從一次3天15W的培訓開始的，ThoughtWorks派來了一個4人講師團隊，三天的課程讓人印象深刻，由此也誕生了Tencent 日後推行敏捷的第一批種子。後來一想，這次培訓本身就是敏捷的一次真實案例，成員臨時抽調，有來自北京，也有來自西安；課程設定應我們臨時要求即時調整，五天壓縮成三天；講解過程大量應用白紙、小紙條、圖釘和白板等簡單工具；關注學員的心情曲線等。這是一個擁抱變化的團隊，從他們身上折射出溝通、簡單、反饋和勇氣的敏捷價值觀。 

　　簡言之，Tencent的TAPD是吸收了XP+SCRUM+FDD三者特點的並行迭代開發模式，涉及範疇包括敏捷專案管理和敏捷軟體開發。 

　　一、敏捷專案管理： 

　　（1）Iteration 

　　軟體開發模型經歷了從瀑布到螺旋再到敏捷的過程，迭代不是敏捷獨有的創造，無論在RUP還是在MSF中迭代都是其核心特性之一。而在Tencent特別強調的是並行迭代，即多個版本並行，最大程度發揮資源的效率。 

　　Release（釋出）可理解成當實現的產品Feature累積到一定使用者價值時的正式釋出，它是比Iteration更大的概念；Iteration（迭代）是在固定時間內開發Feature的過程，Release一般包括多次Iteration。 

　　（2）TimeBox 

　　TimeBox（時間箱）反映了敏捷開發的節奏，即在固定時間內實現不固定特性的週期，拋開需求定義階段，從設計-實現-測試到部署，在Tencent一般一至兩週時間居多。 

　　（3）Planning Game 

　　對敏捷的一種常見誤解是不要計劃，其實在敏捷的體系中不僅強調計劃，甚至區分Release計劃、Iteration計劃和 Task計劃等多種不同粒度、不同時長的計劃。Planning Game突出的是讓使用者代表參與，由使用者代表評估UserStory/Feature的優先順序，開發人員評估任務的開發時間，由使用者代表+專案經理+核心成員三方共同排序、組合，確定本次迭代計劃需要實現的Feature List。在Tencent使用者代表就是產品經理。 

　　（4）IterationPlanningMeeting 

相關推薦