在這些產(chǎn)品背后是騰訊15,000~16,000名技術(shù)人員，這里包括的不只是開發(fā)，也包含測試和運維。而產(chǎn)品員工大約是6000左右，包含了所有的產(chǎn)品經(jīng)理、運營、游戲策劃和項目經(jīng)理。合計總?cè)藬?shù)大約22,000左右。 

從研發(fā)效率來說，單位人員所提供的產(chǎn)品能力，體現(xiàn)了整個集團的人均研發(fā)效率。騰訊用數(shù)量并不太多的員工人數(shù)，維持了如此多款不同產(chǎn)品，我把其中研發(fā)效率的關(guān)鍵因素歸結(jié)為4點： 

1.雇傭杰出的研發(fā)和產(chǎn)品人員 

2.由下而上自組織的敏捷 

3.自動化的研發(fā)工具體系 

4.科學(xué)高效的質(zhì)量控制能力 

今天的分享著重來看第二點，也就是“敏捷”對于騰訊集團這樣的大型企業(yè)代表著什么。 

研發(fā)的現(xiàn)狀

研發(fā)過程中主要有兩種角色，分別是產(chǎn)品和研發(fā)。產(chǎn)品經(jīng)理把需求排進需求池，和研發(fā)勾兌好，經(jīng)過線上線下若干輪pk，劃分優(yōu)先級排進迭代，研發(fā)團隊經(jīng)過內(nèi)部溝通，做好架構(gòu)設(shè)計，然后把需求拆分給不同的人來實現(xiàn)，也就是任務(wù)分配。之后，開發(fā)開始寫代碼，寫代碼的過程中又需要各種各樣的溝通，比如有些依賴或者技術(shù)接口，再比如產(chǎn)品需求發(fā)現(xiàn)有些之前沒想到的疑問回去勾兌。等到功能大致開發(fā)好，測試開始介入，這個時候產(chǎn)品、開發(fā)和測試坐在一起，又要核對測試的需求，在測試過程當中還要勾兌開發(fā)環(huán)境。最后，在測試當中發(fā)現(xiàn)的問題，又要和產(chǎn)品和研發(fā)一起識別和跟蹤。 

再進一步，從迭代規(guī)劃開始，研發(fā)團隊先要對根據(jù)產(chǎn)品節(jié)奏，對自己的版本做規(guī)劃。當然不同形態(tài)的產(chǎn)品，規(guī)劃出的結(jié)果是大相徑庭的，如果是互聯(lián)網(wǎng)產(chǎn)品，那么規(guī)劃往往與發(fā)布節(jié)奏有關(guān)，如果是交付給用戶的產(chǎn)品，比如說騰訊云TCE和TSTACK，這些產(chǎn)品要對不同的客戶有不同定制，版本規(guī)劃肯定又會和客戶交付有關(guān)。在有版本規(guī)劃之后，研發(fā)leader開始分活兒，那么分得任務(wù)又開始與分支規(guī)劃有關(guān)，是要主干開發(fā)呢？還是要特性分支開發(fā)呢？還是要一個人一個分支開發(fā)能？那么怎么規(guī)劃？此時研發(fā)Leader有責任規(guī)范研發(fā)團隊的作為，我們要改分支開發(fā)模式呢還是如何？之后提交、到合流、到缺陷反饋時候的自動化檢測，最后再到發(fā)布交付都要怎麼做？仔細想想看，每個團隊在跑熟流程前，還有遇到問題解決問題的時候都要經(jīng)過大量的溝通。這些溝通只能在產(chǎn)品團隊、研發(fā)團隊、質(zhì)量團隊和CMO（也就是配置管理員）中內(nèi)部消化。 

（現(xiàn)代研發(fā)復(fù)雜的控制節(jié)點） 

回想一下整個過程，即便沒有講細，也講了如此之多的步驟。卻還沒談怎么寫代碼，反而把時間在規(guī)范、交流、溝通中浪費掉了。 

