今天給大家奉上騰訊的實踐，一起看看獨具特色的騰訊敏捷是如何實施的！

該案例轉自於360doc個人圖書館

01

“鵝廠”面臨的挑戰

從2006年開始，騰訊的研發規模開始膨脹，開發模式急需規範和標準化，到底走IPD(整合產品開發)還是Agile(敏捷)的開發路線，公司管理層也在為拿不定主意而犯愁，之後研發管理部開始與ThoughtWorks公司接觸，逐漸將敏捷產品開發引入進來，並正式命名為TAPD( Tencent Agile Product Development)。

實施階段

1. 試點期：組織很多專題研討和內部培訓，樹立標杆，更大範圍內進行培訓

2. 推廣期：內部建立一個顧問團隊，開發一些掃盲的課程，不斷地進入到團隊進行培訓，讓大家瞭解，接收這些理念。

面臨挑戰

1. 團隊非常多，每個團隊特點都不一樣，比如規模不一樣，應用方法不一樣；

2. 產品非常廣，網際網路上所有的產品騰訊幾乎都有，這種多元化的產品它本身產品的研發模式會有一些不一樣，那麼敏捷、TAPD怎麼樣去適應這種多元化產品的研發；

3. 敏捷在騰訊也是存在一個過程改進，這樣就會存在一些不適應性，針對這種不適應性應該怎麼樣去做才能更好；

4. 騰訊人員本身的素質參差不齊，每年校園招聘大概會招聘1000多個畢業生，這些畢業生從畢業到能上手工作，他們對敏捷的瞭解，到融入團隊都需要一個過程；

5. 一些長週期的專案，比如QQ客戶端，一個版本的釋出可能要半年到1年的時間，像這樣一個產品怎樣去做敏捷開發呢，或許它並不適合敏捷開發。

也正是由於這些挑戰，才孕育出了獨特的騰訊敏捷模式！

從整體框架來看，騰訊的TAPD是吸收了XP+Scrum+FDD三者特點的並行迭代開發模式:XP完整的實踐會比較理想化，很多東西不一定在實際開發中能夠採納，所以騰訊只是採納其中的某些，比如自動化測試和持續整合，目的在於保證產品有一個快速釋出的過程；騰訊採取的Scrum不完全是Scrum，與騰訊本身的特點總結出的實踐相結合，專案管理過程同Scrum類似；FDD即產品特性開發驅動的一種模式，騰訊的產品會有一個明確的產品經理這樣一個角色，他會負責整個產品，包括產品的驗證，產品的方向，市場調研，使用者調研等。

02

騰訊的快速迭代過程

一個完整的迭代過程包括概念，設計，開發，測試和釋出五個過程

03

騰訊是如何做敏捷管理的？

1、故事牆

就是白板story wall，平時工作中很多團隊都會使用，這些團隊會把每天開發的一些產品特性採用story的方式每天都在白板裡面展示出來，整個團隊每天都會圍繞這個白 板能夠清晰的看到整個產品或者整個專案的一個過程，包括整個產品特性的過程。寫在白板上比用Excel或者其它工具管理好，因為寫在白板上讓人感覺更緊 迫、更正式、更一目瞭然，有一種別人在監督、在注視的感覺。

2、每日晨會

每個團隊每天大概花15-30分鐘，回顧昨天做了什麼、昨天有些什麼問題、同時也會介紹每個人今天計劃做些什麼工作。對Team而言這是檢查進度、快速調整非常有效的形式。

最早是通過白板的方式去做，就是每天專案經理組織團隊成員對著白板，白板上體現專案的進展情況，通過會議可以很明確的知道昨天大家做到什麼樣子，今天大家計劃做什麼，最早的時候每個成員都是口頭彙報的。實踐一段時間就發現了一些問題：

• 對於一個20、30人的團隊，每天要怎樣做晨會，這是目前遇到的比較大的困惑；

• 晨會很容易形式化，究竟帶來什麼樣的效率和效果，目前也在通過一些方式去研究，去探討。

• 有一些形式上的呆板，剛開始做會覺得比較有意思，覺得這跟傳統做法不一樣，每天這樣做並且做多了就感覺很枯燥，這也是面臨一個挑戰。

後來騰訊也做了一些改進，比如為了讓成員的參與程度更強一些，有些團隊就會採取每個人輪流主持的方式，剛開始晨會的時候我們也會通過一些好玩的東西去刺激，激發一些靈感，現在看來的話，改進的不是很透徹。在騰訊內部有一個交流通訊的軟體，有些專案不採用站起來開晨會的方式，覺得站起來效率也不高，他們就會通過即時通訊軟體每天去交流，最後由一個人統一輸出，這樣能解決一些分散式團隊的合作。（所謂分散式團隊即這個團隊中有些同事在這棟大樓，有些同事在另外一棟大樓，通過這種實時交流的方式也可以解決一些問題。）

