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

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

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

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

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

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

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

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

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

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

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

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

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

但是時(shí)代決定了大家不能一直這么開心的走下去，因?yàn)檐浖こ淘絹碓綇?fù)雜，版本越來越多，功能越來越強(qiáng)大，注定了研發(fā)團(tuán)隊(duì)不可能一直是個(gè)小規(guī)模的組織。組織越大，個(gè)體之間的隔閡就越大，隔閡直接帶來的就是溝通成本的增加。 

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

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

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

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

DevOps進(jìn)一步實(shí)現(xiàn)了人機(jī)的自動(dòng)化對(duì)接。 

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

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

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

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

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

第二點(diǎn)是信息化

這里筆者放了幾張對(duì)比圖： 

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

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

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

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

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

第三點(diǎn)，確定統(tǒng)一的溝通體驗(yàn)

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

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

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

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

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

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

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

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

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

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

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

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

第三步，選擇你要綁定的git項(xiàng)目，點(diǎn)確定完成 

當(dāng)push時(shí)，在評(píng)論帶上--tapdid這樣一個(gè)參數(shù)，就能把對(duì)應(yīng)的提交點(diǎn)綁定到需求上。 

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

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

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

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

先來看他們?cè)趺窗研枨蠛痛a關(guān)聯(lián)起來的，他們并不滿足于單純把需求和提交綁定，而是做了全方位的關(guān)聯(lián)： 

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

這是微信項(xiàng)目在TAPD一個(gè)迭代的需求頁面 

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

如果格式不對(duì)，或者需求不存在，就自動(dòng)提示你需要填寫正確的需求單。 

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

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

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

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

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

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

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

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

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

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

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

會(huì)后答問

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

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

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

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

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

因?yàn)樾枰紤]大型項(xiàng)目的日常管理，很多項(xiàng)目組有至少幾十人的團(tuán)隊(duì)，之后又拆分成幾個(gè)小團(tuán)隊(duì)，在分支策略上，往往不同團(tuán)隊(duì)要管理不同分支。此時(shí)，庫級(jí)別的權(quán)限能力就不夠用了，必須在分支上增加權(quán)限控制。這也是工蜂的一項(xiàng)特有功能，后續(xù)會(huì)進(jìn)一步優(yōu)化。

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