散文網(wǎng) » 生活 »日常 » “軟件研發(fā)效能提升之美”閱讀筆記（2）

“軟件研發(fā)效能提升之美”閱讀筆記（2）

2022-01-30 20:17 作者:十指環(huán) 0人讀過(guò) | 我要投稿

知識(shí)點(diǎn)拆解

1、效能與質(zhì)量相輔相成

高頻的工作能夠帶來(lái)更早的風(fēng)險(xiǎn)暴露，繼而更好地保障質(zhì)量，而高頻的前提是高效。

關(guān)注質(zhì)量，生產(chǎn)率自然會(huì)隨之提高。效能的提升能夠?qū)④浖邪l(fā)中的風(fēng)險(xiǎn)更快、更及時(shí)地暴露出來(lái)，同時(shí)減輕人腦負(fù)擔(dān)，反過(guò)來(lái)又能提升質(zhì)量本身。

2、霍桑效應(yīng)

? ? ?起源于1924年至1933年間的一系列實(shí)驗(yàn)研究：實(shí)驗(yàn)者對(duì)新的實(shí)驗(yàn)處理會(huì)產(chǎn)生正向反應(yīng)，即由于環(huán)境改變而改變行為，所以生產(chǎn)率的提高并非由實(shí)驗(yàn)操控造成的。這種現(xiàn)象稱(chēng)為”霍桑效應(yīng)“。

1）負(fù)面影響：霍桑效應(yīng)會(huì)造成度量結(jié)果的偏差，降低下信息價(jià)值，最終影響效能提升決策。

解決辦法：

雙盲實(shí)驗(yàn)法：讓實(shí)驗(yàn)者和對(duì)照者都不知道自己是在做實(shí)驗(yàn)。

環(huán)境弱化法：盡可能弱化實(shí)驗(yàn)結(jié)果給實(shí)驗(yàn)者帶來(lái)的影響，盡可能弱化環(huán)境變化，工具變化，流程變化等內(nèi)容，不設(shè)定KPI，避免不必要的訪談等工作。

2）正面影響：與員工談話，讓員工發(fā)泄自己的不滿(mǎn)，能使員工干勁倍增，大幅度提高生產(chǎn)效率。企業(yè)中通過(guò)各種座談會(huì)，復(fù)盤(pán)會(huì)，一對(duì)一面談等形式對(duì)員工進(jìn)行心理建設(shè)，其實(shí)質(zhì)是霍桑效應(yīng)的一種應(yīng)用，是對(duì)人性的尊重。給大家的啟示：渴望尊重和欣賞，是人性的需求之一。適度的關(guān)注和贊美能夠產(chǎn)生強(qiáng)烈的心理暗示，繼而帶來(lái)效能的提升。

3、摩爾定律和反摩爾定律

摩爾定律：

1）集成電路芯片上所集成的電路數(shù)目，每隔18個(gè)月翻一番；

2）微處理器的性能每隔18個(gè)越提高一倍，而同期價(jià)格下降一半；

3）用1美元能買(mǎi)到的計(jì)算機(jī)性能，每隔18個(gè)月翻2番；

反摩爾定律：一個(gè)公司今天要想和18個(gè)月前賣(mài)掉同樣多，同樣質(zhì)量的產(chǎn)品，它的營(yíng)業(yè)額就會(huì)下降一半。越遲交付的價(jià)值其價(jià)值越低，我們的目標(biāo)是快速地交付高質(zhì)量的產(chǎn)品，那么在研發(fā)效能上也應(yīng)采取相應(yīng)的手段進(jìn)行支撐。傳統(tǒng)的瀑布模型是”反摩爾定律“的。

4、信息熵

1948年香農(nóng)提出了”信息熵“的概念，解決了信息的量化度量問(wèn)題。

公式中pi是指某信息出現(xiàn)的概率。假設(shè)書(shū)本總共20萬(wàn)字，”研發(fā)效能“出現(xiàn)1000次，那么出現(xiàn)的概率=1000/20萬(wàn)=0.5%，把所有詞語(yǔ)出現(xiàn)的概率都統(tǒng)計(jì)出來(lái)，用上面的公式計(jì)算得出該書(shū)的信息熵。

