除了感性的工作體驗外，我們還需要指標(biāo)來度量改進(jìn)措施是否對提升軟件交付效能有幫助。過多的指標(biāo)會對團(tuán)隊造成不必要的管理成本，也容易讓團(tuán)隊失去關(guān)注焦點。從吞吐量和穩(wěn)定性兩個維度考量的四個關(guān)鍵指標(biāo)是簡單但有效的指標(biāo)，建議優(yōu)先度量。
為了提升軟件交付效能，你的團(tuán)隊或組織可能已經(jīng)開始采取行動，引入敏捷方法、DevOps實踐甚至還有架構(gòu)重構(gòu)。但你如何知道這些改進(jìn)措施起了作用呢，或者它們壓根就水土不服呢？簡單來說，除了感性的工作體驗外，你需要一些指標(biāo)來度量交付效能。
唯快不破
提升交付效能的最重要的目標(biāo)之一就是能"快起來"，那么如何定義"快"呢？我們更傾向于度量吞吐量，吞吐量是指單位時間內(nèi)團(tuán)隊完成的工作量。
- 變更前置時間
Lead Time for Changes，變更前置時間指的是開始編碼到部署所耗費的時間。如果變更前置時間過長，可能意味著開發(fā)或部署過程的某些環(huán)節(jié)出現(xiàn)了問題或阻礙。這是一個典型的吞吐量指標(biāo)，更強(qiáng)調(diào)的是對于單個用戶故事/用例需要花費多長時間才能獲得實際反饋。
我之前受邀參與某個項目，當(dāng)時團(tuán)隊的直觀感受是進(jìn)度滯后。通過度量變更前置時間，我們發(fā)現(xiàn)用戶故事從進(jìn)入"開發(fā)中"到"準(zhǔn)備QA測試"(意味著開發(fā)同事已經(jīng)完成了開發(fā)并按照驗收標(biāo)準(zhǔn)進(jìn)行了自行驗證)的中位數(shù)時間是4.5天，這意味著近一半的用戶故事在一個工作周內(nèi)都不會得到有效的反饋，而在一周之后往往可以"驚喜"地發(fā)現(xiàn)實現(xiàn)方案有問題，需要返工。因此，我們把降低變更前置時間、增加吞吐量作為目標(biāo)，幫助業(yè)務(wù)分析師和Tech Leader在保證 INVEST原則! 的情況下進(jìn)一步拆分故事卡作為手段，在三周之后將變更前置時間的中位數(shù)降低到2.5天。雖然更細(xì)粒度的故事卡帶來了更頻繁的開卡、關(guān)卡活動，看似造成了更多的工作量，但由此帶來的頻繁交流和目標(biāo)拉通，降低了返工的可能，使得項目進(jìn)度逐漸恢復(fù)正常。
- 部署頻率
Deployment Frequency，部署頻率，我認(rèn)為這是吐吞量的另一種度量方式，更頻繁的部署往往意味著單次部署包含的變更更少，但對于某個特性來說，可以更快地獲得產(chǎn)生價值，獲得實際反饋。而且，同變更前置時間相比，部署頻率往往更直接地意味著團(tuán)隊/組織在工程實踐方面有著良好的理解和應(yīng)用。
唯快不破，并非只強(qiáng)調(diào)快
我曾經(jīng)在一家傳統(tǒng)企業(yè)工作，在沒有敏捷方法和工程實踐加持的情況下，我們也做到了每周一次發(fā)布。但幾乎每次發(fā)布后，隨之而來的是緊急發(fā)布，以修復(fù)發(fā)布后出現(xiàn)的各種問題。在一次對客服中心的拜訪中，我了解到客服部門對IT部門的每周發(fā)布并沒有什么好感，因為每次發(fā)布后都如臨大敵，客戶投訴可能呼嘯而至。因此，我們在追求“快”的同時，還得保住“穩(wěn)”，否則頻繁出現(xiàn)故障的使用體驗，甚至?xí)窒焖賱?chuàng)新的努力。
那么，我們應(yīng)該關(guān)注哪些“穩(wěn)定性”指標(biāo)呢？
- 變更失敗率
Change Fail Rate，變更失敗率是指發(fā)生變更后出現(xiàn)故障的幾率。理論上來說，當(dāng)我們引入敏捷方法和DevOps實踐快速迭代時，隨著時間的推移和實踐及工具的成熟，單次部署/發(fā)布包含的變更項會逐漸減少，由此變更失敗率也會最終降低。因此，如果變更失敗率居高不下，可能意味著在過程或工程實踐中出現(xiàn)了某些問題或阻礙
- 服務(wù)恢復(fù)耗時
Time to restore service，服務(wù)恢復(fù)耗時是指當(dāng)服務(wù)中斷或降級后，需要花費多少時間將服務(wù)恢復(fù)正常。每次部署包含的變更多寡、技術(shù)債務(wù)堆積程度對該指標(biāo)有一定影響，但將該指標(biāo)放在這里有一些爭議，因為在一些合作模式中，造成故障的部分原因或修復(fù)措施并不在交付團(tuán)隊的工作范圍內(nèi)（例如基礎(chǔ)設(shè)施）。
為什么優(yōu)先度量這些指標(biāo)
讀到這里，你可能會發(fā)現(xiàn)以上四個關(guān)鍵指標(biāo)來自于一份業(yè)界知名的DevOps報告，為什么在度量交付效能的時候，要優(yōu)先考慮DevOps指標(biāo)呢？
在19年4月的技術(shù)雷達(dá)中，是這樣回答的：
研究人員證實，只需四個關(guān)鍵指標(biāo)就能區(qū)分低績效、中績效和高績效人員：前置時間、部署頻率、平
均修復(fù)時間(MTTR)和變更失敗率。的確，我們已經(jīng)發(fā)現(xiàn)這四個關(guān)鍵指標(biāo)是個簡單卻強(qiáng)大的工具，可幫助領(lǐng)導(dǎo)和團(tuán)隊專注于衡量并改進(jìn)重要的環(huán)節(jié)。
從另一個角度來說，這四個指標(biāo)距離客戶的直觀感受更接近，這意味著它們更能體現(xiàn)真實的價值。同樣的情況可以參考應(yīng)用監(jiān)控，在《Practical Monitoring》一書中，作者極力推薦優(yōu)先從用戶視角建立監(jiān)控指標(biāo)，這比底層指標(biāo)更容易得出結(jié)論：例如響應(yīng)延遲，是用戶是能感受到的，延遲升高了可能意味著出現(xiàn)問題，但CPU使用率用戶是感受不到的，其增高也未必說明問題，可能有些應(yīng)用運行在高負(fù)載CPU是常態(tài)。
最后則是從成本考慮，避免在一開始的時候就規(guī)劃并實施一個大而全的度量體系，從而付出不必要的管理成本
度量需要投入團(tuán)隊的時間，項目管理人員的時間，質(zhì)量保障人員的時 間，以及公司管理人員的時間，還可能會有工具和基礎(chǔ)設(shè)施的投入。圍繞 各種目標(biāo)需要度量體系的設(shè)計和實施，體系的運轉(zhuǎn)需要數(shù)據(jù)的收集、分析 和匯報，這些環(huán)節(jié)做得不到位是不可能產(chǎn)生預(yù)期效果的，而要做到位，所 需的投入可能并不是一個可以忽略的小數(shù)目。因此，目標(biāo)和指標(biāo)的選擇就 顯得特別重要，試圖實施一個大而全的度量體系，通常弊大于利。（《精益軟件度量》，”度量不是什么“章節(jié)）
診斷型指標(biāo)
如果說以上四個關(guān)鍵指標(biāo)告訴我們的是交付效能的變化趨勢，那么下一步，我們可以尋找更細(xì)粒度的指標(biāo)來告訴我們?nèi)绾芜M(jìn)一步改進(jìn)它們。
之前的四個關(guān)鍵指標(biāo)更像體溫計，它們可以快速地反映現(xiàn)在是否健康，但它們不能告訴我們病因。接下來我們需要的是驗血報告，報告中有很多明細(xì)的指標(biāo)，單個指標(biāo)或許并不能說明什么，但若干異常指標(biāo)的組合在一起往往可以幫助醫(yī)生判斷病灶，或許可以將這些明細(xì)指標(biāo)稱作"診斷型"指標(biāo)。
常見的"診斷型"指標(biāo)包括但不限于:
- 平均構(gòu)建時間
- 測試覆蓋率
- 代碼圈復(fù)雜度
- 團(tuán)隊速率
以上這些(以及更多其他)指標(biāo)從代碼復(fù)雜度、測試策略、基礎(chǔ)設(shè)施水平等更"底層"的維度解釋交付效能健康或不健康的原因，它們可以幫助團(tuán)隊在做出進(jìn)一步針對性的改進(jìn)。
總結(jié)
- 除了感性的工作體驗外，我們還需要指標(biāo)來度量改進(jìn)措施是否對提升軟件交付效能有幫助。
- 過多的指標(biāo)會對團(tuán)隊造成不必要的管理成本，也容易讓團(tuán)隊失去關(guān)注焦點。
- 從吞吐量和穩(wěn)定性兩個維度考量的四個關(guān)鍵指標(biāo)是簡單但有效的指標(biāo)，建議優(yōu)先度量。
參考
- Accelerate: State of DevOps 2018 Strategies for a New Economy, By DevOps Research & Assessment
- https://www.thoughtworks.com/cn/radar/techniques/four-key-metrics
- Practical Monitoring, By (author) Mike Julian
- 《精益軟件度量》，作者: 張松
文/ThoughtWorks周宇剛
