DevOps的4個關(guān)鍵指標(biāo)，似乎已經(jīng)成為能解釋一切軟件開發(fā)生產(chǎn)力（或研發(fā)效能）問題的“北極星”指標(biāo)。

我們知道，收集每個指標(biāo)的數(shù)據(jù)，都需要投入成本，所以指標(biāo)不是多多益善，需要識別關(guān)鍵的北極星指標(biāo)。另外，當(dāng)北極星指標(biāo)沒有符合預(yù)期目標(biāo)時(shí)，也需要參考其他群星指標(biāo)，以便為團(tuán)隊(duì)提供當(dāng)時(shí)的上下文，識別合理的改進(jìn)時(shí)機(jī)（后文“如何識別度量數(shù)據(jù)中的改進(jìn)信號”會詳細(xì)討論如如何通過度量數(shù)據(jù)，識別改進(jìn)時(shí)機(jī)）。比如，當(dāng)生產(chǎn)環(huán)境某個用戶故事交貨時(shí)長這個北極星指標(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ū)動改進(jìn)，我們需要平衡式的指標(biāo)。

如果把DevOps的4個關(guān)鍵指標(biāo)當(dāng)作北極星指標(biāo)，那么這4個指標(biāo)屬于哪些維度？這些維度是否恰好能滿足為度量驅(qū)動改進(jìn)提供上下文，從而設(shè)計(jì)群星指標(biāo)？

DevOps的4個關(guān)鍵指標(biāo)，在一定程度上，體現(xiàn)了“流速快”和“質(zhì)量好”這兩個維度。即“生產(chǎn)環(huán)境業(yè)務(wù)系統(tǒng)部署頻率”和“生產(chǎn)環(huán)境用戶故事交貨時(shí)長”，體現(xiàn)了價(jià)值端到端流速是否快。因?yàn)榍罢咴礁?，流速越快；后者越短，流速越快。而“業(yè)務(wù)系統(tǒng)嚴(yán)重故障修復(fù)時(shí)長”和“業(yè)務(wù)系統(tǒng)發(fā)布用戶故事的嚴(yán)重故障率”，則體現(xiàn)了所交付的軟件產(chǎn)品質(zhì)量是否好。因?yàn)榍罢咴蕉蹋脩舾兄墓收蠒r(shí)長越短，質(zhì)量越好；后者越低，質(zhì)量越好。

為了找到用于提供改進(jìn)上下文的群星指標(biāo)，有些團(tuán)隊(duì)會將DevOps的4個關(guān)鍵指標(biāo)所涵蓋的“流速快”和“質(zhì)量好”這兩個維度的指標(biāo)進(jìn)行擴(kuò)充，增加了諸如“迭代完成率”（流速快）、“構(gòu)建時(shí)長”（流速快）、“代碼重復(fù)率”（質(zhì)量好）、“測試覆蓋率”（質(zhì)量好）等指標(biāo)，作為群星指標(biāo)。但增加了這些群星指標(biāo)后，能否恰好代表軟件開發(fā)生產(chǎn)力的關(guān)鍵要素？是否有遺漏？

我們知道，“個體與互動，高于流程和工具”，被放到了敏捷宣言的第一條。在敏捷項(xiàng)目中，“個體”與“互動”，能否作為代表軟件開發(fā)生產(chǎn)力的關(guān)鍵要素呢？當(dāng)度量軟件開發(fā)生產(chǎn)力時(shí)，有些團(tuán)隊(duì)是否遺漏了這兩個關(guān)鍵要素？

研究顯示，軟件開發(fā)生產(chǎn)力與開發(fā)者對于工作的滿意度和幸福指數(shù)高度相關(guān)（參見參考資料2和3）。

如何度量“個體”與“互動”呢？我們可以粗略地用開發(fā)者（本文所說的開發(fā)者，包括Dev、QA、BA、UX、Ops等各個角色）的工作幸福指數(shù)來度量“個體”，用會議成效、知識獲取和工具便利這些有關(guān)溝通協(xié)作的指標(biāo)來度量“互動”。

另外，軟件開發(fā)生產(chǎn)力的終極目標(biāo)，是滿足用戶價(jià)值。那么用戶對產(chǎn)品的滿意度，是不是就是有些團(tuán)隊(duì)所遺漏的第三個關(guān)鍵要素？

上面談到的被有些團(tuán)隊(duì)遺漏的3個關(guān)鍵要素，在GitHub、加拿大維多利亞大學(xué)和微軟研究院于2021年所聯(lián)合撰寫的文章The SPACE of Developer Productivity（八叉推薦，參見參考資料1）中獲得了印證。

