茹炳晟? ??

騰訊TEG基礎(chǔ)架構(gòu)部資深技術(shù)專家

知名實戰(zhàn)派軟件質(zhì)量和研發(fā)工程效能專家,騰訊云最具價值專家TVP，暢銷書《測試工程師全棧技術(shù)進階與實踐》和《高效自動化測試平臺：設(shè)計與開發(fā)實戰(zhàn)》作者。

內(nèi)容來源：全球C++及系統(tǒng)軟件技術(shù)大會

首先我們來看一下研發(fā)效能的5個靈魂拷問：時代變了，很多東西的底層邏輯發(fā)生了很大變化，軟件研發(fā)行業(yè)也發(fā)生了天翻地覆的變化，早年基本上是軟件巨頭來主導整個行業(yè)。所以在那個時代更多的認為是大魚吃小魚的時代。但是今天軟件行業(yè)，尤其消費互聯(lián)網(wǎng)一側(cè)的變化已經(jīng)出現(xiàn)了，大魚吃不了小魚， 而且“大”已經(jīng)成為反應遲鈍的代名詞，更加追求的是“快”，因為對市場的把握、需求的梳理這些能力大家都類似的，就看誰能夠最快速做系統(tǒng)性考慮。

從研發(fā)效能整體來說可以歸結(jié)成“方輪子效應”。圖中拉車的是老板、業(yè)務，他看準了這個方向，全力朝著他的目標前進，他雇用了很多程序員去幫他把車往目標方向推進。在推進過程，老板不知道輪子是方的；員工在推車過程中，由于擔心業(yè)務停滯也不敢停下來。

這就是為什么我們在做很多架構(gòu)設(shè)置、功能交付的時候，雖然知道研發(fā)模式、實現(xiàn)方式很挫但是只要能夠把功能交付出去就萬事大吉。那如何面對方輪子效應 我們引發(fā)出了五個靈魂拷問。

第一個拷問說研發(fā)團隊的忙碌能不能代表高效。舉一個比較扎心的例子，有一些猛將型的員工，線上出了生產(chǎn)事故，第一個沖上去乒乒乓乓在生產(chǎn)環(huán)境敲一通代碼，緊急修復，整個過程像英雄一樣的存在。你覺得他是優(yōu)秀的員工嗎？實際上你會覺得為什么出了這個故障要他來修？這個坑是不是他挖的呢？

整個軟件的交付過程當中 我們大量的工作都集中在“救火”的象限，既重要又緊急 的事情，不做影響業(yè)務。如果你的業(yè)務團隊 、研發(fā)團隊 、運維團隊大量的時間花在救火的話，肯定是忙碌的，但并不代表是高效的。

第二個敏捷是研發(fā)效能提升的銀彈嗎？舉個例子，人在A點，要去向這個B點，那兩點之間最短的距離一定是直線。對應到軟件的研發(fā)模式，如果軟件最重要的功能點是明確的，那兩點之間最短的直線，對應的恰恰是瀑布模型。

所以敏捷真的適合所有嗎？實際上敏捷要求的“小步快跑”是指能夠迅速適應變化。還是剛才這個例子，從A點走向B點的過程中，如果看不清B點，能站著不走嗎？顯然不行，必須先走兩步，做一個迭代。當我做完這個迭代時，去觀察B點是近了還是遠了。如果遠了，有兩種可能，一種可能是一開始沒有看清，還有一種可能需求本身已經(jīng)發(fā)生變化，或者需求得到了進一步的釋放。再走接下來的兩步就可以朝著新的方向快速調(diào)整。

所以敏捷的“快”體現(xiàn)在船小好調(diào)頭上，而不是快速交付。因為對于瀑布模型，敏捷并沒有帶來效率上的提升。但是敏捷開發(fā)不僅增加了溝通上的成本、每天站會的成本、回顧會的成本 、任務打分的成本，還增加了每個階段額外投入的自化測試成本，每個迭代都要有測試，每個迭代都要有自動化，投入必然是增大的。所以說敏捷能不能提高研發(fā)效率取決于項目類型。

