為了在市場中保持競爭力的技術公司都在進行某種程度的轉型。敏捷轉型、數字化轉型和DevOps轉型無處不在，因為公司試圖改變他們的工作方式，從而改善業務結果。

指標(metrics)是任何轉型的關鍵部分。傳統的IT績效指標，例如計算代碼行數和軟件bug的數量，應該謹慎使用，因為存在不值得修復的bug和不值得維護的代碼。這些老式的績效指標度量的是活動(activities)，而非結果(outcomes)。活動指標很少能告訴組織對業務目標的真正影響是什么。

那么，應該如何度量呢?我們需要考慮Flow(流)相關的指標。Flow指標是一種績效(performance)指標，它揭示了期望的業務結果的趨勢 —— 例如更快的上市時間、對客戶的響應以及可預測的發布時間框架。這些業務結果在成功的轉型努力中起著至關重要的作用。請允許我向您介紹五個強大的流指標。

Flow Time(流動時間)

Flow Time是衡量一件事從開始到結束需要多長時間。你可能會想，“等等，這不是周期時間(Cycle Time)嗎?”。你可能是對的。這取決于使用該定義的上下文。根據你所問的人的不同，“周期時間”有不同的含義，計時可能在不同的時間點開始或停止。理解周期時間是一個模棱兩可的術語，這就是為什么我喜歡在討論速度指標時使用Flow Time。因為Flow Time對于大多數人來說是一個陌生的術語，它提供了一個清晰定義含義的機會。Flow是通過系統順利且可預測的值，是支撐DevOps的三個基本原則中的***個。

Flow Time說明：當請求(request)被批準時，計時開始，當變更生效并在生產環境中運行時，計時結束。

Flow Time計算開始時間和結束時間。Flow Time不會因為周末的到來而停止。Flow Time所做的是量化在該時間段內完成給定工作的概率。

例如，如果歷史Flow Time顯示，某種類型的工作有90%的概率在30天內交付，這樣我們就可以說，10次中有9次我們可以30天內交付該類型的工作。我們知道有10%的可能需要更長的時間。這讓我們對客戶的需求有更好的可預測性。

譯注：在DevOps里通常會用到Lead Time(前置時間)這一術語。但Lead Time也來源于工業生產里，這樣也會出現歧義。Flow Time這樣一個專有名詞顯然更好。

Flow Efficiency(流動效率)

好的指標讓我們有更清晰的全景和對諸如“何時能夠完成?”這樣的問題有更準確的答案。到期日(due date)這樣的指標很少考慮等待時間。然而問題通常不在于處理工作的時間，而在于等待時間。

想想由于工作依賴而造成的延遲——當涉及到需要多長時間完成工作這樣的問題時，等待時間往往比實際處理工作時間影響更大。你***是估計等待時間，而不是工作時間。等待時間通常消耗85%或更多的Flow Time。

譯注：這個指標也叫PCE(Process Cycle Efficency)。

WIP Report(在制品報告)

把工作分解成更小的部分是很重要的，這些部分可以很快完成并交付。交付越快，反饋就越快。太多的在制品(WIP)(在Flow Framework中稱為“流負載”)，為更多的工作間依賴、更多的沖突優先級、更多的計劃外工作悄悄開了口子，這會導致延遲。獲取WIP趨勢并將其與Flow Time結果進行比較，可以幫助我們了解組織中的WIP與速度之間的關系。

Aging Report(老化報告)

Aging Report展示了工作項在系統中停留的時間。看看系統中有多少工作項停留了超過30天(或60天或120天)，就會發現系統中有多少浪費。下圖的例子比較了工作的平均耗時，并突出顯示了那些比平均耗時更長的工作項。

譯注：方框代表該類型工作的平均耗時，黑線是該工作的實際耗時，粉線代表超出平均時長的時間。

Flow Distribution(流分布)

將工作分成不同的工作類別使我們可以調整工作優先級以及對報告數據做過濾。流分布顯示各種工作類別期待的(以及歷史的)分布比例，為計劃性工作(planned work)分配帶來可見性。當有了工作類別后，我們就可以對報告按照類別過濾，比如WIP報告，這反過來可以幫助改進WIP設定及可預測性。

譯注：工作類型是每個組織自己定義的。比如在《鳳凰項目》里，定義了四種類型的工作：業務相關的，運維的日常維護工作，變更，以及計劃外工作。

根據工作狀況，WIP設定可能需要調整。比如剛剛發布了一個新特性，那么處理缺陷或技術債務可能會優先于引入更多特性。如果這時選擇繼續做更多的特性工作，它將占用其他工作類型時間，比如修復與技術債務相關的問題。對工作類型分布進行分類和度量有助于進行優先級排序。

映射指標和結果

• 如果上市時間(time-to-market)是追求的結果，那就度量Flow Time(流動時間)，幫助別人了解事情實際上要花多長時間。
• 如果效率是你追求的結果，那就度量Flow Efficiency(流動效率)，以查看瓶頸點，因此將重點放在能夠改善流的地方。當涉及到流時，優化一個非瓶頸點并沒有什么幫助。
• 如果團隊正在處理計劃外的工作和/或優先級沖突，那么就度量WIP數量(WIP Report)以暴露分配工作過多的團隊。說到效率，如果過多地關注資源效率而不是流效率，那么其實是在浪費時間。
• 如果忽略了未完成的重要工作(如修復安全漏洞)，則應度量未完成工作在系統里停留的時間(Aging Report)以暴露風險。就像一座正在建造中的橋梁，在它完成之前，是不產生任何價值的。
• 如果某些類型的重要工作(比如修復技術債務)沒有相應的優先級，則應度量工作類型的分布(Flow Distribution)，以使與工作分配相關的問題變得可見。

原文鏈接：https://www.tasktop.com/blog/5-best-metrics-youve-never-met/

【本文為51CTO專欄作者“徐磊”的原創稿件，轉載請通過作者微信公眾號devopshub獲取授權】

戳這里，看該作者更多好文