回顧下互聯(lián)網(wǎng)時代早期，需求、迭代、IPM、Scrum、缺陷反饋等等這些概念，其實并不流行。例如騰訊在Pony、Tony還寫代碼的時代，寫第一版QQ時，也未必真的了解IPM是什么。舉一反三，在一個行業(yè)發(fā)展的初期，往往是研發(fā)效率最高的時刻。例如前兩年的AI圍棋，團隊可以只有很少的人就能實現(xiàn)突破性進展，可以說：越在行業(yè)初期，研發(fā)團隊越簡單幸福。 

但是時代決定了大家不能一直這么開心的走下去，因為軟件工程越來越復(fù)雜，版本越來越多，功能越來越強大，注定了研發(fā)團隊不可能一直是個小規(guī)模的組織。組織越大，個體之間的隔閡就越大，隔閡直接帶來的就是溝通成本的增加。 

溝通是敏捷和DevOps的共性本質(zhì)

Agile也好，極限編程也好，Scrum也好，這些“敏捷”實踐都是一種溝通的規(guī)范或者方法論。他們本質(zhì)上解決的問題都是溝通上的問題——你不懂我，我不懂你，我要懂你，就要緊密的在一起。 

可以說溝通效率的優(yōu)化，是敏捷運動和DevOps運動的一個共性本質(zhì)。DevOps說的什么？研發(fā)和運維緊密的在一起。 

敏捷方法論中，規(guī)范的是人與人之間的溝通。DevOps則更進一步，涵蓋了人與機器的溝通以及機器與機器的溝通。 

DevOps進一步實現(xiàn)了人機的自動化對接。 

在DevOps提供的全鏈路數(shù)字化鏈接的基礎(chǔ)上，下一步發(fā)展會是什么？發(fā)人深省，細思極恐 

那么從集團層面想要提升效率，要在各種場景下優(yōu)化溝通。怎么樣優(yōu)化溝通呢？在這方面騰訊做到了三件事： 

騰訊在優(yōu)化溝通上所做的三件事 

第一點是在組織上減少職務(wù)鴻溝

本文不講企業(yè)管理，略過 

第二點是信息化

這里筆者放了幾張對比圖： 

上例雖然用圖有些夸張，主要是為了闡明觀點便于理解：如果能用TAPD寫的干嘛要去寫紙條，寫完了還得粘，粘完了還得撕，是一件累人的事。技術(shù)文檔亦然，能用文本格式化在代碼庫里，為什么要寫doc？ 

敏捷從誕生開始到現(xiàn)在，Scrum已經(jīng)有20多年的歷史。如此漫長的時間段中，Scrum從理論層面上看幾乎沒有什么變化。 

但這20多年間，世界已經(jīng)前行，特別是人們的溝通方式發(fā)生了巨變。從口口相傳，到有電話，到PC，到Internet，到移動網(wǎng)絡(luò)，到智能設(shè)備，到微信等等，溝通的工具一直在升級換代。 

代碼庫在公有云的外網(wǎng)雖然現(xiàn)在還沒和企業(yè)微信集成，但騰訊內(nèi)的版本很早就實現(xiàn)了IM通知，比如在家休假，完全靠手機就可以了解到我們團隊的編碼進度，分支合并的消息都直接通過企業(yè)微信push到手機上，周末也都知道誰在加班。同樣對于TAPD，如果需求有變化，可以通過手機上企業(yè)微信直接查看。 

在信息化上，新的概念是辦公無邊界，包含辦公桌上的PC，家的PC，移動終端和智能設(shè)備，使用統(tǒng)一的鑒權(quán)和認證方案，實現(xiàn)研發(fā)過程中信息的無界傳達。 

第三點，確定統(tǒng)一的溝通體驗

騰訊在統(tǒng)一溝通體驗上非常有原則，我們知道騰訊有非常多不同形態(tài)的業(yè)務(wù)，導(dǎo)致在研發(fā)工具鏈上有很多不同的工具和體系。 

但是，卻保障了最基本的溝通工具是統(tǒng)一的。 