談敏捷就必須得看自動化，每個迭代做完的功能 在下一個迭代必須要被重復驗證，所以一定需要自動化。自動化測試真的讓整個研發(fā)的效率或者質(zhì)量提升了嗎？其實很多時候并不是。

自動化測試原來應該是手段，卻變成了目的。舉個例子，因為敏捷追求兩個迭代之間的功能要被重新驗證，必須要做自動化。所以很多項目里行政上有這樣的規(guī)定：兩個迭代之間必須做自動化；自動化測試必須達到多少等等。測試有這樣的指標要求，有限工作時長內(nèi)必然是先去完成自動化，而更探索性的、多方位的去使用軟件，嘗試發(fā)現(xiàn)更多問題的時間被開發(fā)自動化腳本所占據(jù)。在這種模式下面，得到的就是自動化，而不是高質(zhì)量。

如何面對呢？應該說，自動化測試從敏捷的角度來講就不應該做。尤其在前面一個功能被實現(xiàn)完成之后，在第一個迭代、第二個迭代應該更多的把時間和精力，放在如何的去測試這個軟件，多方位多角度使用這個軟件，以探索性的方式去發(fā)現(xiàn)更多問題。一兩個迭代之后，在功能趨向于穩(wěn)定的基礎(chǔ)上，把核心路徑拿出來做自動化。

第四個要做得快，“快”是一個很主觀的概念，如何做得快，要有度量。管理學大師比德德魯克說過：如果你不能衡量他，那你就沒有辦法改進他。這句話放在研發(fā)軟件或者研發(fā)效能領(lǐng)域是否成立呢？研發(fā)效能領(lǐng)域里面，通常存在一個很普遍的現(xiàn)象：你度量什么，你就會得到什么，但是一定不是以你所期望的方式得到。

舉個例子來講，如果通過千行代碼的Bug概率來衡量代碼質(zhì)量，開發(fā)人員會怎做？把代碼函數(shù)分母搞大一點， 一行分兩行寫，注釋多寫幾行，空格多放幾個。Bug率降了嗎？最終目的達到了嗎？

而軟件真的能度量嗎？如果你認為軟件的研發(fā)過程是能度量的，那你就是用傳統(tǒng)的科學管理的思維來管理軟件的研發(fā)，而軟件研發(fā)是一個創(chuàng)造性的勞動。

上述四個拷問基本上都是基于流程過程或者基于技術(shù)，那第五個拷問是說研發(fā)效率是不是一定由技術(shù)來驅(qū)動。有個很扎心的結(jié)論：其實很多研發(fā)效率的提升或者大的研發(fā)效率的提升可以不基于技術(shù)，只要你站在更高的位置。有一個非官方的數(shù)據(jù),一個Bug 的生命周期從被發(fā)現(xiàn)到修復關(guān)閉，假定生命周期是100個小時，真正有效的時長不足10%。90%以上的時間是在流程中的等待，在搭建設(shè)施環(huán)境，在溝通的成本上。如何去除這種等待，如何去除這種流程, 效果遠遠比單點的技術(shù)提升要大得多的。

研發(fā)效能的點點滴滴

講了這么多，那到底什么是研發(fā)效能？很多人認為軟件的架構(gòu)是設(shè)計出來的，其實軟件的架構(gòu)都生長出來的。架構(gòu)師只是搭了個骨架，同樣一個骨架可以生長出不同的架構(gòu)。換句話說，它通過歷史的緯度不斷迭代、變更適應。研發(fā)效能是個復雜的概念，他是先有這個現(xiàn)象，再去把它總結(jié)、它定義。

給大家看一些案例，大家如何來做原型？像現(xiàn)在的AI技術(shù)就很方便。如圖，你可以當場在后面的白板上去畫軟件界面的設(shè)置，攝像頭對著白板，通過模式識別的方法，實時識別、生成前端代碼的預覽。AI技術(shù)的應用可以大幅提升我們的效能。

