第 10 章：如何綜合應用各種指標？

在整個主題的在第二部分中（目錄架構詳見第一篇文章），筆者從如何現形流動順度去展開介紹，從 Velocity 的概念、聊到如何演化與應用的食物，以及 Velicity 的困境、局限與相關迷思。接著又從交付時間（Lead Time）開始談起，聊到相關的指標與圖表，講了許多它們可以改善團隊困境的地方。

但實務上交付時間真的有這麼完美嗎？Velocity 真的有如此不堪嗎？其實並非如此。

數據累積的成本

無論是 Lead Time 與其相關的 Run Chart、Distribution Chart，或者是 CFD、Flow Efficiency，這些指標與圖標都會需要累積一段時間才有參考價值，當樣本數過少時，並無法看出任何趨勢。而 Delivery Rate / Throughput，則是在團隊能夠將顆粒度控制在一定大小時，並且謹守儘量降低 Lead Time 的原則時，才比較有參考價值。

更何況，在搜集時間相關數據時，是相對難的。若沒有一定的自動化程度，團隊不一定有動力或者紀律去一一記錄起始時間，計算時間區間。這些指標與圖表，在實務上最容易挫敗的莫過於無法有效地去記錄這些數據。

Velocity 的易用性

相對的，Velocity 只要有簡單的估算機制搭配，團隊在第一個 Sprint 結束時，就有一個可供參考的數值在 Sprint Planning 時預測規劃時使用。就像前面在筆者在分享 Velocity 演化的經驗，甚至只要一張紙與一支筆，就可以開始這樣的實踐。

這個實踐對於產品待辦項目顆粒度與 Lead Time 相對也要求不高，太大換算的數字就大，並不會失真太多。儘管如此，Scrum Team 仍能透過 Sprint 這個 time-box 有一定的限制，不會超出太多。

而這樣的易用性，正也是可以開啟團隊累積數據與善用圖表的習慣。

搭配使用

所以按照我自身的經驗，我會建議其實團隊在前期時仍然可以嘗試先使用 Velocity 作為第一個輔助用的指標。逐漸累積去追蹤趨勢，讓團隊先有個方式現形最基礎的開發順暢度的變化。並且隨時注意團隊的動態，是否經歷了會打亂 Velocity 參考性的事件（詳見 Velocity 的困境），若有遇到就將參考基準線歸零重新累積。

隨著團隊開始習慣看數據，適時地引入 Lead Time 的概念，並將每個產品待辦清單的最長 Lead Time 設置成 Sprint 長度，這樣不但跟原本運行的機制差異不大，卻將原本限制的來源從 Sprint 改成 Lead Time，之後就可以藉此培養團隊切割顆粒度大小的能力，除此之外又藉此可以開始累積 Lead Time 的數據。

但數據開始累積一定程度時，就可以將圖表畫出來，讓團隊感受到開發順暢度真實的情況，並且開始追求穩定度與更適合的 Lead Time 長度。當團隊對產品待辦清單的顆粒度都因為 Lead Time 而比較穩定的坐落在穩定的大小範圍，就可以嘗試將 Velocity 取代掉，從工作量看像以張數為單位的 Delivery Rate 了。

尚未解決的問題

講得很理想，但這與現實仍有一段落差，因為如何降低紀錄數據的成本這個問題並沒有被解決。如果這件事不被解決，就沒不會有值得參考的資料庫。

別急，接下來筆者就來分享如何善用工具，現形開發流動的順暢度，讓團隊能有更省心與低成本的方式，紀錄數據並且繪製出來作為參考囉！