研發(fā)管理部負責了兩大研發(fā)平臺，TAPD是騰訊的敏捷研發(fā)平臺，承載了全公司的產(chǎn)品規(guī)劃、迭代、測試計劃、任務(wù)分配等等；Code是騰訊的源碼管理平臺，現(xiàn)在是工蜂，負責了全騰訊的代碼庫、資源文件、分支、審查、合并發(fā)布到內(nèi)部開源的研發(fā)鏈路。 

所以即便騰訊如此講究內(nèi)部賽馬，但最基礎(chǔ)溝通工具的統(tǒng)一還是沒丟。 

保持高頻溝通應(yīng)用的統(tǒng)一具有兩大好處，首先，它給集團內(nèi)的業(yè)務(wù)合作減少了障礙，當兩個平時業(yè)務(wù)互不相關(guān)的部門相互合作時，因為系統(tǒng)和賬號相通，只需要加入對應(yīng)的權(quán)限就行了；其次，統(tǒng)一溝通應(yīng)用為集團內(nèi)的人員流動創(chuàng)造了便利，一旦人員轉(zhuǎn)崗，在集團內(nèi)統(tǒng)一的溝通體驗讓調(diào)動人可以快速適應(yīng)工作。 

DevOps系統(tǒng)的橋接形式

接下來看看DevOps在系統(tǒng)之間是怎樣互相橋接的。DevOps關(guān)注的兩塊過程改進，一個是研發(fā)的過程，一個是質(zhì)量的過程。嚴格意義來說研發(fā)閉環(huán)是可以包含多個質(zhì)量過程閉環(huán)的。那么在這兩個流程的閉環(huán)中，都會涉及到若干種不同的工具。 

特別在一些領(lǐng)域，一款工具很難滿足全部的需要。比如說移動項目用jenkins，游戲也用就不太好，再比如說小型機，很難找到開源的CI工具做編譯。這就導(dǎo)致不同的業(yè)務(wù)形態(tài)會有不同的工具。為了讓整個系統(tǒng)流轉(zhuǎn)起來，工具和工具之間的相互調(diào)用，對于騰訊來說，最好的方式是通過松耦合。 

松耦合的概念是支持但不依賴。系統(tǒng)和系統(tǒng)之間都通過通用的接口和Hooks互相調(diào)用。同時騰訊內(nèi)網(wǎng)的研發(fā)系統(tǒng)，已經(jīng)逐步使用OAuth代替?zhèn)鹘y(tǒng)token驗證，來保證訪問的多方安全性。 

先來看內(nèi)置集成的例子，也就是平臺產(chǎn)品直接提供的功能，這里舉的是TAPD中關(guān)聯(lián)工蜂的代碼倉庫。 

第一步，TAPD的項目設(shè)置頁面，點關(guān)聯(lián)Git項目 

第二步，認證TAPD的授權(quán)到工蜂，這里是一個OAuthV2的授權(quán)框 

第三步，選擇你要綁定的git項目，點確定完成 

當push時，在評論帶上--tapdid這樣一個參數(shù)，就能把對應(yīng)的提交點綁定到需求上。 

只需三步，需求關(guān)聯(lián)你的代碼庫。 

但是理想是豐滿的，現(xiàn)實是骨干的。產(chǎn)品這樣設(shè)計的功能，并不是所有的用戶都買單，團隊往往需要根據(jù)自己的特性來定制流程。下面用微信安卓團隊例子看看開發(fā)團隊怎么做。 

整個團隊每月大概處理 300 ～ 500 個需求，平均每個人做10個，采用特性分支的協(xié)作模型項目，每月一個迭代，3到4個Feature Team并行開發(fā)。 

這個是微信的使用的分支模型，可以看到它是一個典型的特性分支發(fā)布模型。根據(jù)每個月的發(fā)布節(jié)奏設(shè)置了關(guān)鍵分支。 

先來看他們怎么把需求和代碼關(guān)聯(lián)起來的，他們并不滿足于單純把需求和提交綁定，而是做了全方位的關(guān)聯(lián)： 

項目的默認分支就是代表當前迭代，歷史發(fā)布的版本、當前版本和計劃開發(fā)的未來版本，都對應(yīng)每個月的保護分支和發(fā)布TAG。每個需求則對應(yīng)一個或多個Feature分支。 