現(xiàn)在的軟件普遍都在走微服務務架構(gòu)，一旦微服務之后是帶來一個特點是什么？開發(fā)人員對一個單點開發(fā)的微服務做測試，你會發(fā)現(xiàn)難的不是測試本身而是搭環(huán)境。因為你這個微服務要跟其他的服務交互，要在本地保證服務可測的話，就必須保證要把調(diào)用服務在本地拉起來，還要保證跟開發(fā)版本一樣，保證啟停的順序，保證版本的依賴方式。這種方式顯然不高效。高效的玩法是做一套公共的基礎(chǔ)環(huán)境，定期跟生產(chǎn)環(huán)境去做同步，這樣一來測試的效果會有大幅度提升，也更愿意主動的去做測試。

通過這兩個例子，我們來看一下 研發(fā)效能到底是什么東西。這是我歸納的一句話叫：研發(fā)效能的“第一性原理”：順暢，高質(zhì)量地持續(xù)交付有效價值的閉環(huán)。

順暢指的是整個的價值交付，從需求變成可交付的軟件，并且讓用戶用到軟件的過程必須順暢。不能做完功能沒有發(fā)布窗口或者沒有辦法做測試等等都是不順暢的表現(xiàn)。

第二個要高質(zhì)量，如果你跑得快、質(zhì)量差，換句話說也會死的越快。所以說要跑得快，同時質(zhì)量要求還是比較高的。

持續(xù)交付是指效率能夠做的很高，也能夠系統(tǒng)化的保證這個效率，而不是通過加班等不可持續(xù)的方式。我們要求持續(xù)交付要是持續(xù)的、系統(tǒng)性的、高效的。

有效價值是針對需求，更多是從產(chǎn)品經(jīng)理角色去講，要聽用戶講，但不要去照著做。

最后要形成閉環(huán)，要能夠快速反饋。

在這下面就引出了五個持續(xù)：開發(fā)過程要能夠持續(xù)，不能中斷；CI集成過程要能持續(xù)；測試要能夠持續(xù)，階段性交付、接口、模塊跟模塊之間的集成能做測試。而且能非常輕量級的來做測試，不能變成一錘子買賣；持續(xù)交付，東西做完能快速給到生產(chǎn)環(huán)境做部署、發(fā)布；對于互聯(lián)網(wǎng)產(chǎn)品還要持續(xù)的運維過程。

?在這個理念下，我們關(guān)注價值的流動速度，關(guān)注長期穩(wěn)定的質(zhì)量，同時關(guān)心客戶價值的交付，整個過程必須透明化，以數(shù)據(jù)驅(qū)動的方式來展開 這就是我對研發(fā)效能的比較系統(tǒng)的定義。

研發(fā)效能提升經(jīng)驗分享

那么研發(fā)效能的提升，尤其對大的企業(yè)，可以使用MVP的思想。從研發(fā)效能角度來講，不要做一個流程或一個工序?qū)ΜF(xiàn)在沒用但為了以后有用。一定要把一個有價值的東西拆成一個小片，哪怕改進點是非常小，但是對你的用戶或者研效平臺的使用者可以帶來實際的價值。

?在這種思想下面，就引出了我們研發(fā)效能的一套經(jīng)驗。

• 從痛點入手（從下往上走）

本地編譯時間長就從分布式編譯入手；自動化測試用例數(shù)量很大執(zhí)行維護成本很高，可以做微服務；數(shù)據(jù)準備困難，可以通過測試中臺去打造Test Data Service。

• 從全局切入

剛才已經(jīng)講過的一個BUG的流轉(zhuǎn)生命周期，一定要站在更高的宏觀視角去審視效率的提升，單點優(yōu)化帶來的提升是有限的，全流程拉通目前階段來看更有價值。

• 用戶獲益

第一是偽需求，做研發(fā)效能經(jīng)常會碰到的尷尬情況，比如說要幫用戶做測速率的版本，而用戶連自動化測試平臺都沒有建起來。所以這種情況下，那怎么來識別需求，就看看業(yè)務團隊自己有沒有在做。