1）通過(guò)公式推導(dǎo)得出，符號(hào)越少，信息熵越小，故語(yǔ)音輸出的效率不高。

2）人的溝通也有帶寬（語(yǔ)速和信息量），丟包（沒(méi)聽(tīng)清楚），延遲（傳輸介質(zhì)影響），協(xié)議轉(zhuǎn)換等因素?,這些因素會(huì)削弱信息量和信息價(jià)值。

5、自解釋編程

自解釋的代碼不是無(wú)注釋和無(wú)文檔的代碼，而是伴隨著高信息熵的代碼體系，內(nèi)容簡(jiǎn)潔合理的注釋與文檔同樣也是優(yōu)秀代碼的一部分，能夠給效能的提升帶來(lái)幫助。

6、可視化

數(shù)據(jù)可視化，以圖像為載體將數(shù)據(jù)背后的故事敘述出來(lái)，使人一目了然。

項(xiàng)目管理中的可視化方法：看板，甘特圖，燃盡圖，效能數(shù)據(jù)可視化。

7、豎井效應(yīng)

指公司內(nèi)的各個(gè)職能團(tuán)隊(duì)各自為政，均達(dá)到了局部的高效，然而從全局看卻不見(jiàn)得高效。

8、墨菲定律

一項(xiàng)風(fēng)險(xiǎn)的實(shí)際發(fā)生，往往意味著未來(lái)也很可能會(huì)再次發(fā)生該風(fēng)險(xiǎn)。

9、集成

指部分向整體合并的過(guò)程，例如某工程師研發(fā)的代碼，將其合并到主干的過(guò)程就是集成，其中涉及編譯，打包，構(gòu)建，單元測(cè)試等工作。

10、交付

指將軟件產(chǎn)品移交給質(zhì)量團(tuán)隊(duì)或用戶(hù)評(píng)審的過(guò)程，評(píng)審?fù)瓿傻南乱徊骄褪遣渴鹬辽a(chǎn)環(huán)境。

11、持續(xù)

通過(guò)將任務(wù)化整為零，由單個(gè)節(jié)點(diǎn)完成一部分工作后，交由下一節(jié)點(diǎn)執(zhí)行，但任何一個(gè)節(jié)點(diǎn)出現(xiàn)問(wèn)題時(shí)就是執(zhí)行快速失敗，加快了周轉(zhuǎn)速度，能夠及早暴露問(wèn)題。

項(xiàng)目管理中的提效手段

1、敏捷開(kāi)發(fā)

? ? ? 敏捷開(kāi)發(fā)方法：Scrum，極限編程，動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)，特性驅(qū)動(dòng)開(kāi)發(fā)

FDD：特性驅(qū)動(dòng)開(kāi)發(fā)，由Jeff de Luca、Eria Lefebvre和Peter Coad共同提出。所有共組圍繞特性展開(kāi)，項(xiàng)目不需要冗長(zhǎng)的設(shè)計(jì)過(guò)程，而是邊設(shè)計(jì)邊開(kāi)發(fā)邊完善。特性被設(shè)計(jì)為可理解的，可衡量的，可實(shí)現(xiàn)的功能，可以直接拿出來(lái)展示給客戶(hù)，提高富有價(jià)值的信息。

? ? ?敏捷開(kāi)發(fā)主要角色：產(chǎn)品負(fù)責(zé)人，敏捷教練，開(kāi)發(fā)團(tuán)隊(duì)。

2、敏捷項(xiàng)目管理中五大效能提升要素

1）自組織團(tuán)隊(duì)（自治，自我超越，正向交互）

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

3）頻繁交付

4）消除對(duì)立（盡量避免針對(duì)不同角色制定可能會(huì)產(chǎn)生沖突的KPI,例如測(cè)試人員制定BUG數(shù)量的KPI，針對(duì)研發(fā)人員制定解決BUG數(shù)量的KPI; 建議采用共同KPI）