3、規劃遊戲

對敏捷的一種常見誤解：不要計劃。事實上，在敏捷的體系中不僅強調計劃，甚至區分Release計劃、Iteration計劃和Task計劃等多種不同粒度，不同時長的計劃。規劃遊戲突出的是讓使用者代表參與，由使用者代表評估使用者故事/特性的優先順序，開發人員評估任務的開發時間，由使用者代表+專案經理+核心成員三方共同排序、組合，確定本次迭代計劃需要實現的特性列表。在騰訊使用者代表就是產品經理。騰訊特別強調的是並行迭代，即多個版本並行，最大程度發揮資源的效率。Release(釋出)可理解成當實現的產品特性累積到一定使用者價值時的正式釋出，它是比迭代更大的概念；迭代是在固定時間內開發特性的過 程，Release一般包括多次迭代。

4、時間盒

在騰訊的產品研發中，產品的每一個迭代都有一個明確的時間盒。在每一次迭代開始的時候會召開一次IPM會議，即本次迭代的計劃會議，團隊中的所有成員包括產品人員、開發人員、專案經理、總監、部門領導，一起去敲定本次迭代要完成的任務，一旦任務敲定下來，本次迭代就會嚴格按照這個去落實執行。 TimeBox反映了敏捷開發的節奏，即在固定時間內實現不固定特性的週期，拋開需求定義階段，從設計-實現-測試到部署，一般來說，在騰訊一至兩週時間居多。

5、產品演示

提交測試前由開發人員演示實現的功能，產品經理到場Review是否符合當初的設想，避免接近釋出時才反饋。

6、迭代總結

在每一個產品釋出的時候都會有一個總結。具體的做法是：把做得好的、不好的總結出來，做得好的在下一個迭代發揚光大，做得不好的在下一個迭代需要注意改進。這樣的總結要求專案的所有成員都必須參加，包括專案的開發人員、測試人員、QA、專案經理、產品經理等，每個人都要去總結他在上一個迭代中碰到了什麼問題，通過便籤紙的方式貼出來，在這裡，專案經理可以看作是Scrum Master。最後會得出一個excel的文件，包括上一個迭代中出的問題，具體的解決辦法等。

7、自運轉團隊

在早期的專案中，為了能提高效率，PM（專案經理）希望每個角色都能全力以赴地提升自己的效率，於是自己承擔起來大量溝通和推進的工作，那個時候團隊在被PM推著走，一旦PM休假，專案基本沒什麼產出，所以發現到這個問題以後，大家意識到團隊的主動性必須被調動起來。

自運轉團隊，是將需求開發過程詳細劃分成開發的各環節，並明確每個環節的負責人，由該負責人來驅動上下游的負責人，而不再由專案經理來連線各個環 節，再配合高效的專案協助工具平臺，一起實現開發過程自運轉。這時專案經理則由指揮者變成服務者，他需要觀察環節之間產生的瓶頸，並及時採取措施掃除障礙。

04

騰訊是如何進行敏捷開發的？

1、使用者研究

如何加強使用者的參與度，這是一種成本比較低的使用者研究方法。通過抓取一些使用者資料做分析，分析使用者在這個產品上整個體驗的過程是怎樣的。通過後臺的資料可以看到整個活動的曲線，同時CE也可以通過一些科學的手段去保證，包括市場調研、使用者研究、資料探勘、產品體會等，即通過一些對使用者反饋、使用者觀察的工具一起配合做研究。比如QQ拍拍的一個使用者的研究，我們到現場去做調研，通常，會由產品經理和使用者研究人員到使用者的實際辦公地點進行一天的調研，通過觀察使用者如何使用你的產品，配合一些相關的工具去做科學的分析。因為網際網路非常強呼叫戶反饋，騰訊有自己內部的一個CE反饋平臺，在這個平臺上可以收集到所有使用者的反饋，產品經理可以看到他所負責的產品有哪些反饋，包括內部的、外部的，然後根據這些反饋對產品進行快速的調整，包括開發一些產品特性，內部同事也可以踴躍地在平臺上反饋，因為內部同事本身就是QQ使用者。

2、故事卡片/故事牆/特徵列表

StoryCard是XP中推薦的需求定義方法，要求符合Invest和Moscow原則；故事牆則用於跟蹤故事卡片的變化狀態，而特徵列表是Tencent一直沿用的需求表達形式，在騰訊的TAPD工具中已經實現了類似ThoughtWorks 的Mingle的故事卡片管理功能，對於需求跟蹤而言這是不錯的方法，一目瞭然。