第二是結(jié)構(gòu)問題有一句話是結(jié)構(gòu)不對，什么都不對。那結(jié)構(gòu)問題講的是什么呢？要把厲害關(guān)系理清楚，用體制幫你去推進，制定好規(guī)則，其他由系統(tǒng)去保證。做底層邏輯設(shè)計時， 要假設(shè)任何人都是自私自利的。如果體制設(shè)計能在每個人都自私自利的情況下獲得全局利益最大化，那這個制度設(shè)計就是成功的。

最后是服務意識，做研發(fā)效能的人要放低姿態(tài)。用戶用工具，驅(qū)動產(chǎn)品的過程，必須提供全程的保姆式服務甚至要幫助“背鍋”。

• 持續(xù)改進

永遠不要想把一件事情一下子就吃透。

• 全局優(yōu)化（自上而下）

研發(fā)效能到底從下往上做還是從上往下做？答案是兩邊要同時做?？抗こ處熗撇粍樱习宀恢滥愕墓こ躺嫌心男〇|西可以改進，這些東西的改進點一定是在工程師更了解。

• 效率平臺的靈活性

主要的一個點在于我們應該盡可能的去搭建一個平臺，而不是把所有的東西都自己來做。當規(guī)模做大到一定程度抽象成平臺，然后讓用戶按需使用垂直能力來符合業(yè)務上的一些特殊的要求。

• 杜絕掩耳盜鈴

虛榮性指標和可執(zhí)行指標要重點強調(diào)，為什么要做研發(fā)效能，需要有指標來度量就有兩種指標一種叫虛榮性指標。比如Sonar在企業(yè)內(nèi)部推廣之后，怎么來衡量推廣成功還是失??？很多企業(yè)都用有多少項目或者有多少百分比的項目接入了Sonar，這個就是虛榮性指標。Sonar的可執(zhí)行指標不是接入百分比或者接入用戶數(shù)量、項目數(shù)量，而應該是Sonar里面的關(guān)鍵問題存在時長，Sonar的P1的issue的增長趨勢、變化趨勢，能夠知道接下來行動的度量指標才是有益的。

• 吃自己的狗糧

我在騰訊內(nèi)部負責研發(fā)效能資源平臺，資源平臺本身是為TEG各個部門產(chǎn)品提供研發(fā)效率的提升，提供Devops、測試、監(jiān)控、運維相關(guān)的能力。那我們這個平臺自己的開發(fā)遵不遵守我們這套體系呢？答案是我們必須用自己的產(chǎn)品來發(fā)規(guī)范和內(nèi)容的，因為只有這樣我們才能明白用戶的疾苦。

研發(fā)效能的發(fā)展方向與未來展望

最后我們來聊一聊研發(fā)效能行業(yè)的趨勢。

研發(fā)流程全鏈路打通與過程可視化，這是必然的?，F(xiàn)在的研發(fā)效能差在哪里，都是單點提升。比如說測試跟開發(fā)有沒有打通，運維如何跟開發(fā)人員結(jié)合，安全測試如何融入到整個研發(fā)體系當中去，這些東西都是可以深入討論提升的。全鏈路打通同時要過程可視化。所有的數(shù)據(jù)要有看板，數(shù)據(jù)一定是要通過工具自動觸發(fā)狀態(tài)的變更、流轉(zhuǎn)，讓整個過程可視化，讓數(shù)據(jù)可相信。

第二個是敏態(tài)和穩(wěn)態(tài)的齊頭并進。一些快速迭代變更的產(chǎn)品要用敏態(tài)，但是一些后端的、偏底層的、穩(wěn)態(tài)的，瀑布模型依然有它的市場，依然有它的業(yè)務場景。

第三個研發(fā)能力的中臺沉淀，很多東西跨部門跨產(chǎn)品，有很多努力是應該被沉淀下來，尤其像Devops，自動化的測試，靜態(tài)代碼的分析等等，都應該要被沉淀成一個垂直的單點。然后可以在研發(fā)效能的上層平臺做組合。

第四個是講研發(fā)效能不是拍腦袋，所有的東西都應該有數(shù)據(jù)來支撐。

最后研發(fā)效能從有到無，研發(fā)效能的核心能力應該融入了你的研發(fā)過程，深入人心。

謝謝大家。

掃描下方二維碼

免費領(lǐng)取白皮書