騰訊敏捷開發及快速迭代

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

        接觸是從一次 3 天 15W 的培訓開始的，ThoughtWorks 派來了一個 4 人講師團隊，由此也誕生了騰訊日后推行敏捷的第一批種子。接著總結騰訊本身是怎么樣子的，有這樣一個框架之后就搞一些團隊去實踐，通過實踐以后再不斷改 進，本身也是一個不斷迭代的過程。

        整個實施階段大概分成幾個階段：

• 試點期：組織很多專題研討和內部培訓，樹立標桿，更大范圍內進行培訓。
• 推廣期：內部建立一個顧問團隊，開發一些掃盲的課程，不斷的到一些團隊里面去介紹去培訓，讓大家接受這些理念。

        同樣騰訊在推廣敏捷的過程中也面臨一些挑戰：

1. 團隊非常多，每個團隊特點都不一樣，比如規模不一樣，應用方法不一樣；
2. 產品非常廣，互聯網上所有的產品騰訊幾乎都有，這種多元化的產品它本身產品的研發模式會有一些不一樣，那么敏捷、TAPD 怎么樣去適應這種多元化產品的研發；
3. 敏捷在騰訊也是存在一個過程改進，這樣就會存在一些不適應性，針對這種不適應性應該怎么樣去做才能更好；
4. 騰訊人員本身的素質也是參差不齊，每年校園招聘大概會招聘 1000 多個畢業生，這些畢業生從畢業到能上手工作，他們對敏捷的了解，融入到團隊中都需要一個過程；
5. 一些長周期的項目，比如 QQ 客戶端，一個版本的發布可能要半年到 1 年的時間，像這樣一個產品怎樣去做敏捷開發，也許它就不適合敏捷開發。

        正是由于這些挑戰，才孕育出了獨特的騰訊敏捷模式。以下為收集的一些資料整理：

        一、整體的框架結構

        簡言之，騰訊的 TAPD 是吸收了 XP+SCRUM+FDD 三者特點的并行迭代開發模式，涉及范疇包括敏捷項目管理和敏捷軟件開發。

        1、產品

        采用 FDD，即產品特性開發驅動的一種模式，騰訊的產品會有一個明確的產品經理這樣一個角色，他會負責整個產品，包括產品的驗證、產品的方向、市場調研、用戶 調研等。FDD 模式是一種非常適合產品經理來對產品做一些滾動的要求，騰訊在產品設計上引入了類似 FDD 這樣的模式，但是也不完全是 FDD，只是參考 FDD，所有的開發團隊都是由產品經理所歸納出來的產品特性去驅動整個產品的研發。

        FDD 的核心是面向產品的功能點，但這個功能點是從客戶角度出發的，并不是從系統角度出來的。功能點是用一個短句描述出一個業務需求，而這個業務需求的粒度是按 開發時間來衡量的（一般不超過兩個星期）。特征與用例的相似之處是，兩者都可以用短句（動賓短語）來描述；兩者的不同之處在于，用例用 UML 的用例圖來表示，而特征是用四色原型（類圖）來表示。產品經理這個角色有點 Scrum 的 Product Owner 的味道。但產品特性和 backlog 相差甚遠，因為產品特性只是一個動賓短語，而 backlog 卻是一個完整的故事（story）。

        2、項目管理過程

        騰訊采取了 SCRUM，但也不完全是 SCRUM ，騰訊根據自己的特點去總結的一些實踐，大概的項目管理過程同 SCRUM 的過程比較類似，包括每天的晨會、迭代、timebox、每個迭代完成的時候會有 showcase、回顧總結等。

        3、開發實踐

        參考了很多 XP 的實踐，就 XP 完整的實踐來說會比較理想化，很多東西不一定在實際開發中能夠采納，所以騰訊也是采納其中的某些實踐，比如自動化測試和持續集成，通過這樣的實踐就能保證產品有一個快速發布的過程。

        二、騰訊的快速迭代過程

        一個完整的迭代過程包括概念、設計、開發、測試和發布五個過程。

