筆者一開始學習 Scrum，是在 2015 年左右，那時被公司派到上海去支援，跟著他們一起 Planning、Daily、Refine 等等。那時這樣的工作流程對我來說是非常陌生的，應該說，我當時是在完全還不知道什麼是 Scrum 的情況下，開始學習用 Scrum 工作的。
記得一開始對我來說最有障礙的就是「估算」了。那時我就覺得很奇怪，不就一個 spec 發下來，做個技術分析，看看 deadline 趕不趕得上，頂多在發現趕不上時提前跟主管講一下就好了嗎？這樣應該就很有良心了吧？為什麼還要大家聚在一起評估，還不能先指定要誰做，還要拿樸克牌？要幹嘛？比大小嗎？
後來才知道，拿撲克牌是為了要「估點數」，但當時的我，也不知道估點數是為了什麼。想說，新人嘛！不然就大家出什麼就跟著出吧！於是，在某一次估算的流程中，我發現我出的點數與別人差很多，但看看時間又快到了，想要趕快結束這場會議的我就做了一個決定：喊了一聲「啊，出錯了！」然後默默把牌抽回來。
你們不會嗎？會吧？從小到大，不管考試還是比賽，不應該就測驗你的理解「對不對」，寫的答案跟人家一不一樣嗎？不然你去學校考場看剛走出來的考生，聊的是不是都是「第 8 題我寫 D，你呢？」「啊我寫 A，我應該寫錯了！」
出牌出得跟別人不一樣，下意識會覺得自已「出錯了」，人之常情，對吧？
「對吧？」示意圖，圖片來源：梗圖倉庫
後來的這幾年，也時不時地在一些社群或討論的場合，聽到有人在問：「估算要怎麼估才會準？」
到底估點數怎樣才會準？
其實，筆者的想法是：
估算很難很準示意圖，圖片來源：https://www.dailymail.co.uk/
「搞笑談軟工」版主 Teddy Chen 曾專文介紹：「Story point 為何沒有單位」。文中拿了割草來當例子，於是筆者斗膽借此例來延伸解釋一下。假設我們接到一個工作要割草，那麼，我們要怎麼估算這個工作的大小？用時間嗎？顯然不適合。今天一個割草有十年經驗的老鳥，跟一個初來乍到，連割草機怎麼發動都不知道的小菜鳥，你可以想像，這兩個人割同一片草地所需的時間肯定大不相同。如果要用時間當單位，那請問要以誰的時間為估算基準？
說到割草這件事，完成時間固然重要，但我們最根本要先知道的事，其實是這件事「有多大」。如果連這件事有多大都不知道，你要怎麼估出後面的東西？
那麼，有什麼事會從根本上決定這個工作的大小呢？因素有很多，這些因素也就定義了這個工作的「內容」本身。例如：這塊草地有多大、草地中有多少障礙物、有沒有斜坡、驗收員對完工的檢查有多嚴格…等等。
然而，上述這些事情雖然對定義工作範圍很重要，很卻很難量化。因此我們能做的，也就是透過討論，加上一些過去的經驗，來取得共識。目的是為了讓團隊對這次接到的這個「割草」任務，有共同的了解。到時才不會因為執行的人不同而得到不同的結果。
回到我們的 Planning Meeting 場景，同樣的工作今天大家都出 10，你卻與眾不同地出了一個 50，這時，我們可以說是你「出錯」了嗎？這時我們可以勇敢大膽地說：「不適合」。
Unble Bob 在 Clean Agile 一書說，估算是為了取得共識。什麼意思？當一個人出的數字跟大家明顯不同，可能的原因很多。如果是他對 PO 的解釋有誤，此時正是釐清的大好時機；如果他對工作的內容有與我們不同的見解，例如有個安全性 issue 除了他沒人考慮到，那不就還好他有想到？總之，不同的數字是一個指標，但與錯誤無關，這個指標給我們一個機會透過討論來消弭大家對同一個工作的理解的歧義。
這也是為什麼我同時會認為估算不應該一直很準。原因也就呼之欲出了：如果估算一直很準，那有樂觀來看有可能是我們對工作的了解都差不多，但也很有可能只是代表我們只是對「趕快結束這個 Meeting」很有心得而已。
簡言之，不要怕估算不準，也不要追求估算準。要緊的是我們的討論對工作的了解有沒有幫助。
謎之聲：「沒人能阻止想下班的人，只要是能定量的指標就能被達成。」
iThome鐵人賽
看影片追技術