亚洲熟妇av一区二区三区,久久久久久精品观看sss,免费观看四虎精品国产永久,国产成人精品一区二三区熟女,天堂网在线最新版www资源网

研發(fā)效能提升的八項實踐建議(研發(fā)效能提升的八項實踐建議怎么寫)

筆者常會被問及這樣的問題:“你之前主導(dǎo)的研發(fā)效能提升項目都獲得了成功,如果請你到我們公司來,幾年可以幫助我們把研發(fā)效能做好?”

這其實是一個無解的問題。

從某種程度上說,投入大,周期就會短,但是實施周期不會因為投入無限大而無限變短。我們可以避開很多曾經(jīng)踩過的坑,盡量少走彎路,但是適合自己的路還是要靠自己走出來的,拔苗助長只會損害長期利益。買了一輛跑車,你就能成為賽車手嗎?

鑒于此,筆者總結(jié)了八項實踐建議,如下圖所示,供讀者參考。

研發(fā)效能提升的八項實踐建議(研發(fā)效能提升的八項實踐建議怎么寫)

圖 研發(fā)效能提升的八項實踐建議

研發(fā)效能提升的八項實踐建議(研發(fā)效能提升的八項實踐建議怎么寫)

01

從痛點入手

研發(fā)效能提升八項實踐建議的第一項,是“從痛點入手”。

很多時候,當(dāng)我們手上拿著錘子的時候,看什么都像釘子。但是研發(fā)效能的提升恰好是反過來了,我們要先找到哪些是最礙眼的釘子,然后用體系化的方法論去打造合適的錘子。

所以在推行研發(fā)效能的早期階段,我們通常會采用自下而上的策略,從一個個工程實踐中的實際痛點(釘子)入手,從解決問題的角度打造研發(fā)效能提升的亮點,此時我們追求的是“短、平、快”,遵循的是將問題點逐個擊破的原則。

比如下面這些場景:

  • 本地編譯耗時長:提供增量編譯和分布式編譯能力。
  • 本地測試?yán)щy,測試環(huán)境準(zhǔn)備復(fù)雜且耗時長:基于Kubernetes的Pod提供一鍵搭建測試環(huán)境的能力。
  • 自動化測試用例數(shù)量大,執(zhí)行回歸時間過長:采用并發(fā)測試用例執(zhí)行機(jī)制,使用幾百、幾千臺測試執(zhí)行機(jī)并行執(zhí)行用例,實現(xiàn)用硬件資源換時間。
  • 自動化測試用例維護(hù)成本高:測試用例采用模塊化和分層體系,實現(xiàn)低成本的自動化用例維護(hù)。
  • 測試數(shù)據(jù)準(zhǔn)備困難:引入統(tǒng)一的測試數(shù)據(jù)服務(wù)(Test Data Service)能力。
  • 研發(fā)后期階段,代碼遞交集中,缺陷井噴:推行測試左移策略,鼓勵研發(fā)自測,遵循“誰開發(fā)、誰測試、誰上線、誰值班”的原則。
  • 性能缺陷在研發(fā)后期發(fā)現(xiàn),修復(fù)重測成本高居不下:性能測試轉(zhuǎn)變?yōu)樾阅芄こ蹋屝阅苋谌胲浖邪l(fā)的各個環(huán)節(jié),而不是最后的一錘子買賣。
  • 安全問題頻現(xiàn):將安全測試能力納入研發(fā)的全生命周期,實現(xiàn)DevSecOps,而不是早期的SDL(Security Development Lifecycle,安全開發(fā)生命周期)。
  • 集群規(guī)模龐大,發(fā)布過程耗時過長:各個層級的并發(fā)部署能力,集群內(nèi)節(jié)點的并發(fā)、集群間的并發(fā)等。
  • 項目的過程數(shù)據(jù)都是后期集中填充,失去度量意義:項目的過程數(shù)據(jù)由工具自動填充,不再依賴工程師手工輸入。比如,開發(fā)完成的時間不再依賴于開發(fā)人員手工填寫,而是由Jenkins構(gòu)建完成后自動填寫,以保證所有過程數(shù)據(jù)的真實有效性,從而為后面的度量和改進(jìn)提供可靠的信息輸入。

研發(fā)效能提升的八項實踐建議(研發(fā)效能提升的八項實踐建議怎么寫)

02

從全局切入

第二項是“從全局切入”。

很多時候我們會嘗試去優(yōu)化某個具體的環(huán)節(jié),而忽略了全局優(yōu)化的可能。

