建站
咨詢
售后
建站咨詢
新聞中心
作者 | 吾真本
創(chuàng)新互聯(lián)專注于網(wǎng)站建設(shè)，為客戶提供成都做網(wǎng)站、成都網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)開發(fā)服務(wù)，多年建網(wǎng)站服務(wù)經(jīng)驗(yàn)，各類網(wǎng)站都可以開發(fā)，品牌網(wǎng)站設(shè)計(jì)，公司官網(wǎng)，公司展示網(wǎng)站，網(wǎng)站設(shè)計(jì)，建網(wǎng)站費(fèi)用，建網(wǎng)站多少錢，價(jià)格優(yōu)惠，收費(fèi)合理。
DevOps的4個(gè)關(guān)鍵指標(biāo)（4 key metrics），似乎已經(jīng)成為能解釋一切軟件開發(fā)生產(chǎn)力（或研發(fā)效能）問題的“北極星”指標(biāo)。
我們知道，收集每個(gè)指標(biāo)的數(shù)據(jù)，都需要投入成本，所以指標(biāo)不是多多益善，需要識(shí)別關(guān)鍵的北極星指標(biāo)。另外，當(dāng)北極星指標(biāo)沒有符合預(yù)期目標(biāo)時(shí)，也需要參考其他群星指標(biāo)，以便為團(tuán)隊(duì)提供當(dāng)時(shí)的上下文，識(shí)別合理的改進(jìn)時(shí)機(jī)。
比如，當(dāng)生產(chǎn)環(huán)境某個(gè)用戶故事交貨時(shí)長這個(gè)北極星指標(biāo)很長時(shí)，可以看看該“用戶故事所經(jīng)歷的SIT測試次數(shù)”是否多，來了解這是否因?yàn)榉倒ざ鄬?dǎo)致的。如果不是，那么再看看是否用戶故事拆分粒度可以優(yōu)化，等等。
所以，指標(biāo)數(shù)量和維度需要取得平衡，既要少到能恰好代表軟件開發(fā)生產(chǎn)力關(guān)鍵要素，也要多到恰好能提供用于持續(xù)改進(jìn)的上下文。為了更好地用度量驅(qū)動(dòng)改進(jìn)，我們需要平衡式的指標(biāo)。
要設(shè)計(jì)平衡式的指標(biāo)，首先要確定平衡式的指標(biāo)所應(yīng)涵蓋的維度。
DevOps 4個(gè)關(guān)鍵指標(biāo)的維度
可以先看看DevOps的4個(gè)關(guān)鍵指標(biāo)屬于哪些維度，然后思考這些維度是否恰好能滿足為度量驅(qū)動(dòng)改進(jìn)提供上下文。如果不能完全滿足，再尋找被遺漏的度量維度，并設(shè)計(jì)對(duì)應(yīng)的群星指標(biāo)。
DevOps的4個(gè)關(guān)鍵指標(biāo)，在一定程度上，體現(xiàn)了“流速快”和“質(zhì)量好”這兩個(gè)維度。
“生產(chǎn)環(huán)境業(yè)務(wù)系統(tǒng)部署頻率”和“生產(chǎn)環(huán)境用戶故事交貨時(shí)長”，體現(xiàn)了價(jià)值端到端流速是否快。因?yàn)榍罢咴礁?，流速越快；后者越短，流速越快?/p>
“業(yè)務(wù)系統(tǒng)嚴(yán)重故障修復(fù)時(shí)長”和“業(yè)務(wù)系統(tǒng)發(fā)布用戶故事的嚴(yán)重故障率”，則體現(xiàn)了所交付的軟件產(chǎn)品質(zhì)量是否好。因?yàn)榍罢咴蕉?，用戶感知的故障時(shí)長越短，質(zhì)量越好；后者越低，質(zhì)量越好。
被遺漏的群星指標(biāo)的維度
為了找到用于提供改進(jìn)上下文的群星指標(biāo)，有些團(tuán)隊(duì)會(huì)將DevOps的4個(gè)關(guān)鍵指標(biāo)所涵蓋的“流速快”和“質(zhì)量好”這兩個(gè)維度的指標(biāo)進(jìn)行擴(kuò)充，增加了諸如“迭代完成率”（流速快）、“構(gòu)建時(shí)長”（流速快）、“代碼重復(fù)率”（質(zhì)量好）、“測試覆蓋率”（質(zhì)量好）等指標(biāo)，作為群星指標(biāo)。但增加了這些群星指標(biāo)后，能否恰好代表軟件開發(fā)生產(chǎn)力的關(guān)鍵要素？是否有遺漏？
我們知道，“個(gè)體與互動(dòng)，高于流程和工具”，被放到了敏捷宣言的第一條。在敏捷項(xiàng)目中，反映個(gè)人自身的“個(gè)體”，與反映團(tuán)隊(duì)成員之間協(xié)作的“互動(dòng)”，能否作為代表軟件開發(fā)生產(chǎn)力的關(guān)鍵要素呢？當(dāng)度量軟件開發(fā)生產(chǎn)力時(shí)，有些團(tuán)隊(duì)是否遺漏了這兩個(gè)要素及其所對(duì)應(yīng)的維度？
研究顯示，軟件開發(fā)生產(chǎn)力與開發(fā)者對(duì)于工作的滿意度和幸福指數(shù)高度相關(guān)（參見參考資料2和3）。
如果團(tuán)隊(duì)忽視其成員的工作“幸福感”，不僅有損生產(chǎn)力，還會(huì)使人離心離德，導(dǎo)致背叛。當(dāng)下熱門動(dòng)漫《中國奇譚》第一集“小妖怪的夏天“中所講述的故事，就生動(dòng)地描繪了這一場景。在“大王洞”打工的小豬妖，用伙伴烏鴉怪的羽毛制作弓箭搞技術(shù)革新，但卻被熊教頭看作是“無視上級(jí)”而罰去重做；被熊教頭當(dāng)作豬鬃刷子刷鍋，導(dǎo)致毛發(fā)變禿；目睹了伙伴烏鴉怪因?yàn)橥悼戳舜笸醪贾玫淖侥锰粕南葳?，而慘遭大王毒手。這些遭遇讓他完全喪失了工作的“幸福感”，最后冒著生命危險(xiǎn)，棄暗投明，阻止了唐僧師徒四人落入大王設(shè)下的陷阱。
如何度量“個(gè)體”與“互動(dòng)”呢？我們可以粗略地用開發(fā)者（本文所說的開發(fā)者，包括Dev、QA、BA、UX、Ops等各個(gè)角色）的工作幸福指數(shù)來度量“個(gè)體”，用會(huì)議成效、知識(shí)獲取和工具便利這些有關(guān)溝通協(xié)作的指標(biāo)來度量“互動(dòng)”。
另外，軟件開發(fā)生產(chǎn)力的終極目標(biāo)，是滿足用戶價(jià)值。那么用戶對(duì)產(chǎn)品的滿意度，是不是就是有些團(tuán)隊(duì)所遺漏的第三個(gè)關(guān)鍵要素及其所對(duì)應(yīng)的維度？
平衡式度量指標(biāo)的5個(gè)維度
上面談到的被有些團(tuán)隊(duì)遺漏的3個(gè)關(guān)鍵要素及其所對(duì)應(yīng)的維度，在GitHub、加拿大維多利亞大學(xué)和微軟研究院于2021年所聯(lián)合撰寫的文章The SPACE of Developer Productivity（參見參考資料1）中獲得了印證。
這篇文章中所提到的SPACE，代表度量軟件開發(fā)生產(chǎn)力的5個(gè)維度——Satisfaction & well-being, Performance, Activity, Communication & collaboration, Efficiency & flow。這5個(gè)維度，大致可以一一對(duì)應(yīng)到本文所提到的下面5個(gè)度量維度——幸福感（幸福指數(shù)，Satisfaction & well-being）、協(xié)作佳（溝通協(xié)作，Communication & collaboration）、價(jià)值準(zhǔn)（價(jià)值成效，Performance）、流速快（價(jià)值流速，Efficiency & flow）、質(zhì)量好（過程產(chǎn)出，Activity）。
從下圖中能夠看出，如果僅局限于DevOps的4個(gè)關(guān)鍵指標(biāo)所涉及的那2個(gè)維度，來設(shè)計(jì)群星指標(biāo)，那么就會(huì)將“幸福感、協(xié)作佳和價(jià)值準(zhǔn)”這3個(gè)重要的維度遺漏掉。為什么這3個(gè)維度很重要？因?yàn)閳F(tuán)隊(duì)所交付的軟件產(chǎn)品，是要靠人這個(gè)“個(gè)體”，以及個(gè)體之間的“互動(dòng)”來交付的。如果把DevOps的4個(gè)關(guān)鍵指標(biāo)所涉及的“流速快”和“質(zhì)量好”看作某種中間狀態(tài)的“果”，那么“個(gè)體”所對(duì)應(yīng)的“幸福感”，以及“互動(dòng)”所對(duì)應(yīng)的“協(xié)作佳”這兩個(gè)維度，就是“因”。沒有“因”，哪來“果”呢？雖然在項(xiàng)目的中后期，“幸福感、協(xié)作佳”可以與“流速快、質(zhì)量好”互為因果，但在項(xiàng)目的初期，我們是可以通過規(guī)劃，讓“幸福感、協(xié)作佳”成為“因”的。最后那個(gè)“價(jià)值準(zhǔn)”維度，是所有4個(gè)維度的最終狀態(tài)的“果”，更值得我們關(guān)注。本著以終為始的原則，我們應(yīng)該在關(guān)注“流速快、質(zhì)量好”這兩個(gè)維度之前，先關(guān)注“價(jià)值準(zhǔn)”。
圖：軟件開發(fā)生產(chǎn)力平衡式度量維度之間的關(guān)系
本文的目的，就是要找回這3個(gè)被遺漏的度量維度，并補(bǔ)充其他維度的一些重要的度量指標(biāo)，從而獲得一份平衡式的度量維度和指標(biāo)，進(jìn)而便于敏捷團(tuán)隊(duì)通過度量驅(qū)動(dòng)改進(jìn)。注意，下面的5個(gè)指標(biāo)維度，相對(duì)完整。但每個(gè)維度下的指標(biāo)，并沒有包括全部指標(biāo)，團(tuán)隊(duì)需要根據(jù)自身實(shí)際情況，進(jìn)行取舍。
平衡式的度量指標(biāo)
維度1：幸福感（幸福指數(shù)）
(1) 指標(biāo)1：開發(fā)者對(duì)于工作的幸福指數(shù)。
工作幸福指數(shù)越高，軟件開發(fā)生產(chǎn)力就越高。
可以每周問每位開發(fā)者：“如果從0到10打分，你向其他開發(fā)者推薦入職我司做開發(fā)工作的可能性有多大？”
維度2：協(xié)作佳（溝通協(xié)作）
(2) 指標(biāo)2：開發(fā)者對(duì)于會(huì)議成效的滿意度。
會(huì)議越有成效，溝通協(xié)作就越好，軟件開發(fā)生產(chǎn)力就越高。
可以每周問每位開發(fā)者：“如果從0到10打分，你對(duì)本周所參與的所有會(huì)議的成效的綜合滿意度打幾分？”
(3) 指標(biāo)3：開發(fā)者對(duì)于知識(shí)獲取的滿意度
獲取所需知識(shí)（包括文檔質(zhì)量和知識(shí)分享）越便利，軟件開發(fā)生產(chǎn)力就越高。
可以每周問每位開發(fā)者：“如果從0到10打分，你對(duì)本周獲取知識(shí)的便利情況（包括文檔質(zhì)量和知識(shí)分享）的綜合滿意度打幾分？”
(4) 指標(biāo)4：開發(fā)者對(duì)于工具及工具平臺(tái)的滿意度
工欲善其事，必先利其器。溝通協(xié)作所需工具越趁手，軟件開發(fā)生產(chǎn)力就越高。
可以每周問每位開發(fā)者：“如果從0到10打分，你對(duì)本周使用工具及工具平臺(tái)的便利情況的綜合滿意度打幾分？”
維度3：價(jià)值準(zhǔn)（價(jià)值成效）
(5) 指標(biāo)5：用戶對(duì)產(chǎn)品的滿意度
用戶對(duì)產(chǎn)品越滿意，說明軟件開發(fā)生產(chǎn)力成效就越高。
可以每月問用戶代表：“如果從0到10打分，你向他人推薦使用這款產(chǎn)品的可能性有多大？”
維度4：流速快（價(jià)值流速）
(6) 指標(biāo)6：生產(chǎn)環(huán)境業(yè)務(wù)系統(tǒng)部署頻率
當(dāng)部署與發(fā)布不分離時(shí)，生產(chǎn)環(huán)境業(yè)務(wù)系統(tǒng)部署頻率越高，說明業(yè)務(wù)能更小批地部署上線，這樣能更早地將業(yè)務(wù)價(jià)值交付給用戶，軟件開發(fā)生產(chǎn)力就越高。
當(dāng)部署與發(fā)布分離時(shí)，生產(chǎn)環(huán)境業(yè)務(wù)系統(tǒng)部署頻率越高，能間接反映自動(dòng)化回歸測試、特性開關(guān)、藍(lán)綠部署等機(jī)制更強(qiáng)，軟件開發(fā)生產(chǎn)力就越高。
可以每次生產(chǎn)環(huán)境部署時(shí)，問運(yùn)維人員：“業(yè)務(wù)系統(tǒng)生產(chǎn)環(huán)境本次部署距上次部署之間的間隔時(shí)長有多長？”
(7) 指標(biāo)7：生產(chǎn)環(huán)境用戶故事交貨時(shí)長
生產(chǎn)環(huán)境用戶故事交貨時(shí)長越短，說明用戶故事拆分越合理，中間返工少，工序間等待少，軟件開發(fā)生產(chǎn)力就越高。
可以每次投產(chǎn)上線后，請(qǐng)運(yùn)維人員統(tǒng)計(jì)本次成功投產(chǎn)上線的所有用戶故事的交貨時(shí)長，即從提交第一行代碼到代碼庫到成功投產(chǎn)上線之間的時(shí)長。
(8) 指標(biāo)8：用戶故事所經(jīng)歷的SIT測試次數(shù)
開發(fā)者在修復(fù)SIT測試階段所發(fā)現(xiàn)的用戶故事缺陷后，還應(yīng)該再次提交給QA在SIT階段驗(yàn)證。用戶故事所經(jīng)歷的SIT測試次數(shù)越少，說明該故事開卡驗(yàn)卡等質(zhì)量內(nèi)建做得好，返工少，軟件開發(fā)生產(chǎn)力就越高。
可以在每次用戶故事通過了SIT測試后，請(qǐng)測試人員記錄該故事所經(jīng)歷的SIT測試次數(shù)。
(9) 指標(biāo)9：并行工作數(shù)（Work-In-Progress, WIP）
開發(fā)者每日并行的工作越少，工作切換所消耗的時(shí)間就越少，軟件開發(fā)生產(chǎn)力就越高。
可以每日問每位開發(fā)者：“當(dāng)天手中并行安排了幾個(gè)工作？”
維度5：質(zhì)量好（過程產(chǎn)出）
(10) 指標(biāo)10：業(yè)務(wù)系統(tǒng)嚴(yán)重故障修復(fù)時(shí)長
業(yè)務(wù)系統(tǒng)嚴(yán)重故障修復(fù)時(shí)長越短，可以間接反映生產(chǎn)環(huán)境系統(tǒng)運(yùn)行觀測能力越強(qiáng)，故障響應(yīng)、切換和回滾機(jī)制越強(qiáng)，軟件開發(fā)生產(chǎn)力就越高。
可以每次解決完生產(chǎn)環(huán)境的嚴(yán)重故障后，請(qǐng)運(yùn)維人員統(tǒng)計(jì)修復(fù)時(shí)長，即從故障出現(xiàn)（而非發(fā)現(xiàn)）到成功修復(fù)或回滾之間的時(shí)長。
(11) 指標(biāo)11：業(yè)務(wù)系統(tǒng)發(fā)布用戶故事的嚴(yán)重故障率
業(yè)務(wù)系統(tǒng)發(fā)布用戶故事的嚴(yán)重故障率越低，說明所發(fā)布的用戶故事質(zhì)量越好，軟件開發(fā)生產(chǎn)力就越高。
可以在每次投產(chǎn)上線后，請(qǐng)運(yùn)維人員統(tǒng)計(jì)本次投產(chǎn)的用戶故事中無法正常使用的比例。
(12) 指標(biāo)12：通過代碼評(píng)審的commit比例
通過代碼評(píng)審的commit比例越高，或許能反映代碼質(zhì)量會(huì)更好（取決于開發(fā)者的整潔代碼意識(shí)和代碼評(píng)審質(zhì)量）。
可以在每個(gè)迭代結(jié)束前，請(qǐng)每位開發(fā)者統(tǒng)計(jì)自己提交到主干的commit中，通過代碼評(píng)審的比例。
(13) 指標(biāo)13：迭代回歸測試案例執(zhí)行率
迭代回歸測試案例執(zhí)行率越高，或許能反映業(yè)務(wù)系統(tǒng)已有功能的缺陷就越少（取決于回歸測試覆蓋關(guān)鍵業(yè)務(wù)場景的質(zhì)量）。
可以在每個(gè)迭代結(jié)束前，請(qǐng)測試人員統(tǒng)計(jì)迭代實(shí)際執(zhí)行的回歸測試案例，占本應(yīng)執(zhí)行的比例。
(14) 指標(biāo)14：迭代回歸測試執(zhí)行時(shí)長
該指標(biāo)需要與“迭代回歸測試案例執(zhí)行率”結(jié)合起來看，當(dāng)“迭代回歸測試案例執(zhí)行率”為100%，且使用了自動(dòng)化回歸測試，那么迭代回歸測試執(zhí)行時(shí)長越短，能間接表明軟件開發(fā)生產(chǎn)力就越高。
可以在每個(gè)迭代結(jié)束前，請(qǐng)測試人員統(tǒng)計(jì)本迭代回歸測試執(zhí)行時(shí)長。
總結(jié)
度量軟件開發(fā)生產(chǎn)力的指標(biāo)維度和數(shù)量，需要取得平衡，既要少到能恰好代表軟件開發(fā)生產(chǎn)力關(guān)鍵要素，也要多到恰好能提供用于持續(xù)改進(jìn)的上下文。只使用DevOps的4個(gè)關(guān)鍵指標(biāo)，而忽視“幸福感、協(xié)作佳和價(jià)值準(zhǔn)”這3個(gè)維度，會(huì)導(dǎo)致團(tuán)隊(duì)僅關(guān)注“流速快”和“質(zhì)量好”這兩個(gè)中間狀態(tài)的“果”，而失去對(duì)“幸福感、協(xié)作佳”這兩個(gè)“因”的關(guān)注，且失去對(duì)用戶滿意度這樣的最終狀態(tài)的“果”的關(guān)注，無法看到軟件開發(fā)生產(chǎn)力的全貌，也就難以用度量驅(qū)動(dòng)改進(jìn)。
分享名稱：被遺漏的度量指標(biāo)
網(wǎng)頁網(wǎng)址：http://m.5511xx.com/article/cocodoj.html