5）未雨綢繆

“計(jì)劃就是把未來(lái)變成現(xiàn)在，這樣就可以未雨綢繆”

提高對(duì)項(xiàng)目有利的事件發(fā)生的可能性及其影響力，同時(shí)減少對(duì)項(xiàng)目不利事件發(fā)生的可能性，并盡可能減少其負(fù)面效應(yīng)。在敏捷團(tuán)隊(duì)中所有成員面對(duì)共同的目標(biāo)時(shí)，主動(dòng)暴露問(wèn)題，積極尋求解決，能夠更好地促進(jìn)風(fēng)險(xiǎn)的消化。適當(dāng)選擇工具：看板，燃盡圖，缺陷跟蹤系統(tǒng)等

關(guān)注點(diǎn)：及時(shí)暴露風(fēng)險(xiǎn)，防御性管理，planB，避免盲目自信

3、提效手段：解耦，高頻，消除變量，代碼質(zhì)量，分支管理，開(kāi)發(fā)流水線

1）解耦：“快速”的一大阻礙是軟件研發(fā)各項(xiàng)工作的耦合度，一項(xiàng)工作產(chǎn)生瓶頸很容易阻塞其他工作的進(jìn)行，繼而造成整體進(jìn)度的延期。解決“獲得質(zhì)量反饋太慢，成本太高；研發(fā)與測(cè)試相互依賴(lài)太多，造成互相阻塞；與外部團(tuán)隊(duì)依賴(lài)太多，造成互相阻塞”等問(wèn)題。

2）高頻：將高頻工作有效地運(yùn)轉(zhuǎn)起來(lái)，積極地跟進(jìn)每一次問(wèn)題，最終“快速交付和高質(zhì)量”可同時(shí)得到保障。

3）消除變量：越是復(fù)雜的系統(tǒng)越需要精簡(jiǎn)。

a，約束是控制復(fù)雜度的第一步，因?yàn)槊慷嘁环N變量，就多一分風(fēng)險(xiǎn)，如果遵守統(tǒng)一的標(biāo)準(zhǔn)規(guī)范，就可以收斂出錯(cuò)的情況，也有利于團(tuán)隊(duì)的共同認(rèn)知與交流；

b，控制復(fù)雜度，將影響復(fù)雜度的不必要因素在一開(kāi)始就掐滅，即零容忍；

c，抵抗熵增，管理要做的事情只有一件，就是如何對(duì)抗熵增，在這個(gè)過(guò)程中，企業(yè)的生命力才會(huì)增強(qiáng)，而不是默默地走向死亡。

d，遠(yuǎn)慮：人無(wú)遠(yuǎn)慮，必有近憂。依賴(lài)工程師的自覺(jué)一般是不靠譜的，需要有制度和流程熵的約束，良好的代碼評(píng)審機(jī)制和走讀機(jī)制可以在一定程度上規(guī)避一些問(wèn)題，團(tuán)隊(duì)的文化建設(shè)和工匠精神的培養(yǎng)則是制度的有力補(bǔ)充。

4）代碼質(zhì)量

代碼質(zhì)量受到成本、時(shí)間和范圍的三重約束。

實(shí)踐方法：測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD,UTDD,ATDD）,靜態(tài)掃描，代碼評(píng)審

5）分支管理

分支允許多人同時(shí)工作而互不干擾，不過(guò)也需要在某個(gè)時(shí)機(jī)，將分支代碼合并成一份，以便生產(chǎn)最終交付的代碼版本，真?zhèn)€過(guò)程涉及到版本管理，發(fā)布管理，缺陷修復(fù)等環(huán)節(jié)。需要工作流將整個(gè)流程有效地管控起來(lái)，該類(lèi)規(guī)則稱(chēng)為“工作流”，例如 Git Flow， GitHub Flow， GitLab Flow等

6）開(kāi)發(fā)流水線