舉個例子,我們?nèi)メt(yī)院看病,在掛號時經(jīng)常會出現(xiàn)排隊半小時,而實際掛號可能就花費兩分鐘的情況,接下來很可能又是漫長的排隊等待醫(yī)生就診,好不容易進(jìn)入了診室,可能問診不到五分鐘就又被要求去驗血……整個過程中實際有效時間的占比很小。

如果這個時候我們還試圖去優(yōu)化掛號本身的時間,而不去關(guān)注優(yōu)化各個環(huán)節(jié)的等待時間,那顯然是錯誤的方向。

因此,效率的提升既要關(guān)注單個步驟的優(yōu)化,也要專注減少步驟與步驟之間的無用等待。這一點體檢中心就比公立醫(yī)院做得好很多,我們很少會見到體檢中心每個科室門口都大排長龍的情景,因為體檢中心出于經(jīng)濟(jì)利益的考慮會關(guān)注吞吐量,會通過全局排隊調(diào)度優(yōu)化來實現(xiàn)更高的盈利。

回到軟件研發(fā)領(lǐng)域,你會發(fā)現(xiàn)類似上面醫(yī)院這種不合理的排隊現(xiàn)象隨處可見,比如軟件缺陷的流轉(zhuǎn),軟件需求的實現(xiàn)與交付,軟件制品包發(fā)布等待,等等。

這些也是提升研發(fā)效能需要重點關(guān)注的領(lǐng)域,需要從全局理清楚全流程,識別出等待浪費的時間,通過流程再造與優(yōu)化實現(xiàn)全局效率的提升。

03

用戶獲益

對于研發(fā)效能的提升,有一點我們必須牢記,那就是成功的標(biāo)準(zhǔn)不是研發(fā)效能平臺的成功,而是客戶的成功。只有客戶獲益才是檢驗研發(fā)效能項目成功的唯一標(biāo)準(zhǔn),下面我們再總結(jié)一些要點。

偽需求:偽需求是指研發(fā)效能團(tuán)隊自己臆想出來的需求,是屬于典型的“手里拿著錘子,看什么都像釘子”的典型案例。那么如何識別偽需求呢?識別標(biāo)準(zhǔn)其實很簡單,就看用戶是不是愿意和你分?jǐn)偝杀?,如果業(yè)務(wù)線已經(jīng)開始做了,或者想要開始做,那就說明那是業(yè)務(wù)線的剛需,如果研發(fā)效能平臺能幫助用戶提供方案,那么研發(fā)效能平臺的接入就是水到渠成的事情。筆者見過很多這類剛需的例子,比如微服務(wù)架構(gòu)下集成測試環(huán)境的搭建就是其中的典型。

結(jié)構(gòu)問題:著名商業(yè)顧問劉潤說過“結(jié)構(gòu)不對,什么都不對”。比如,兩個和尚分粥的故事想必大家都聽過,一碗粥兩個和尚要均分,但是分粥的和尚總想多喝點粥,那怎么才能做到無監(jiān)管情況下的公平呢?教育分粥的和尚說出家人“以少吃為懷”嗎?顯然一旦沒有了監(jiān)管,他就會給自己多分點,解決這個問題的最好辦法就是一個和尚分粥,另一個和尚選粥——這個體制就決定了分粥的均勻性。

因此,好的策略是承認(rèn)每個人都是自私的,但是我們制定的策略要能夠在人人都是自私的基礎(chǔ)上獲得全局利益的最大化。

如果全局利益最大化是建立在要求每個人都是大公無私的基礎(chǔ)上,那就是失敗的設(shè)計,因為這必然會導(dǎo)致失敗。回到研發(fā)效能提升這個問題上,我們必須抱著“不是我們的研發(fā)效能平臺有多好,而是業(yè)務(wù)線用了以后有什么提升”的態(tài)度來定位自己,才能從結(jié)構(gòu)上獲得成功的籌碼。

服務(wù)意識:理解了上面的觀點,再來理解服務(wù)意識就很容易了。在研發(fā)效能平臺落地的過程中,我們需要和業(yè)務(wù)線互助以實現(xiàn)雙贏,業(yè)務(wù)線收獲現(xiàn)成可用的方案,研發(fā)效能平臺收獲最佳實踐的沉淀,這些最佳實踐的沉淀是至關(guān)重要的,為后期的批量成功復(fù)制提供了技術(shù)基礎(chǔ)。

04

持續(xù)改進(jìn)

