Velocity 的部分大致就先聊到昨天，今天要來聊聊看另一種解決方案供參考。
昨天提到，若是想要達到張數與工作量在預測上趨勢相近，在軟體開發情境的條件是：
在 Scrum 裡，為了達到這個條件，採用的是以下兩個實踐去符合條件
透過 sprint 長度去設定了交付時間上線的要求，在時間被固定的情況下，團隊做出的選擇就會趨向將產品待辦項目拆到小於某個顆粒度。同時為了不要遺留任何進行中的產品待辦項目，會優先完成做到一半的產品待辦項目，而不是去展開新的產品待辦項目。
但軟體開發實務上，還是有很多情況是不怎麼適合實踐 sprint，或是實踐成本高的，像是：
那該怎麼辦呢？這時候不如就回看看這三個條件，其實都是基於第一個條件，而第一個條件的關鍵指標就是交付時間（Lead Time，又稱為前置時間），Scrum 的 Sprint 只是協助團隊降低交付時間的方式，但是通常團隊只知道規則，卻不一定意識是為了交付時間。那何不先拋開實踐，直接專注在這個關鍵指標上呢？
這邊先簡單對齊一下本文對於交付時間的定義，即——答應要做到交付所經過的時間。在 Scrum 中就是 Sprint Planning 所認領的時刻到交付為止的時間長度。
那關注這個指標有什麼好處？除了簡化開發流程預測外，有沒有更好的動力讓團隊去關注？還真得有！先幫讀者回憶一下，前面在提到開發流暢度時，就曾講到這個概念：
流動順暢度會影響了需求給予客戶的交付時間，這也就代表著開發團隊是否能更彈性面對市場或需求變化的能力。通常平均交付時間越短，我們就越能因應需求去變化，這也就是我們常談到的敏捷性，對吧！
這其實也就對應到前面 Velocity 迷思之二的那張示意圖：
相較於 Velocity 會在 Sprint 結束時，才知道數據，要幾個 Sprint 才能知道趨勢。交付時間只要 Item 交付，就可以知道離預期差距多少，做了什麼調整也更能及時反應。
而如何判斷一個產品開發是不是處在一個敏捷的狀態，那就是判斷他的交付時間是否穩定，以及時間長度都在預期內。為此可以再搭配幾個圖表去輔助識別。
最簡單的一張圖就是，透過交付完成的順序，在圖表上依順序（X軸），填寫交付時間的天數（Y軸），如此一來就可以看出在這段時間內，交付時間是變得越來越久，還是有所改善，並藉此去做出調整或者回顧。
進一步可以搭配 control chart 去找出不穩定的流程或是哪些數據是特別異常的。如上圖，藍色實心線是平均值，而上下紅色虛線則是控制界限。透過這張圖就更能識別異常的點是哪些。
為了能夠方便回顧，也可以將橫軸從交付順序改成交付日期，一樣有時間性，但更能識別穩定與異常度時間區段，進而去尋找可能原因去做改善。
另一個可以搭配的圖表就是交付時間的分布圖，橫軸是交付時間的天數，縱軸則是指交付時間是這個天數的產品待辦項目有幾張。透過這個圖表，就可以一目瞭然的 Leadtime 的分佈是集中且穩定的，還是分散且混亂的。
如果分佈圖顯示大部分工作項目的交付時間集中在一個較窄的範圍內，這意味著流程相對穩定和可預測。如果交付時間分佈跨度較大，可能說明團隊在某些情況下效率較低，並且流程的可預測性較差，需要進一步調查這些波動的原因。
如果分佈圖出現長尾（有部分工作項目交付時間非常長），這表明流程中存在瓶頸。這些瓶頸可能來自於某些任務在特定階段卡住了，例如在測試、需求釐清或部署過程中出現了延遲。
通過分析交付時間分佈，團隊可以更好地預測未來工作項目的交付時間。了解過去的交付時間分佈情況，能幫助團隊在規劃未來工作時做出更準確的估算，從而提高交付預測的準確性。
今天分享了更接近開發現場的指標 —— 交付時間，透過這個指標能夠更快且更明確的識別目前開發流動的順暢度與穩定度。後面的篇章會在介紹如何在工作場域中，利用工具協助團隊紀錄這個指標，變透過繪製圖表將其現形。有時間的會，再跟讀者們多多聊聊一些特徵，學習如何透過這些圖表判別現在的狀況有什麼要關注的地方。
iThome鐵人賽
看影片追技術