這是鼎叔的第一百一十五篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本專欄和微信公眾號《敏捷測試轉型》，星標收藏，大量原創思考文章陸續推出。本人新書《無測試組織 - 測試團隊的敏捷轉型》已出版（機械工業出版社）。
前文聊聊效能度量的作弊經濟學 ，列舉了傳統度量的問題和對於度量的種種誤解，讓我們結合敏捷理念的深入理解，看看該如何設計基於敏捷的度量指標體系。
敏捷度量體系的特質
面向敏捷團隊，度量工作要能真正被支援，推動大家往前跑，其體系應該具備這樣一些特質。
公開性和簡潔性：在公開的區域，用醒目的格式，讓大家一眼就看就清楚，字面意思能自解釋，這樣才能被所有成員關注。記憶負擔和實施成本可以儘量下降。
有效性和可靠性：指標要有用，且在長時間內靠譜。當大家發現指標異常並採取行動時，如果有較大機率發現是誤報，會打擊大家關注這些指標的意願。
優先全域性指標：度量首先要聚焦在牽引全域性成功的指標上。區域性指標是當全域性指標出現風險時，再進行拆解分析的。在專案整體檢視中，避免過多的區域性指標資料干擾成員的判斷。
誰度量，誰受益：為了讓度量投入能健康持續的進行，參與貢獻資料的角色一定要有明確的收益，比如透過度量能提升自己的能力，能挖掘出自己的盲區，有利於獲得更好的認可。如果參與度量只是為了讓 QA 能完成彙報任務，甚至還會因為自己度量的資料被老闆批評，這種體驗是難以持續支撐度量效果的。
儘可能自動化度量：既然度量是長期持續的行為，且耗費成本，肯定應該儘量自動化進行。但是確實有一些關鍵指標的後設資料不是自動產生的，可以依託眾包平臺或者問卷調研平臺的錄入資料，實現及時的自動呈現。
趨勢可能比數值更重要：很多指標的動態趨勢可能比靜態數值更應該引起重視，對此工程師不應該只停留在對大小的監控預警，而是應該實現一定時間週期內的趨勢（突增突降，連續多次增或降）監控預警。比如每日新報告缺陷的趨勢，每日完成故事點數的趨勢（燃盡圖）。趨勢圖也能看出哪個測試階段被 “卡” 住了，急需採取緊急動作。
實驗性：既然敏捷的原則就是快速試錯，不斷改進。那麼把度量指標認為是 “權威” 和 “必備的考核目標” 的看法，顯然和敏捷原則背道而馳的。即使團隊對度量指標的價值和定義達成了共識，也需要在實踐中觀察是否合理或精準。可以考慮對指標進行一段時期灰度實驗或者 AB 測試，挑選出更符合團隊實際情況的改進指南指標。
以上是度量指標本身應該具有的特性。
度量指標體系的分層
如果從整個度量指標的體系設計的內容分層來看，至上而下可以分為下面三個層次，圍繞不同的層次和受眾去呈現關鍵指標。
一 面向商業組織層面的度量
組織，尤其高階管理者，關注的是經營的成功，因此度量整體效益（利潤和成本），規模增長速度，使用者滿意度和 NPS 指數，這幾類指標一定是最重要的，代表團隊現在是否健康，未來是否有更多商業機會，是否受市場歡迎。
針對組織的度量比較敏感，會受到組織結構和利益角色的挑戰，應當基於高層的支援，聚焦在市場客觀反饋的北極星指標（即唯一關鍵指標）。
二 面向具體產品層面的度量
這個層面的度量是關注具體產品專案交付的效益和口碑，是否達成既定目標。比如需求交付週期、釋出頻率、專案成本、產品體驗關鍵指標、線上缺陷、投訴率和解決率等等。這個層面的度量指標需要產品人員和技術人員達成一致，共同關注，共同改進。
產品整體性度量指標最好能被進一步拆解，便於團隊分模組識別可改進的抓手，同時避免遺漏。
對於不太熟悉的新產品或新價值領域，也可以先選取一個達成共識的單一重要指標，在深刻理解和應用之後，不斷擴充套件指標的覆蓋範圍或相關型別。
三 面向研發能力層面的度量
這塊通常是實時呈現的研發質量及效率指標，可以立刻採取具體的改進行動。比如日構建次數、單元測試透過率、介面測試覆蓋率、App 崩潰率、首頁流暢度等。
“效能” 和 “敏捷” 的定義
這些年來，很多公司言必稱效能，但是大家對 “效能” 這個新詞與 “敏捷” 這個老詞的理解是含糊不清的，它們是同一個意思麼？
本人拙見，敏捷是原則、價值觀和方法論指導框架，效能是衡量研發產出效益的客觀資料結果。敏捷是內功，效能是表象。正確堅定地實踐敏捷方法，應該逐步帶來效能的明顯提升；但反之則不然，效能指標提升，不一定代表我們採納了正確的敏捷措施，需要進一步分析。
軟體交付的北極星指標
需求交付效能的提升，是由兩個閉環驅動的。左環由產品團隊主導，決定做什麼，為什麼做，為誰做。右環由開發團隊主導，實現怎麼做。（參考《持續交付 2.0》一書）
左環往往是更漫長的，它有大量的調查，實驗，選擇和決策過程。如果要驅動產品團隊提高左環的效率，需要強化 “精益需求實踐方法論，見聊聊精益需求管理（合輯共九篇）”，提升產品和研發的敏捷設計能力。
研發團隊更多是主導右環的順利交付。
之前幾篇文章也提到過（聊聊需求的工作量估算），對於一個產研團隊而言，最關鍵的北極星指標就是需求交付週期（Lean Time），從明確產品的使用者需求，到程式碼最終釋出到使用者手上。
我們可以把完整的需求交付週期拆分為三個序列的階段：需求設計階段，需求研發階段，需求上線階段。
需求設計階段。從使用者需求明確，到產品需求規格明確（PRD）。
使用者需求一個是來自於業務側，一般透過 BRD 規格文件梳理。另一個是來自於產品團隊或者技術團隊，來源可以是使用者反饋和競爭力發展。
需求研發階段。需求評審 + 開發設計 + 開發編碼 + 開發自測 + 需求測試在聯調環境透過
需求評審環節建議在需求研發階段度量，因為澄清需求工作量和釋出內容的取捨，就能讓迭代交付時間可控。
需求釋出階段。包括 UAT 測試驗收 + 灰度 + 全量釋出
在行業中，對於不需要正式 UAT，釋出成本極低的產品，這個階段如果耗時很小，則不需要專門度量。
其中，作為技術部門可控的需求交付週期，是需求研發&釋出階段的總週期。如果業務風險大，UAT 和釋出成本高，釋出階段的耗時長，就需要專項最佳化。
行業敏捷團隊的需求研發週期推薦指標是 28 天（阿里巴巴集團推薦值），即在 4 週一個迭代內完成。傑出團隊平均能在 18 天完成需求研發。
為什麼選擇這個北極星指標？
因為需求交付週期決定了終端使用者滿意度，而且它可以驅動其他所有的效能指標。
只要交付快起來，需求就會被合理拆解，質量風險就會下降，自動化建設、工程成熟度就會提升，流程就會最佳化。
北極星指標就意味著只有一個指標，指引所有人。目前暫時也沒看到更有說服力的單一指標可以替代北極星指標的位置。
結語
針對整個軟體生命週期，鼎叔見過形形色色的度量指標 KPI，其中有不少是 “偽敏捷” 的，會讓團隊走向 “虛假繁榮”，對於 “短期成功” 的原因一知半解。有些指標是需要組合分析，才能識別風險究竟在哪裡。
鼎叔認為，每個團隊可以有自己的自主風格和不同成熟度階段。過段時間，本公眾號會結合個人心得，推薦一些敏捷團隊可以好好挖掘的拆解指標。