持續(xù)改進(jìn)是研發(fā)效能平臺自身發(fā)展的必經(jīng)之路。

很多問題在開始時,我們的關(guān)注點是如何快、速簡單地解決問題,但是當(dāng)用戶量和接入團(tuán)隊日益增長后,我們更需要關(guān)注解決方案的普適性和通用性。如果一開始就試圖尋找完美的方案,那么必然會得不償失。

比如,我們需要在Jenkins中通過hook機(jī)制去觸發(fā)一些操作(比如代碼靜態(tài)掃描、單元測試等),最簡單的做法就是在hook中實現(xiàn)操作的具體步驟,這種實現(xiàn)在開始的效率很高,也非常容易實現(xiàn),但卻不是最優(yōu)的方案,因為hook中的代碼只會被執(zhí)行一次,而且hook越來越多以后,各種實現(xiàn)都散落在各個地方,難以維護(hù),一旦有新的需要(比如要加入慢SQL掃描),就需要改hook實現(xiàn),而且這種做法也違背了IaC(Infrastructure as Code)原則。

更好的做法是引入研發(fā)效能的消息中心,通過下游操作的訂閱模式來實現(xiàn)未來的可擴(kuò)展性。

但是,如果我們從一開始就創(chuàng)建消息中心,實現(xiàn)的難度和成本都會大增,業(yè)務(wù)線有可能就等不及這個方案,從而研發(fā)效能的提升就無法如期落地。所以我們認(rèn)為,研發(fā)效能的落地可以采取“先圈地、后改進(jìn)”的策略。

05

全局優(yōu)化

研發(fā)效能提升的落地,光靠自下往上和光靠自上往下都是行不通的,而是應(yīng)該雙管齊下,“從兩邊往中間擠”才是切實可行的方案

研發(fā)效能提升的初期,主要是靠“自下往上”的工程實踐來實現(xiàn)各種痛點問題的各個擊破,比如通過分布式編譯來降低編譯的時長,通過AI技術(shù)來自動生成單元測試的用例,通過分析代碼遞交歷史自動推薦最合適的代碼評審者等。通過這些專項的效率提升逐漸向管理層證明研發(fā)效能提升的實際價值,由此引起管理層對研發(fā)效能的重視,進(jìn)而為管理層從上往下推進(jìn)研發(fā)效能的提升打下基礎(chǔ)。

隨著研發(fā)效能實踐逐漸進(jìn)入深水區(qū),單一領(lǐng)域效能提升的邊際效應(yīng)會逐漸遞減,此時基于橫向拉通的全局優(yōu)化變得非常關(guān)鍵,自上往下的推動在此時將會起到關(guān)鍵的作用。很多橫向跨部門的流程優(yōu)化和整合必須借助管理層的力量才能有效地向前推進(jìn)。

06

效能平臺架構(gòu)的靈活性

這里我們先來講兩個概念:“唱戲的”和“搭臺的”。剛開始做研發(fā)效能的時候,我們既是搭臺的又是唱戲的,在研發(fā)效能平臺(搭臺)的基礎(chǔ)上提供各業(yè)務(wù)線的解決方案(唱戲)。但是,當(dāng)業(yè)務(wù)線的接入規(guī)模不斷擴(kuò)大的時候,各個垂直領(lǐng)域的多樣化需求越來越多,我們已經(jīng)很難應(yīng)對各家的個性化非通用需求了(每家要唱的戲都不同)。此時,研發(fā)效能平臺的開放能力就成為關(guān)鍵,它必須能夠應(yīng)對這種多樣性,讓業(yè)務(wù)線能夠在平臺上實現(xiàn)各自的個性化需求,所以研發(fā)效能平臺本身的技術(shù)架構(gòu)設(shè)計必須考慮可擴(kuò)展性和靈活性。

比如,我們可以Jenkins持續(xù)集成工具視為一個平臺,在這個平臺上支持安裝各種插件,以增強平臺功能,從而實現(xiàn)平臺架構(gòu)的靈活性。

07

杜絕“掩耳盜鈴”

“掩耳盜鈴”是我們在落地研發(fā)效能過程中經(jīng)常會犯的錯誤。下面給出了一些研發(fā)效能的“最差實踐”,讀者可以在心里默默數(shù)一數(shù)被砸中幾條。

  • 代碼質(zhì)量門禁Sonar設(shè)而不卡。
  • 單元測試只是執(zhí)行,不寫斷言Assert。
  • 代碼覆蓋率形同虛設(shè)。
  • Peer Review走過場。
  • 代碼遞交過于隨意。
  • 監(jiān)控超配,有報警但無人認(rèn)領(lǐng)。