3、結對程式設計

理論上結對程式設計可以提高程式碼的質量，而且不會降低開發效率，但騰訊的業務繁忙，資源上不允許兩人結對。但是在一些團隊裡面還是一直在嘗試著做結對 程式設計的工作。一個在編寫程式，旁邊還有一個人同時記錄編寫過程、編寫思路、碰到的問題、自己的想法，編寫完以後一段時間他們會互相交換著進行程式設計，這是結對程式設計的一個過程。

4、測試驅動

“測試驅動開發”在騰訊執行地並不太好，騰訊的產品以Web形式居多、業務邏輯相對簡單，C++下的單元測試有些力不從心。相反自動化測試在騰訊比較盛行，因為有測試部門專門的自動化測試Team在推動，而且連結的是正式生產環境，可以即時反映產品當前的狀態。

5、持續整合

持續整合可以降低釋出前整合階段的難度與成本，騰訊的自動化構建系統推行得比較早，覆蓋了大多數產品，而且正在朝自動化構建-自動化測試-自動化釋出三者協同的目標邁進。作用於加快產品釋出的能力，持續整合在以下幾個方面作用明顯。

• 自動編譯輸出報告，維護程式碼可執行，及時暴露風險，降低整合成本。

• Dailybuild日構建系統，讓產品經理、測試人員可以儘早進行體驗和測試。

• 作為一個自動化系統，利用靜態程式碼檢查、單元測試報告等手段為團隊提供報告，促進編碼質量不斷得到重視，降低缺陷解決成本、縮短解決時間。

6、灰度釋出

灰度釋出是騰訊的又一創新，它將產品試用擴大到海量使用者一端，在小範圍及時吸取使用者反饋，分析使用者行為和喜好，持續修正自己產品的功能體驗。在網際網路行業，灰度釋出已經成為最重要的釋出控制手段。有時我們希望通過向小部分使用者開發新功能，讓他們先來體驗新功能、新特性。通過使用者反饋、資料運營的手段及早獲得反饋，及時改進。以此方式，既可以降低釋出風險，也可以提升釋出頻率，加快釋出節奏。

簡單說，即一項業務不是一下發布給所有使用者，而是分批分期地釋出。這樣做目的有兩方面，一是減輕伺服器壓力，二是在此期間可以在小範圍收集到使用者的反饋，如果業務出現問題，不會讓大範圍使用者受到影響。隨著經驗的累計，我們有了許多種灰度策略和方法，灰度也有了更多的應用，甚至引入到了測試環境，即選擇一些熱心使用者，將功能首先發布給他們，通過他們的使用，來幫助進行一些現網測試，這使得一些難於模擬的測試場景變得簡單，測試人員的壓力大大降低；更重要是，使用者成為最好的測試人員，測試結果更加真實；同時他們也享受到了優先體驗的特權，可謂一舉三得。釋出的時候也有策略，比如釋出時如何放量，對使用者有些什麼樣的實驗，技術上怎樣做一些後臺開關，運營上怎樣跟進，怎樣保證4小時人員的留守，釋出完後怎樣收集使用者反饋等等都會有一些統一的規則。

7、釋出汽車

過於頻繁的釋出會打破團隊節奏，有效的釋出管理是必不可少的，根據業務特點，我們通常會採用三種釋出模式，我們管它叫“釋出汽車”。

班車模式：像班車一樣，固定週期進行，比如每兩週釋出一次，這周比較適合特性規劃比較好的產品，比如QQ客戶端基本每個月都會發佈一個版本。

的士模式：與QQ客戶端不同，QQServer作為一個平臺，它的需求來源非常多，因此它採用多線並行的方式，根據需求來源分成十多個子專案，如果想要釋出，就像打的一樣隨叫隨釋出。他的好處是快，但是協調發布的成本是比較高的，比做班車花費更多。

警車模式：顧名思義可以不按法規來開車，因此對於特別緊急的需求或運營事件，必須採用警車這種模式，緊急釋出，但這樣做成本更高，會把交通秩序搞亂，開發節奏打破。

8、重構

好的程式碼不是設計出來的，而是重構出來的。

補充

流程和開發方法確定了還遠遠不夠，更難的是如何將它推動落地。騰訊組織開發了承載敏捷思想的TAPD專案管理工具，它類似 ThoughtWorks的Mingle；然後推出了敏捷能力模型，類似CMM成熟度模型一樣對Team評級加以引導；還推出了敏捷指數排行榜形成競 爭，營造你追我趕的聲勢氛圍。

原文連結：

http://www.360doc.com/content/14/0605/00/8504707_383731281.shtml