這篇文章中所提到的SPACE，代表度量軟件開發(fā)生產(chǎn)力的5個維度——Satisfaction & well-being, Performance, Activity, Communication & collaboration, Efficiency & flow。這5個維度，大致可以一一對應(yīng)到本文所提到的下面5個度量維度——工作爽（幸福指數(shù)，Satisfaction & well-being）、協(xié)作佳（溝通協(xié)作，Communication & collaboration）、價(jià)值準(zhǔn)（價(jià)值成效，Performance）、流速快（價(jià)值流速，Efficiency & flow）、質(zhì)量好（過程產(chǎn)出，Activity）。

從下圖中能夠看出，如果僅局限于DevOps的4個關(guān)鍵指標(biāo)所涉及的那2個維度，來設(shè)計(jì)群星指標(biāo)，那么就會將“工作爽、協(xié)作佳和價(jià)值準(zhǔn)”這3個重要的維度遺漏掉。為什么這3個維度很重要？因?yàn)閳F(tuán)隊(duì)所交付的軟件產(chǎn)品，是要靠人這個“個體”，以及個體之間的“互動”來交付的。如果把DevOps的4個關(guān)鍵指標(biāo)所涉及的“流速快”和“質(zhì)量好”看作某種中間狀態(tài)的“果”，那么“個體”所對應(yīng)的“工作爽”，以及“互動”所對應(yīng)的“協(xié)作佳”這兩個維度，就是“因”。沒有“因”，哪來“果”呢？雖然在項(xiàng)目的中后期，“工作爽、協(xié)作佳”可以與“流速快、質(zhì)量好”互為因果，但在項(xiàng)目的初期，我們是可以通過規(guī)劃，讓“工作爽、協(xié)作佳”成為“因”的。最后那個“價(jià)值準(zhǔn)”維度，是所有4個維度的最終狀態(tài)的“果”，更值得我們關(guān)注。本著以終為始的原則，我們應(yīng)該在關(guān)注“流速快、質(zhì)量好”這兩個維度之前，先關(guān)注“價(jià)值準(zhǔn)”。

軟件開發(fā)生產(chǎn)力平衡式度量維度之間的關(guān)系

本文的目的，就是要找回這3個被遺漏的度量維度，并補(bǔ)充其他維度的一些重要的度量指標(biāo)，從而獲得一份平衡式的度量維度和指標(biāo)，進(jìn)而便于敏捷團(tuán)隊(duì)通過度量驅(qū)動改進(jìn)。注意，下面的5個指標(biāo)維度，相對完整。但每個維度下的指標(biāo)，并沒有包括全部指標(biāo)，團(tuán)隊(duì)需要根據(jù)自身實(shí)際情況，進(jìn)行取舍。

平衡式的度量指標(biāo)

維度1：工作爽（幸福指數(shù)）

指標(biāo)1：開發(fā)者對于工作的幸福指數(shù)。

工作幸福指數(shù)越高，軟件開發(fā)生產(chǎn)力就越高。

可以每周問每位開發(fā)者：“如果從0到10打分，你向其他開發(fā)者推薦入職我司做開發(fā)工作的可能性有多大？”

維度2：協(xié)作佳（溝通協(xié)作）

指標(biāo)2：開發(fā)者對于會議成效的滿意度。

會議越有成效，溝通協(xié)作就越好，軟件開發(fā)生產(chǎn)力就越高。

可以每周問每位開發(fā)者：“如果從0到10打分，你對本周所參與的所有會議的成效的綜合滿意度打幾分？”

指標(biāo)3：開發(fā)者對于知識獲取的滿意度

獲取所需知識（包括文檔質(zhì)量和知識分享）越便利，軟件開發(fā)生產(chǎn)力就越高。

可以每周問每位開發(fā)者：“如果從0到10打分，你對本周獲取知識的便利情況（包括文檔質(zhì)量和知識分享）的綜合滿意度打幾分？”

指標(biāo)4：開發(fā)者對于工具及工具平臺的滿意度

工欲善其事，必先利其器。溝通協(xié)作所需工具越趁手，軟件開發(fā)生產(chǎn)力就越高。

可以每周問每位開發(fā)者：“如果從0到10打分，你對本周使用工具及工具平臺的便利情況的綜合滿意度打幾分？”

維度3：價(jià)值準(zhǔn)（價(jià)值成效）

指標(biāo)5：用戶對產(chǎn)品的滿意度

用戶對產(chǎn)品越滿意，說明軟件開發(fā)生產(chǎn)力成效就越高。

可以每月問用戶代表：“如果從0到10打分，你向他人推薦使用這款產(chǎn)品的可能性有多大？”

維度4：流速快（價(jià)值流速）

指標(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)部署頻率越高，能間接反映自動化回歸測試、特性開關(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í)長有多長？”

指標(biāo)7：生產(chǎn)環(huán)境用戶故事交貨時(shí)長