1. 在概念階段，會采用 FDD 里面提到的一些好的最佳實踐來支撐到我們怎么樣去敏捷的做需求開發，會制定一些產品發布的計劃，比如產品在未來，某個迭代什么時候發布，要發布哪些產品特性，都是在這個階段做的。
2. 在設計階段，會做產品原型上的設計。對于互聯網產品說更多的是通過快速原型法快速的讓產品在不同范圍內去做一些體驗，比方產品在某個迭代的一個小 迭代里面，可能會在一個團隊里面先去體驗，可能就會采取發布到公司某一個部門去體驗，或者發布到整個公司范圍去體驗，它會是一個不斷放大的一個過程。
3. 在開發和測試階段，更多的采取 XP 的一些實踐，包括編碼規范，代碼走讀，比如 1 周一次代碼走讀，構建持續集成的環境，包括自動化構建，自動化測試等，會有一些好的測試上的實踐，如全員測試，就是將測試看成不僅僅是測試人員的工作，更 多的是整個團隊的工作，當然也包括這個產品的其他同事的工作，通過全員測試來激發大家對產品質量負責。
4. 在發布階段，騰訊采用的是灰度發布，同傳統的軟件發布不一樣。項目中整個迭代過程就通過類似 SCRUM 模式去管理，如有每日晨會，如何建設團隊氛圍，統一的管理平臺，每次迭代完成時的總結回顧等等，這屬于項目管理的工作。

        其中分析、設計、開發、測試、發布這五個過程可以內部再迭代，而且這五個過程不是分階段開展的，即不是分析完了之后才設計，全部設計完了才開 發，開發結束了才測試，測試通過了才發布。而是邊分析邊設計——在業務不復雜的情況下，這是可行的——邊設計邊開發，開發完一個功能就測試一個功能，同時 開發下一個功能。

        還有一些基礎的工作，如代碼管理，版本管理，文檔管理，異地開發管理，這些在騰訊的整個管理體系里面都包含的，還有會制定一些相關的規范，不過規范不是很強硬的要求每一個項目必須執行，更多的由團隊自己選擇，讓他們根據自己團隊的特點、規模去選擇應該采取哪些實踐。

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

        1、故事墻

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

        2、每日晨會

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

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

1. 對于一個 20、30 人的團隊，每天要怎樣做晨會，這是目前遇到的比較大的困惑；
2. 晨會很容易形式化，究竟帶來什么樣的效率和效果，目前也在通過一些方式去研究，去探討。
3. 有一些形式上的呆板，剛開始做會覺得比較有意思，覺得這跟傳統做法不一樣，每天這樣做并且做多了就感覺很枯燥，這也是面臨一個挑戰。

        后來騰訊也做了一些改進，比如為了讓成員的參與程度更強一些，包括形式上會更強一些，現在有些團隊就會采取每個人輪流主持的方式，剛開始晨會的 時候我們也會通過一些好玩的東西去刺激一下某些東西，但是現在看來的話，感覺改進的還是不是很透。在騰訊內部有一個交流通信的軟件，有些項目也開始不采用 站起來開晨會的方式，覺得站起來效率也不高，就會通過即時通信軟件每天去交流，最后由一個人去統一輸出，這樣能解決一些分布式團隊的合作。所謂分布式團隊 就是這個團隊中有些同事在這個大樓，有些同事是在那個大樓，通過這種實時交流的方式可以解決一些問題。

        3、規劃游戲

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

        4、時間盒

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

        5、產品演示

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

        6、迭代總結

        在每一個產品發布的時候都會有一個總結。具體的做法是，把做得好的、不好的總結出來，做得好的在下一次迭代發揚光大，做得不好的在下一次迭代就 要注意改進。這樣的總結是要求項目的所有成員都必須參加，包括項目的開發人員、測試人員、QA、項目經理、產品經理等，每個人都要去去總結他在上一個迭代 中碰到了什么問題，通過便簽紙的方式貼出來，項目經理實際上可以看成是 Scrum Master
，包括站起來總結這樣一些東西，包括我們下一次迭代繼續發揚什么，必須要注意什么東西，最后就會得出一個 excel 的文檔，包括上一個迭代中出的問題，具體的解決辦法，都會有

        7、自運轉團隊

        早期的項目，為了能提高效率，項目經理希望每個角色都能全力以赴的提升自己的效率，于是自己承擔起來大量溝通和推進的工作，那個時候的都在被 PM 推著走，一旦 PM 休假，項目基本沒有什么產出，當時去了以后，發現問題很嚴重，團隊的主動性必須被調動起來才行。

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

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

        1、用戶研究

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

        2、故事卡片/故事墻/特征列表

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

        3、結對編程

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

        4、測試驅動

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

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

1. 自動編譯輸出報告，維護代碼可運行，及時暴露風險，降低集成成本。
2. Dailybuild 日構建系統，讓產品經理、測試人員可以盡早進行體驗和測試。
3. 作為一個自動化系統，利用靜態代碼檢查、單元測試報告等手段為團隊提供報告，促進編碼質量不斷得到重視，降低缺陷解決成本、縮短解決時間。

        6、灰度發布

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

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

        7、發布汽車

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

• 班車模式：像班車一樣，固定周期進行，比如每兩周發布一次，這周比較適合特性規劃比較好的產品，比如 QQ 客戶端基本每個月都會發布一個版本。
• 的士模式：與 QQ 客戶端不同，QQServer 作為一個平臺，它的需求來源非常多，因此它采用多線并行的方式，根據需求來源分成十多個子項目，根據每個子項目如果想要發布，就像打的一樣隨叫隨發布。他的好處是快，但是協調發布的成本是比較高的，比作班車花錢要多。
• 警車模式：顧名思義可以不按法規來開車，因此對于一下特別緊急的需求或運營事件，必須采用警車這種模式，緊急發布，但這樣做成本更高，會把交通秩序搞亂，開發節奏打破。

        8、重構

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

        四、總結

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