DevOps流水線從某種程度上說(shuō)就是一個(gè)很好的載體，因?yàn)樗鼛缀醺采w了真?zhèn)€端到端的流程。在流水線上，各環(huán)節(jié)流轉(zhuǎn)得越快，價(jià)值流動(dòng)就越快。

4、誤區(qū)

1）敏捷開(kāi)發(fā)就是快速開(kāi)發(fā)

? ? 敏捷項(xiàng)目中的快速是以保證交付質(zhì)量的前提，高效的流程和快速的變化響應(yīng)能夠極大地減輕人的心智負(fù)擔(dān)，遇到變化也能更及時(shí)地調(diào)整項(xiàng)目策略，這樣能促進(jìn)質(zhì)量的提升。

2)敏捷開(kāi)發(fā)應(yīng)當(dāng)拋棄文檔

? ?提倡攥寫(xiě)必要的文檔，不拘泥于格式，而是以提供清晰、易讀的信息為目標(biāo)。

3）敏捷開(kāi)發(fā)只適合小微團(tuán)隊(duì)

4）敏捷開(kāi)發(fā)淪為小瀑布開(kāi)發(fā)

5）敏捷是沒(méi)有約束的

6）DevOps就是CICD

7）堅(jiān)守固定的CICD流程

8）盲目從權(quán)威

建立度量體系

三層度量體系：

1）基礎(chǔ)能力層：完善基礎(chǔ)設(shè)施，通過(guò)對(duì)人和工具的指標(biāo)度量，促進(jìn)研發(fā)能力的增強(qiáng)，保障高效執(zhí)行；

2）產(chǎn)品交付層：以流動(dòng)效率為核心，關(guān)注過(guò)程指標(biāo)，致力于效率，產(chǎn)出和成本的平衡；

3）業(yè)務(wù)價(jià)值層：以業(yè)務(wù)目標(biāo)為核心，交付準(zhǔn)確，優(yōu)質(zhì)的產(chǎn)品，達(dá)到預(yù)期的業(yè)務(wù)結(jié)果（業(yè)務(wù)增長(zhǎng)，用戶(hù)數(shù)增加，等等）

度量的誤區(qū)：

1）”古德哈特定律“：當(dāng)決策者試圖以一個(gè)事物的客觀測(cè)量指標(biāo)作為指針來(lái)施行政策時(shí)，這一指標(biāo)就再也不能有效測(cè)量事物了。

2）構(gòu)建大而全的度量體系：從成本角度考慮，避免一開(kāi)始就構(gòu)建大而全的度量體系。度量是一項(xiàng)演進(jìn)式的工作需要各個(gè)角色的參與和討論，其在發(fā)展過(guò)程中也需要基礎(chǔ)設(shè)施的支持，很難在短期內(nèi)看到成效，而不切實(shí)際的企圖快速構(gòu)建一套大而全的度量體系的行為，通常會(huì)以失敗而告終。

度量的目標(biāo)是消除系統(tǒng)性瓶頸，這意味著我們?cè)谶M(jìn)行度量時(shí)始終要有全局性思維，下沉的同時(shí)要能夠回到山峰統(tǒng)攬全局。

DevOps

1、devOps六大武器

1）標(biāo)準(zhǔn)化作業(yè)

軟件流程在特定領(lǐng)域中是可以標(biāo)準(zhǔn)化的，標(biāo)準(zhǔn)化的最大好處是能夠固化流程，將人力從重復(fù)勞動(dòng)中解放出來(lái)，同時(shí)有效地減少錯(cuò)誤的發(fā)生。

2）快速失敗

盡可能在早期發(fā)現(xiàn)問(wèn)題并立刻失敗，避免問(wèn)題隱藏至后期，進(jìn)而增加解決成本。通過(guò)引入CI/CD技術(shù)，通過(guò)高頻集成和高頻交付，將問(wèn)題暴露在早期。

3）快速反應(yīng)

將業(yè)務(wù)決策以最快的速度轉(zhuǎn)換為技術(shù)產(chǎn)品，需要消除角色壁壘，盡可能用工具替代人力，并用流水線方式加速流程。