生產(chǎn)環(huán)境用戶故事交貨時(shí)長越短，說明用戶故事拆分越合理，中間返工少，工序間等待少，軟件開發(fā)生產(chǎn)力就越高。

可以每次投產(chǎn)上線后，請運(yùn)維人員統(tǒng)計(jì)本次成功投產(chǎn)上線的所有用戶故事的交貨時(shí)長，即從提交第一行代碼到代碼庫到成功投產(chǎn)上線之間的時(shí)長。

指標(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測試后，請測試人員記錄該故事所經(jīng)歷的SIT測試次數(shù)。

指標(biāo)9：并行工作數(shù)（Work-In-Progress, WIP）

開發(fā)者每日并行的工作越少，工作切換所消耗的時(shí)間就越少，軟件開發(fā)生產(chǎn)力就越高。

可以每日問每位開發(fā)者：“當(dāng)天手中并行安排了幾個工作？”

維度5：質(zhì)量好（過程產(chǎn)出）

指標(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)重故障后，請運(yùn)維人員統(tǒng)計(jì)修復(fù)時(shí)長，即從故障出現(xiàn)（而非發(fā)現(xiàn)）到成功修復(fù)或回滾之間的時(shí)長。

指標(biāo)11：業(yè)務(wù)系統(tǒng)發(fā)布用戶故事的嚴(yán)重故障率

業(yè)務(wù)系統(tǒng)發(fā)布用戶故事的嚴(yán)重故障率越低，說明所發(fā)布的用戶故事質(zhì)量越好，軟件開發(fā)生產(chǎn)力就越高。

可以在每次投產(chǎn)上線后，請運(yùn)維人員統(tǒng)計(jì)本次投產(chǎn)的用戶故事中無法正常使用的比例。

指標(biāo)12：通過代碼評審的commit比例

通過代碼評審的commit比例越高，或許能反映代碼質(zhì)量會更好（取決于開發(fā)者的整潔代碼意識和代碼評審質(zhì)量）。

可以在每個迭代結(jié)束前，請每位開發(fā)者統(tǒng)計(jì)自己提交到主干的commit中，通過代碼評審的比例。

指標(biāo)13：迭代回歸測試案例執(zhí)行率

迭代回歸測試案例執(zhí)行率越高，或許能反映業(yè)務(wù)系統(tǒng)已有功能的缺陷就越少（取決于回歸測試覆蓋關(guān)鍵業(yè)務(wù)場景的質(zhì)量）。

可以在每個迭代結(jié)束前，請測試人員統(tǒng)計(jì)迭代實(shí)際執(zhí)行的回歸測試案例，占本應(yīng)執(zhí)行的比例。

指標(biāo)14：迭代回歸測試執(zhí)行時(shí)長

該指標(biāo)需要與“迭代回歸測試案例執(zhí)行率”結(jié)合起來看，當(dāng)“迭代回歸測試案例執(zhí)行率”為100%，且使用了自動化回歸測試，那么迭代回歸測試執(zhí)行時(shí)長越短，能間接表明軟件開發(fā)生產(chǎn)力就越高。

可以在每個迭代結(jié)束前，請測試人員統(tǒng)計(jì)本迭代回歸測試執(zhí)行時(shí)長。

總結(jié)

度量軟件開發(fā)生產(chǎn)力的指標(biāo)維度和數(shù)量，需要取得平衡，既要少到能恰好代表軟件開發(fā)生產(chǎn)力關(guān)鍵要素，也要多到恰好能提供用于持續(xù)改進(jìn)的上下文。只使用DevOps的4個關(guān)鍵指標(biāo)，而忽視“工作爽、協(xié)作佳和價(jià)值準(zhǔn)”這3個維度，會導(dǎo)致團(tuán)隊(duì)僅關(guān)注“流速快”和“質(zhì)量好”這兩個中間狀態(tài)的“果”，而失去對“工作爽、協(xié)作佳”這兩個“因”的關(guān)注，且失去對用戶滿意度這樣的最終狀態(tài)的“果”的關(guān)注，無法看到軟件開發(fā)生產(chǎn)力的全貌，也就難以用度量驅(qū)動改進(jìn)。

相關(guān)參考資料

1. The SPACE of Developer Productivity; March 6, 2021; https://queue.acm.org/detail.cfm?id=3454124
2. Graziotin, D., Fagerholm, F. 2019. Happiness and the productivity of software engineers. In Rethinking Productivity in Software Engineering, ed. C. Sadowski and T. Zimmermann, 109-124. Berkeley, CA: Apress; https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_10.
3. Storey, M. A., Zimmermann, T., Bird, C., Czerwonka, J., Murphy, B., Kalliamvakou, E. 2019. Towards a theory of software developer job satisfaction and perceived productivity. IEEE Transactions on Software Engineering; https://ieeexplore.ieee.org/document/8851296.