另一種掩耳盜鈴的錯誤實踐是普遍采用虛榮性指標(biāo)來做度量效能。

那么到底什么是虛榮性指標(biāo)呢?

虛榮性指標(biāo)是指那些不能直接用來指導(dǎo)后續(xù)行動的指標(biāo),我們需要的是可以指導(dǎo)我們行動的可執(zhí)行指標(biāo),可以參考以下內(nèi)容。

  • “接入Sonar的工程數(shù)”就是虛榮性指標(biāo),與之對應(yīng)的可執(zhí)行指標(biāo)是“Sonar問題的增長趨勢”和“Sonar問題的修復(fù)時長”。
  • “系統(tǒng)用戶數(shù)”就是虛榮性指標(biāo),與之對應(yīng)的可執(zhí)行指標(biāo)是“DAU單日活躍用戶數(shù)”和“MAU月活躍用戶數(shù)”。
  • “接入研發(fā)效能平臺的項目數(shù)”就是虛榮性指標(biāo),與之對應(yīng)的可執(zhí)行指標(biāo)是“百分之多少的項目使用過研發(fā)效能平臺來完成開發(fā)測試和發(fā)布流程”。

總而言之,我們需要的是雪中送炭,而不是錦上添花。

08

吃自己的“狗糧”

最后一點,吃自己的“狗糧”,意為“做自己研發(fā)效能平臺的第一個用戶”,研發(fā)效能平臺本身的研發(fā)流程必須通過自己的平臺來執(zhí)行,這樣才能站在用戶的角度看待自己的方案,才能和業(yè)務(wù)線用戶“共情”。

如果我們作為效能工具平臺的研發(fā)團(tuán)隊,自己都不用自己的工具平臺來完成研發(fā)過程,就很難要求別人也來使用我們的研發(fā)效能平臺。

基于這項理念,我們始終踐行的做法是,研發(fā)效能團(tuán)隊主持開發(fā)的產(chǎn)品和解決方案,自己必須是第一個用戶,同時我們自己必須認(rèn)可其帶來的價值,只有這樣才能站在用戶的視角來客觀地評價我們的產(chǎn)品和方案,不至于出現(xiàn)“王婆賣瓜自賣自夸”的現(xiàn)象。

* 本文節(jié)選自《軟件研發(fā)效能提升之美》一書,歡迎閱讀此書了解更多內(nèi)容!

研發(fā)效能提升的八項實踐建議(研發(fā)效能提升的八項實踐建議怎么寫)

研發(fā)效能提升的八項實踐建議(研發(fā)效能提升的八項實踐建議怎么寫)

▊《軟件研發(fā)效能提升之美》

吳駿龍 茹炳晟 著

如果你想了解更多軟件研發(fā)效能的系統(tǒng)知識和趣聞軼事,或正在從事軟件研發(fā)效能相關(guān)工作,希望進(jìn)一步深造學(xué)習(xí),請不要錯過這本《軟件研發(fā)效能提升之美》。

本書由兩位行業(yè)知名專家聯(lián)袂編寫,匯聚了行業(yè)前沿的研發(fā)效能提升實踐與案例,同時提煉出大量方法論和經(jīng)驗反思,以詼諧幽默而又不失嚴(yán)謹(jǐn)詳實的風(fēng)格,全方位多角度覆蓋研發(fā)效能領(lǐng)域的核心知識,深入淺出,發(fā)人深思。收錄作者行業(yè)知名大會熱門演講精華內(nèi)容,集合研發(fā)效能提升的前沿技術(shù)與理念,40余名行業(yè)專家與企業(yè)高管傾情推薦。

做好研發(fā)效能提升是不容易的,我們需要的不僅僅是前沿技術(shù)的加持,更重要的是理念的更新?lián)Q代和優(yōu)秀實踐的傳承,而這些,正是本書所希望帶給讀者的核心價值。我們不僅會告訴你“怎么做”,還會告訴你這么做的“緣由和故事”,呈現(xiàn)所有人都能學(xué)得會且?guī)У米叩难邪l(fā)效能實踐。這樣,也許若干年后你重讀本書,依然能夠時讀時新,有全新的收獲。

版權(quán)聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn),該文觀點僅代表作者本人。本站僅提供信息存儲空間服務(wù),不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容, 請發(fā)送郵件至 舉報,一經(jīng)查實,本站將立刻刪除。