「老師，我們公司有在使用敏捷方法做專案，可是團隊在估算用戶故事（User Story）時間的時候，老是估不準，有的時候會多留很多 buffer，有時候又少估很多時間，導致衝刺的工作做不完，這該怎麼辦才好？」
我在《Scrum 敏捷方法裡，渾然天成的九大風險管理把關設計》一文中談過，敏捷方法的框架其實隱含了不少巧妙的風險管控設計，其中當然包含了管控「因時間錯估而延誤」的風險。這裡我們先假設，這位學員提及的敏捷團隊，有確實遵守敏捷方法要求的原則來運作，沒有自行偷斤減兩，可是團隊對於時間的估算，卻依然不夠準確。在這樣的前提背景下，我們還有什麼其他的招數，可以來改善這樣的問題。
【比較法】的問題
假設團隊使用的規劃撲克牌是依據費式序列設計的，若有個用戶故事Ａ，開發團隊估算其所需的時間為１點，接著將另一個用戶故事Ｂ與Ａ做比較，認為Ｂ所需的時間大約是Ａ的 1.5倍左右，所以開發團隊便將Ｂ的時間估為２點。
開發團隊繼續將另一個用戶故事Ｃ與Ｂ做比較，認為Ｃ所需的時間大約是Ｂ的２倍出頭，可是因為規劃撲克牌內並沒有４點的撲克牌可選，所以開發團隊便將Ｂ用戶故事的時間估為５點。
您可能已經發現，Ｃ用戶故事的點數可能已經在無意之間被過度放大了。如果我們繼續用這樣的做法來估算其他用戶故事的時間，那麼，愈晚被估算的用戶故事，它的時間可能就愈不可靠，誤差愈大。
上例中，用戶故事C的時間點數，其實是A的3倍，也就是3點，可是因為選擇了不當的比較基準B，才造成了C被誤判為5點，那到底我們應該選擇A還是B，來當作C的比較基準呢？
也許您會這樣認為：把C和B比較一次，再繼續把C和A比較一次，接著把兩次的比較結果權衡一下，這不就得了嗎？
這樣做的確會比較準確，可是你試想一下，如果現在要處理第Z個用戶故事，而你已經有 25 個已經估算完畢的用戶故事，你和你的開發團隊會把Z和這 25 個用戶故事都像這樣比較一次嗎？
當然不會！因為這樣的做法實在是太沒有效率、太慢了。敏捷方法之所以要求時間的估算要使用「比較法」，就是因為有「大量」的用戶故事要估算，所以得夠「快」，而且還要得夠「準」。那麼，我們到底還有什麼做法，可以兼顧效率和準確呢？
（一）三角測量（Triangulating）
被估算完點數的用戶故事，其實都可以當成我們的「比較基準資料庫」，理論上，資料庫內的任何一筆資料，都應該可以被我們當作估算下個新用戶故事時間時的比較基準。可是上述的例子告訴我們，這個資料庫當中的數據，有可能自己本身就已經不夠準確。故我們的首要之務，就是先想辦法建立一個「足夠準確」的「比較基準資料庫」。
當「比較基準資料庫」有足夠的數據後，我們在估算一個新用戶故事時間的時候，就應該在資料庫裡挑選出「兩個」用戶故事來當作比較基準，其中一個的點數要「略大於」新用戶故事，而另外一個的點數則必需「略小於」新用戶故事，如此把新用戶故事包夾在兩個基準之間來做兩兩比較，以確認我們對新用戶故事的點數估算是否有失真，這樣的作法就叫做「三角測量法」。
這樣做有三個好處：
(1) 對於新用戶故事的時間估算，不再像上例那般，只有單方向的比較（往大或是往小），造成誤差愈滾愈大。
(2) 透過這樣的方法所建立起來的「比較基準資料庫」會更加精準可靠。
(3) 對於新用戶故事的時間估算，速度會夠快。
到這裡，您可能會以為，這樣就已經足夠了。其實，我們還可以做得更好！
（二）隨機選擇
人，總有自己的偏好，開發團隊也不例外。於是，「比較基準資料庫」內的某些數據，總是會比較頻繁地被選來使用，而其他的數據則可能被長期冷凍，乏人問津，而這樣的主觀選擇，就容易造成估算上的不可靠。
因此，在遵循「三角測量法」的前提之下，當我們在選取比較基準時，除了考量基準和待估算用戶故事之間的「相似度」之外，最好也能「隨機」一些，讓基準的選擇能夠更加客觀。
到這裡，您覺得，做到這樣總該夠了吧？錯！我們還可以做得更好！
（三）與時俱進
首先，「比較基準資料庫」內的用戶故事，有些尚未被實作完成，其時間還只是個估算，而有些則已經完工，其時間估算就可以被驗證。如果這些已完工的用戶故事被證實，其當初的時間估算很不準確，那麼，這樣的用戶故事就不再合適被當做比較基準，應該從「比較基準資料庫」當中將之剔除。
其次，隨著時間的推進，「比較基準資料庫」內的某些用戶故事，其使用的技術也可能早已過時淘汰，該用戶故事也不再適合被當作基準來使用，也該從「比較基準資料庫」中將之剔除。
第三，開發團隊成員也可能會異動，也許會形成新人多過舊人的狀況，如果「比較基準資料庫」內的某些用戶故事，對多數開發團隊成員來說是陌生的，那麼，這樣的用戶故事也不適合再繼續被當做比較基準，也該從「比較基準資料庫」中將之剔除。
最後，假若開發團隊成員沒有太大變化，「比較基準資料庫」內的用戶故事所用的技術也沒過時，我們就不必持續更新「比較基準資料庫」了嗎？答案當然是，「要持續更新！」為什麼呢？
因為，即便開發團隊成員和所用技術都沒太大變化，人的記憶總是有限的，對於那些歷史悠久的用戶故事，開發團隊當初是如何考量才做出那樣估算的記憶，往往早已模糊失落。在這樣的情況下，要繼續使用這些陳舊的用戶故事當作基準來跟新用戶故事做比較，往往更容易造成估算的失真。因此，這類過於陳舊的用戶故事也不適合繼續當做比較基準，也該從「比較基準資料庫」中將之剔除。
經過以上這些多面向的技巧把關之後，相信您和您的開發團隊，對於用戶故事的時間估算，肯定會更加地得心應手才是。
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
