(3) 適用情境

Velocity 帶來的好處

作為一開始的兩個需求：

• 幫助團隊預測下一個 Sprint 可交付的工作量
• 透過歷史數據展現開發流動的順暢度

在這段期間 Velocity 無疑是有滿足這兩個需求，

• Developers 在 Planning 時比較有依據的去拿可以做完的量
• PO 開始對團隊交付量的節奏有感覺，能夠預測交期與客戶協商
• Scrum Team 可以藉此去審視過去的狀況，藉此作為 Retrospective 的素材

在製成圖表之後，專注在已交付產品待辦清單的交付量，待搭配可開發時間的起伏，是可以明顯感受到目前交付的量是否穩定，只要這個數值保持穩定，整體流動應該也是穩定的。

速率表的困境

既然 Velocity 符合需求，帶來了上述的好處，為什麼昨天我在尾聲時卻說我放下了這個能展現開發流動的實踐方式呢？

事實上，在實踐過程中，我們遇到了一些情境，導致這個 Velocity 對照表

估算困難度提高

為了達成新目標，從某個時期開始，團隊面對產品開發的不確定性變得更高，或是對於需求的理解度、或是對於使用新技術的掌握程度，這兩個面想都使得團隊在估算工作量上，難以做出符合現況的相對比較，進而估算出來的工作量級別在開發完後，才認為差異甚遠。

而 Velocity 既然是基於估算工作量的數據所計算出來的預測，那當估算級別不穩定時，不能說不能再參考，但可參考的程度也就會降低。儘管團隊也會因為這樣的現象，在開發完後重新估算出一個符合事實的相對工作量級別，但這樣卻也增加了維護 Velocity 的成本。

團隊組成與可開發時間的不穩定

在另一個時間點以後，團隊的組成開始變得不穩定，從簡單的為了支援面試，一週可能有三分之二的時間不在、或是團隊成員因為另一個目標被抽出去組成虛擬團隊、或者是為了並行開發三個子目標，團隊重組拆分成三個子團隊。也包括成員開始積假，到開發一段落時，開始率續請長假。

不同於以往是緩和的浮動，這些狀況都導致了可開發時間是極不穩定的。這種不穩定除了完整時間變少，增加了需要切換脈絡的成本外，更因為團隊該段時間的組成也會不一樣，團隊在交付能力上也會有所變化。甚至當某些技術特別成熟的成員請假時，又遇到需要開發該技術的產品待辦項目，當次 Sprint 的交付工作量就會驟跌。

這些變化也會讓 Velocity 的可參考程度下降，而且是極具破壞力的。用個比喻想像看，團隊成員組成的能力可以比喻成交通工具，可開發時間就是使用該交通工具的時間長度，在估算路程時間時，原本都是穩定開汽車去跑，用汽車的 Velocity 的歷史數據，我可以輕易的預測剩下的路程要花多久跑完。但是現在我一下開汽車、又一下開機車、騎腳踏車，甚至改搭火車，這樣該如何預測呢？

對照表的複雜化

原本的Velocity 紀錄表，可能就是簡單的紀錄每個 Sprint 的交付量，這甚至可以搭配專案管理工具去自動化生成。但隨這遇到各項困境或是不該有的期待，對照表開始出現各項需求，比如說計算開發中的產品待辦項目已完成多少比例的工作量、重新評斷工作量估算不準的產品待辦項目、計算可開發時間、計算每單位可開發時間平均的故事點交付量，這些情況都導致了紀錄的變得複雜、成本提高。

而改善的方式，都只是勉強的趨緩 Velocity 可參考信任度下降的幅度而已，但隨著預測越加失準，團隊就會越不想維護他，而可信度也更會因此下降，進入了惡性循環。

最終導致了這個實踐不再堪用，停止採用這個實踐。

Velocity 的適用情境

Velocity 的不確定性與預測範圍

不確定性錐，源自《Agile Estimating and Planning》一書，圖片取自於網頁 "The Purpose of Agile Planning"

在 Mike Cohn 的 Agile Estimating and Planning 一書中的第 16 章 Estimating Velocity 有提及使用歷史資料作為估算團隊速度的方式時，應該要思考下列提問：

• 使用的技術是否一樣？
• 所針對的領域是否一樣？
• 開發團隊是否一樣？
• 產品負責人是否一樣？
• 使用的工具是否一樣？
• 工具環境是否一樣？
• 對項目的估算是否有相同的人員進行？

當否定的比例越高，這個預測值的不確定性也就越高，對於預測值浮動範圍越高。原本會利用平均的 Velocity 乘上一個範圍係數，例如釐清需求時期的 85% ~ 115%，可能就會變動為 60% ~ 160%。假設原本平均 Velocity 是 36，原本預測可交付的工作量可能落在 36 x 0.85 ~ 36 x 1.15 之間，也就是 30 ~ 42，但不確定性越高時，可能就會變成 21.6 ~ 57.6。

而當不去定性高到某種程度時，或許就是要停止使用 Velocity 與其歷史數據來預測的時候了。更何況這種不穩定造成的預測動盪，更多是往少的方向走。

Velocity 在實務上適用情境的檢查清單

就我自己輔導團隊的這次經驗，我也簡單的列出了幾個是否該使用 Velocity 的檢查清單：

• 團隊是否熟悉估算機制？
• 團隊對產品領域知識與使用技術的掌握度是否熟悉？
• 團隊的組成是否穩定？
• 團隊的數量是否有在 5 人以上，且不會有一項技能只有一個人會？
• 團隊成員是否有穩定的可開發時間？
• 每個 Sprint 是否會避免有在製品到下個 Sprint？

透過這幾個項目，希望能幫助正在使用 Velocity 的讀者，往情境為是的方向邁進；若還沒開始使用，或者是使用起來沒效果的讀者，也可以看看你身處的情境是不是都處於否的情況居多，那或許可以考慮使用其他指標，而不一定要使用 Velocity 去判別你的開發流暢度以及作為預測的手段。

反思

本文談及了會導致 Velocity 不穩定的情況，這些情況都會導致 Velocity 的參考價值與紀錄確實度降低，進而也彰顯 Velocity 現形開發流動是否順暢的意義。

或許讀者會認為，這不是透過了 Velocity 發現開發留流動不順了嗎？是的，這些情況可以透過 Velocity 的不穩定知道流動是紊亂的，但似乎也只能知道這樣了。

透過 Velocity 其實難以界定原因是什麼，也因為這樣，通常這也導致開發團隊以外的人，會單純就上面的表現怪罪開發團隊的不努力或者退步，造成兩方的對立。

在之後幾天筆者會來聊聊與 Velocity 相關的幾個迷思，探討一些搭配 Velocity 會遇到的現象，擴大這些經驗帶來的學習點。並再近一步探討，還有什麼方式可以在 Velocity 不適用時，協助現形開發流動的順暢度。