4）高質(zhì)量與高效率

通過(guò)持續(xù)部署，快速反饋的方式，更好地將不確定性逐步變?yōu)榇_定性，從而保障高質(zhì)量交付。

5）降低成本

當(dāng)devops模式運(yùn)作成熟，尤其是快速迭代的流水線初成規(guī)模后，軟件研發(fā)的效率將大大提升，研發(fā)成本將明顯降低，應(yīng)對(duì)變化的能力也將大幅提高。

6）團(tuán)隊(duì)協(xié)作

依靠工具和自動(dòng)化彌補(bǔ)開(kāi)發(fā)與運(yùn)維之間的技能鴻溝和溝通鴻溝，將軟件研發(fā)中的三個(gè)角色（開(kāi)開(kāi)發(fā)，測(cè)試，運(yùn)維）有效地粘合在一起，團(tuán)隊(duì)角色之間“有責(zé)無(wú)界”，為了更高的目標(biāo)通力協(xié)作。

2、DevOps生命周期精解

3、容器技術(shù)在DevOps中的應(yīng)用

4、混沌工程

基本思路：既然我們?cè)谑虑盁o(wú)法將軟件質(zhì)量的確定性測(cè)量出來(lái)，也無(wú)法避免突發(fā)故障的發(fā)生，那么就要接受系統(tǒng)一定會(huì)存在缺陷和發(fā)生故障的混沌態(tài)，通過(guò)一系列的演練頻繁暴露這些問(wèn)題，在不斷優(yōu)化和改進(jìn)軟件系統(tǒng)的同時(shí)，倒逼質(zhì)量?jī)?nèi)建和防御意識(shí)的提升，做到面向失敗設(shè)計(jì)。類(lèi)似打育苗。相關(guān)工具：ChaoBlade

5、DevSecOps

通過(guò)實(shí)踐DevSecOps可以更早地，有意識(shí)地將安全性融入軟件開(kāi)發(fā)全生命周期中。如果開(kāi)發(fā)組織從一開(kāi)始就將安全性考慮在代碼中，那么在漏洞進(jìn)入生產(chǎn)環(huán)境之前或發(fā)布之后，發(fā)現(xiàn)并修復(fù)漏洞會(huì)更容易，成本也更低。

AIOps

2016年，Gartner公司提出了AIOps，指的是 Algnorithmic IT Operations，是一種基于算法的運(yùn)維方式。2018年，AIOps由算法升級(jí)為智能，即Aritificial Intelligence for IT Operations。指整合大數(shù)據(jù)和機(jī)器學(xué)習(xí)能力，通過(guò)松耦合，可擴(kuò)展方式去提取和分析在數(shù)據(jù)量，種類(lèi)和速度三個(gè)維度不斷增長(zhǎng)的IT數(shù)據(jù)，為所有主流IT運(yùn)維管理產(chǎn)品提供支撐。AIOps平臺(tái)能夠同時(shí)使用多個(gè)數(shù)據(jù)源、數(shù)據(jù)采集方法及分析和展現(xiàn)技術(shù)，廣泛增強(qiáng)IT運(yùn)維流程和事件管理效率，可用于性能分析，異常檢測(cè)，事件關(guān)聯(lián)分析，IT服務(wù)管理和自動(dòng)化等應(yīng)用場(chǎng)景。

DevOps將軟件生命周期的工具全鏈路打通，結(jié)合自動(dòng)化和跨團(tuán)隊(duì)的線上協(xié)作能力，實(shí)現(xiàn)了快速響應(yīng)、高質(zhì)量交付及持續(xù)反饋。AIOps在企業(yè)運(yùn)營(yíng)和運(yùn)維工作中為成本、質(zhì)量、效率等方面的優(yōu)化提供了重要支撐。主張有機(jī)器學(xué)習(xí)算法自動(dòng)地從海里運(yùn)維數(shù)據(jù)中不斷地學(xué)習(xí)，不斷地提煉并總結(jié)規(guī)則。