這是微信項目在TAPD一個迭代的需求頁面 

這是合并請求頁面，他們要求開發(fā)自己把需求單粘進合并請求單里： 

如果格式不對，或者需求不存在，就自動提示你需要填寫正確的需求單。 

同時如果產(chǎn)品經(jīng)理說需求這個月還不能發(fā)布，也能通過tapd的標識，來直接攔截合并請求單。 

同樣和代碼庫集成的還有自動化掃描和測試流程，流程就不仔細說了，也是通過松耦合的方式來實現(xiàn)自動化調(diào)用。當掃描檢測失敗的時候自動阻攔合并請求，從代碼級別上攔截特性分支的合入。 

（自動化質(zhì)量檢測接口調(diào)用模型）騰訊企業(yè)級研發(fā)平臺的要求

一個成熟的企業(yè)級研發(fā)系統(tǒng)，以代碼管理為例，至少要在這4個方面能達到基本要求： 

存儲對騰訊來說，總?cè)萘勘仨殶o限大，單庫容量必須能支撐大型圖游這樣級別的項目。 

在管理層面，人員、權(quán)限、和項目必須做到企業(yè)可控，這一點也是硬性條件。 

在網(wǎng)絡(luò)層面，騰訊因為有多個辦公地，其中還有海外的，想要訪問項目足夠快就要在鄰近節(jié)點部署環(huán)境，來節(jié)省專線的帶寬，那么系統(tǒng)的多地就近訪問，在騰訊來說也是一個必備功能。 

在安全方面更是硬性要求，不能因為一個員工今天和領(lǐng)導(dǎo)鬧矛盾就刪庫跑路數(shù)據(jù)就找不回來了，同時，業(yè)務(wù)系統(tǒng)也要滿足企業(yè)內(nèi)各種各樣的合規(guī)和審查要求，比如查一下上個月某個項目組的訪問記錄。 

騰訊工蜂正是在這些要求下給騰訊量身定做的系統(tǒng)，目前已經(jīng)服務(wù)了包括微信在內(nèi)數(shù)不清的騰訊業(yè)務(wù)。 

在系統(tǒng)設(shè)計上，也考慮了行業(yè)先進的思想和經(jīng)驗。系統(tǒng)直接集成了代碼檢視能力，支持高數(shù)量級的分支管理，支持會話式開發(fā)，在工作過程中的動向通過動態(tài)的模式展示，同時集成和定制能力是全方位的，每一個可以操作的功能基本都有它對應(yīng)的API或Hooks。 

在企業(yè)管理方面也做了多層加強 

會后答問

問：騰訊為什么選擇Git作為下一代代碼管理平臺？

騰訊大約在2015~2016年意識到上一代SCM的不足，在2015~2017年間，阿里、百度、微軟等公司已經(jīng)全面切換Git，新一代的Git系統(tǒng)并非單純的Git，而是一套高度集成化，承載多項能力的效能平臺。新一代思想設(shè)計下的系統(tǒng)在使用過程中，潛移默化的大幅增加研發(fā)過程中的溝通效率，并能夠?qū)⒀邪l(fā)過程沉淀下來。 

問：如何看待Git和傳統(tǒng)SCM在權(quán)限組織上的差異？

Git在團隊實踐過程中，巧妙的培養(yǎng)的業(yè)務(wù)團隊拆分架構(gòu)和組件的行為。幫助項目架構(gòu)更合理的結(jié)構(gòu)化拆分，這種劃分大項目為細粒度的行為反而有助于權(quán)限的分散管理。這是經(jīng)過實踐所得出的結(jié)論。 

問：看到ppt中出現(xiàn)了分支權(quán)限，能否解釋一下？

因為需要考慮大型項目的日常管理，很多項目組有至少幾十人的團隊，之后又拆分成幾個小團隊，在分支策略上，往往不同團隊要管理不同分支。此時，庫級別的權(quán)限能力就不夠用了，必須在分支上增加權(quán)限控制。這也是工蜂的一項特有功能，后續(xù)會進一步優(yōu)化。

轉(zhuǎn)自：開發(fā)者頭條