騰訊敏捷開發及快速迭代

騰訊敏捷開發及快速迭代

http://www.edu-hb.com     2013-6-4 15:23:50     來源： itwriter

從 2006 年開始，騰訊的研發規模開始膨脹，開發模式急需規範和標準化，到底走 IPD（集成產品開發）仍是 Agile（敏捷）的開發路線，公司管理層也在爲拿不定主意而犯愁，以後研發管理部開始與 ThoughtWorks 公司接觸，逐漸將敏捷產品開發引入進來，並正式命名爲 TAPD（Tencent Agile Product Development）。 　　接觸是從一次 3 天 15W 的培訓開始的，ThoughtWorks 派來了一個 4 人講師團隊，由此也誕生了騰訊往後推行敏捷的第一批種子。接着總結騰訊自己是怎麼樣子的，有這樣一個框架以後就搞一些團隊去實踐，經過實踐之後再不斷改進，自己也是一個不斷迭代的過程。 　　整個實施階段大概分紅幾個階段： 試點期：組織不少專題研討和內部培訓，樹立標杆，更大範圍內進行培訓。 推廣期：內部創建一個顧問團隊，開發一些掃盲的課程，不斷的到一些團隊裏面去介紹去培訓，讓你們接受這些理念。 　　一樣騰訊在推廣敏捷的過程當中也面臨一些挑戰： 團隊很是多，每一個團隊特色都不同，好比規模不同，應用方法不同； 產品很是廣，互聯網上全部的產品騰訊幾乎都有，這種多元化的產品它自己產品的研發模式會有一些不同，那麼敏捷、TAPD 怎麼樣去適應這種多元化產品的研發； 敏捷在騰訊也是存在一個過程改進，這樣就會存在一些不適應性，針對這種不適應性應該怎麼樣去作才能更好； 騰訊人員自己的素質也是良莠不齊，每一年校園招聘大概會招聘 1000 多個畢業生，這些畢業生從畢業到能上手工做，他們對敏捷的瞭解，融入到團隊中都須要一個過程； 一些長週期的項目，好比 QQ 客戶端，一個版本的發佈可能要半年到 1 年的時間，像這樣一個產品怎樣去作敏捷開發，也許它就不適合敏捷開發。 　　正是因爲這些挑戰，才孕育出了獨特的騰訊敏捷模式。如下爲收集的一些資料整理： 　　1、總體的框架結構 　　簡言之，騰訊的 TAPD 是吸取了 XP+SCRUM+FDD 三者特色的並行迭代開發模式，涉及範疇包括敏捷項目管理和敏捷軟件開發。 　　一、產品 　　採用 FDD，即產品特性開發驅動的一種模式，騰訊的產品會有一個明確的產品經理這樣一個角色，他會負責整個產品，包括產品的驗證、產品的方向、市場調研、用戶調研等。FDD 模式是一種很是適合產品經理來對產品作一些滾動的要求，騰訊在產品（來自：湖北招生網www.edu-hb.com）設計上引入了相似 FDD 這樣的模式，可是也不徹底是 FDD，只是參考 FDD，全部的開發團隊都是由產品經理所概括出來的產品特性去驅動整個產品的研發。 　　FDD 的核心是面向產品的功能點，但這個功能點是從客戶角度出發的，並非從系統角度出來的。功能點是用一個短句描述出一個業務需求，而這個業務需求的粒度是按開發時間來衡量的（通常不超過兩個星期）。特徵與用例的類似之處是，二者均可以用短句（動賓短語）來描述；二者的不一樣之處在於，用例用 UML 的用例圖來表示，而特徵是用四色原型（類圖）來表示。產品經理這個角色有點 Scrum 的 Product Owner 的味道。但產品特性和 backlog 相差甚遠，由於產品特性只是一個動賓短語，而 backlog 倒是一個完整的故事（story）。 　　二、項目管理過程 　　騰訊採起了 SCRUM，但也不徹底是 SCRUM ，騰訊根據本身的特色去總結的一些實踐，大概的項目管理過程同 SCRUM 的過程比較相似，包括天天的晨會、迭代、timebox、每一個迭代完成的時候會有 showcase、回顧總結等。 　　三、開發實踐 　　參考了不少 XP 的實踐，就 XP 完整的實踐來講會比較理想化，不少東西不必定在實際開發中可以採納，因此騰訊也是採納其中的某些實踐，好比自動化測試和持續集成，經過這樣的實踐就能保證產品有一個快速發佈的過程。 　　2、騰訊的快速迭代過程 　　一個完整的迭代過程包括概念、設計、開發、測試和發佈五個過程。 在概念階段，會採用 FDD 裏面提到的一些好的最佳實踐來支撐到咱們怎麼樣去敏捷的作需求開發，會制定一些產品發佈的計劃，好比產品在將來，某個迭代何時發佈，要發佈哪些產品特性，都是在這個階段作的。 在設計階段，會作產品原型上的設計。對於互聯網產品說更多的是經過快速原型法快速的讓產品在不一樣範圍內去作一些體驗，比方產品在某個迭代的一個小迭代裏面，可能會在一個團隊裏面先去體驗，可能就會採起發佈到公司某一個部門去體驗，或者發佈到整個公司範圍去體驗，它會是一個不斷放大的一個過程。 在開發和測試階段，更多的採起 XP 的一些實踐，包括編碼規範，代碼走讀，（來自：湖北招生考試網edu-hb.com）好比 1 週一次代碼走讀，構建持續集成的環境，包括自動化構建，自動化測試等，會有一些好的測試上的實踐，如全員測試，就是將測試當作不只僅是測試人員的工做，更多的是整個團隊的工做，固然也包括這個產品的其餘同事的工做，經過全員測試來激發你們對產品質量負責。 在發佈階段，騰訊採用的是灰度發佈，同傳統的軟件發佈不同。項目中整個迭代過程就經過相似 SCRUM 模式去管理，若有每日晨會，如何建設團隊氛圍，統一的管理平臺，每次迭代完成時的總結回顧等等，這屬於項目管理的工做。 　　其中分析、設計、開發、測試、發佈這五個過程能夠內部再迭代，並且這五個過程不是分階段開展的，即不是分析完了以後才設計，所有設計完了纔開發，開發結束了才測試，測試經過了才發佈。而是邊分析邊設計——在業務不復雜的狀況下，這是可行的——邊設計邊開發，開發完一個功能就測試一個功能，同時開發下一個功能。 　　還有一些基礎的工做，如代碼管理，版本管理，文檔管理，異地開發管理，這些在騰訊的整個管理體系裏面都包含的，還有會制定一些相關的規範，不過規範不是很強硬的要求每個項目必須執行，更多的由團隊本身選擇，讓他們根據本身團隊的特色、規模去選擇應該採起哪些實踐。 　　2、騰訊是如何作敏捷管理的？ 　　一、故事牆 　　就是白板 story wall，平時工做中不少團隊都會使用，這些團隊會把天天開發的一些產品特性採用 story 的方式天天都在白板裏面展現出來，整個團隊天天都會圍繞這個白板可以清晰的看到整個產品或者整個項目的一個過程，包括整個產品特性的過程。寫在白板上比用 Excel 或者其它工具管理好，由於寫在白板上讓人感受更緊迫、更正式、更一目瞭然，有一種別人在監督、在注視的感受。 　　二、每日晨會 　　每一個團隊天天大概花 15-30 分鐘，回顧昨天作了什麼、昨天有些什麼問題、同時也會介紹每一個人今天計劃作些什麼工做。對 Team 而言這是檢查進度、快速調整很是有效的形式。 　　最先是經過白板的方式去作，就是天天項目經理組織團隊成員對着白板，白板上體現項目的進展狀況，經過會議能夠很明確的知道昨天你們作到什麼樣子，今天你們計劃作什麼，最先的時候每一個成員都是口頭彙報的。實踐一段時間就發現了一些問題： 對於一個 20、30 人的團隊，天天要怎樣作晨會，這是目前遇到的比較大的困惑； 晨會很容易形式化，究竟帶來什麼樣的效率和效果，目前也在經過一些方式去研究，去探討。 有一些形式上的呆板，剛開始作會以爲比較有意思，以爲這跟傳統作法不同，天天這樣作而且作多了就感受很枯燥，這也是面臨一個挑戰。 　　後來騰訊也作了一些改進，好比爲了讓成員的參與程度更強一些，包括形式上會更強一些，如今有些團隊就會採起每一個人輪流主持的方式，剛開始晨會的時候咱們也會經過一些好玩的東西去刺激一下某些東西，可是如今看來的話，感受改進的仍是不是很透。在騰訊內部有一個交流通訊的軟件，有些項目也開始不採用站起來開晨會的方式，以爲站起來效率也不高，就會經過即時通訊軟件天天去交流，最後由一我的去統一輸出，這樣能解決一些分佈式團隊的合做。所謂分佈式團隊就是這個團隊中有些同事在這個大樓，有些同事是在那個大樓，經過這種實時交流的方式能夠解決一些問題。 　　三、規劃遊戲 　　對敏捷的一種常見誤解是不要計劃，其實在敏捷的體系中不只強調計劃，甚至區分 Release 計劃、Iteration 計劃和 Task 計劃等多種不一樣粒度、不一樣時長的計劃。規劃遊戲突出的是讓用戶表明參與，由用戶表明評估用戶故事/特性的（來自：湖北教育信息網www.edu-hb.com）優先級，開發人員評估任務的開發時間，由用戶表明+項目經理+核心成員三方共同排序、組合，肯定本次迭代計劃須要實現的特性列表。在騰訊用戶表明就是產品經理。騰訊特別強調的是並行迭代，即多個版本並行，最大程度發揮資源的效率。Release（發佈）可理解成當實現的產品特性累積到必定用戶價值時的正式發佈，它是比迭代更大的概念；迭代是在固定時間內開發特性的過程，Release 通常包括屢次迭代。 　　四、時間盒 　　在騰訊的產品研發中，產品的每個迭代都有一個明確的時間盒。在每一次迭代開始的時候會召開一次 IPM 會議，即本次迭代的計劃會議，會議中團隊中的全部成員包括產品人員、開發人員、項目經理、總監、部門領導，一塊兒去敲定本次迭代要完成的任務，一旦任務敲定下來，本次迭代就會嚴格按照這個去落實執行。TimeBox 反映了敏捷開發的節奏，即在固定時間內實現不固定特性的週期，拋開需求定義階段，從設計-實現-測試到部署，在騰訊通常一至兩週時間居多。 　　五、產品演示 　　提交測試前由開發人員演示實現的功能，產品經理到場 Review 是否符合當初的設想，避免接近發佈時才反饋。 　　六、迭代總結 　　在每個產品發佈的時候都會有一個總結。具體的作法是，把作得好的、很差的總結出來，作得好的在下一次迭代發揚光大，作得很差的在下一次迭代就要注意改進。這樣的總結是要求項目的全部成員都必須參加，包括項目的開發人員、測試人員、QA、項目經理、產品經理等，每一個人都要去去總結他在上一個迭代中碰到了什麼問題，經過便籤紙的方式貼出來，項目經理實際上能夠當作是 Scrum Master ，包括站起來總結這樣一些東西，包括咱們下一次迭代繼續發揚什麼，必需要注意什麼東西，最後就會得出一個 excel 的文檔，包括上一個迭代中出的問題，具體的解決辦法，都會有 　　七、自運轉團隊 　　早期的項目，爲了能提升效率，項目經理但願每一個角色都能盡心盡力的提高本身的效率，因而本身承擔起來大量溝通和推動的工做，那個時候的都在被 PM 推着走，一旦 PM 休假，項目基本沒有什麼產出，當時去了之後，發現問題很嚴重，團隊的主動性必須被調動起來才行。 　　自運轉團隊，是將需求開發過程詳細劃分紅開發的各環節，並明確每一個環節的負責人，由該負責人來驅動上下游的負責人，而再也不由項目經理來鏈接各個環節，再配合上高效的項目協助工具平臺，實現開發過程自運轉。這時項目經理則由指揮者變成服務者，觀察環節之間產生的瓶頸，並及時採起措施掃除障礙。 　　3、騰訊是如何進行敏捷開發的？ 　　一、用戶研究 　　如何增強用戶的參與度，這是一種成本比較低的用戶研究方法。經過抓取一些用戶數據作分析，分析用戶在這個產品上整個體驗的過程是怎樣的，經過後臺的數據能夠看到整個活動的曲線，同時 CE 也能夠經過一些科學的手段去保證，包括市場調研、用戶研究、數據挖掘、產品體會等，這就是經過一些對用戶反饋、用戶觀察的工具去配合去對用戶作研究。好比 QQ 拍拍的一個用戶的研究，咱們能夠到現場去作的一個調研，常常會由產品經理和用戶研究人員到用戶的實際辦公地點進行調研，作一天的反饋，經過觀察用戶一天是如何使用你的產品，配合一些相關的工具去科學的分析。由於互聯網是很是強調同用戶的這種反饋的，騰訊有本身內部的一個 CE 反饋平臺，在這個平臺上能夠收集到全部用戶的反饋，產品經理能夠天天都會看到他所負責的產品有哪些反饋，包括內部的、外部的，而後他就能夠根據這些反饋對產品進行一些快速的調整，包括開發一些什麼樣的產品特性，內部同事也能夠踊躍的在平臺上反饋，內部同事自己就是 QQ 用戶。 　　二、故事卡片/故事牆/特徵列表 　　StoryCard 是 XP 中推薦的需求定義方法，要求符合 Invest 和 Moscow 原則；故事牆則用於跟蹤故事卡片的變化狀態，而特徵列表是 Tencent 一直沿用的需求表達形式，在騰訊的 TAPD 工具中已經實現了相似 ThoughtWorks 的 Mingle 的故事卡片管理功能，對於需求跟蹤而言這是不錯的方法，一目瞭然。 　　三、結對編程 　　理論上結對編程能夠提升代碼的質量，並且並不會下降開發效率，但騰訊的業務繁忙，資源上不容許兩人結對。可是在一些團隊裏面仍是一直在嘗試着作結對編程的工做。一個在編寫程序，旁邊還有一我的，同時記錄編寫過程、編寫思路、碰到的問題、本身的想法，編寫完之後一段時間他們會交換一下，就是互相交換着進行編程，這是一個結對編程的一個過程。 　　四、測試驅動 　　「測試驅動開發」在騰訊執行地並不太好，騰訊的產品以 Web 形式居多、業務邏輯相對簡單，C++下的單元測試有些力不從心。相反自動化測試在騰訊比較盛行，（來自：湖北招生考試網w ww.edu-h b.c om）由於有測試部門專門的自動化測試 Team 在推進，並且連接的是正式生產環境，能夠即時反映產品當前的狀態。 　　五、持續集成 持續集成能夠下降發佈前集成階段的難度與成本，騰訊的自動化構建系統推行的比較早，覆蓋了大多數產品，並且正在朝自動化構建-自動化測試-自動化發佈三者協同的目標邁進。做爲加快產品的發佈的能力，持續集成在如下幾個方面做用明顯。 自動編譯輸出報告，維護代碼可運行，及時暴露風險，下降集成成本。 Dailybuild 日構建系統，讓產品經理、測試人員能夠儘早進行體驗和測試。 做爲一個自動化系統，利用靜態代碼檢查、單元測試報告等手段爲團隊提供報告，促進編碼質量不斷獲得重視，下降缺陷解決成本、縮短解決時間。 　　六、灰度發佈 　　灰度發佈是騰訊的又一創新，它將產品試用擴大到海量用戶一端，在小範圍及時吸收用戶反饋，分析用戶行爲和喜愛，持續修正本身產品的功能體驗。在互聯網行業，灰度發佈已經成爲最重要的發佈控制手段。有時咱們但願經過向小部分用戶開發新功能，讓他們先來體驗新功能、新特性。經過用戶反饋、數據運營的手段及早得到反饋，及時改進。以此方式，既能夠下降發佈風險，也能夠提高發布頻率，加快發佈節奏。 　　簡單說就是，將一項業務不是一下發布給全部用戶，而是分批分期的發佈，目的有兩個方面，一是減輕服務器壓力，二是期間能夠在小範圍收集到用戶的反饋，若是業務出現問題，不會讓大範圍用戶受到影響。隨着經驗的累計，咱們有了許多種灰度策略和方法，灰度也有了更多的應用，甚至引入到了測試環境，即選擇一些熱心用戶，將功能首先發布給他們，經過他們的使用，來幫助進行一些現網測試，這使得一些難於模擬的測試場景變得簡單，測試人員的壓力大大下降；更重要的用戶是最好的測試人員，測試結果更加真實；同時他們也享受到了優先體驗的特權，可謂一舉三得。發佈的時候也有策略，好比發佈時如何放量，對用戶有些什麼樣的實驗，技術上怎樣作一些後臺開關，運營上怎樣跟進，怎樣保證 4 小時人員的留守，發佈完後怎樣收集用戶反饋等等都會有一些統一的規則。 　　七、發佈汽車 　　過於頻繁的發佈會打破團隊節奏，有效的發佈管理是必不可少的，根據業務特色，咱們一般會採用三種發佈模式，咱們管它叫「發佈汽車」。 班車模式：像班車同樣，固定週期進行，好比每兩週發佈一次，這周比較適合特性規劃比較好的產品，好比 QQ 客戶端基本每月都會發佈一個版本。 的士模式：與 QQ 客戶端不一樣，QQServer 做爲一個平臺，它的需求來源很是多，所以它採用多線並行的方式，根據需求來源分紅十多個子項目，根據每一個子項目若是想要發佈，就像打的同樣隨叫隨發佈。他的好處是快，可是協調發布的成本是比較高的，比做班車花錢要多。 警車模式：顧名思義能夠不按法規來開車，所以對於一下特別緊急的需求或運營事件，必須採用警車這種模式，緊急發佈，但這樣作成本更高，會把交通秩序搞亂，開發節奏打破。 　　八、重構 　　好的代碼不是設計出來的，而是重構出來的。 　　4、總結 　　固然流程和開發方法肯定了還遠遠不夠，更難的是如何將它推進落地。首先騰訊組織開發了承載敏捷思想的 TAPD 項目管理工具，它相似 ThoughtWorks 的 Mingle；而後推出了敏捷能力模型，相似 CMM 成熟度模型同樣對 Team 評級加以引導；同時還推出了敏捷指數排行榜造成競爭，營造你追我趕的聲勢氛圍。