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

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

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

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

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

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

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

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

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

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

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

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

那么從集團層面想要提升效率,，要在各種場景下優(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通知,，比如在家休假，完全靠手機就可以了解到我們團隊的編碼進(jìn)度,，分支合并的消息都直接通過企業(yè)微信push到手機上,，周末也都知道誰在加班。同樣對于TAPD,，如果需求有變化,，可以通過手機上企業(yè)微信直接查看。 

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

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

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

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

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

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

保持高頻溝通應(yīng)用的統(tǒng)一具有兩大好處,，首先，它給集團內(nèi)的業(yè)務(wù)合作減少了障礙，當(dāng)兩個平時業(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)注的兩塊過程改進(jìn)，一個是研發(fā)的過程,，一個是質(zhì)量的過程,。嚴(yán)格意義來說研發(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項目 

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

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

當(dāng)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)： 

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

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

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

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

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

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

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

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

存儲對騰訊來說,，總?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ìn)的思想和經(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)化拆分,，這種劃分大項目為細(xì)粒度的行為反而有助于權(quán)限的分散管理,。這是經(jīng)過實踐所得出的結(jié)論。 

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

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

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