估計

在 擁抱改變 這篇文章中，我稍微聊到了傳統專案做法中，抓時程的方法。
我打算用這篇文章來稍微聊一下在scrum中，對"估計"這件事情的看法。

 先來玩個小遊戲好了。請大家看下面這張圖：

 (圖片出處：http://hdw.eweb4.com/out/440195.html)

好了嗎？開始囉~

 --------------------------------------------------------------------------------------

第一題
 請估計紅色圈圈的大樓跟綠色圈圈的大樓的高度，單位請用公分，沒錯，是cm。

第二題
 請估計紅色圈圈的大樓跟綠色圈圈的大樓的高度，這次請把地下停車場的深度一起估進去。
單位一樣是公分。

第三題
 請問，畫紅色圈圈的大樓是綠色圈圈的大樓的幾倍高？
 包含地下停車場呢？紅色框框的大樓是綠色框框的大樓的幾倍高？

 好的，玩完了。
 --------------------------------------------------------------------------------------

哪一種估計比較難？假如你找十個人玩這個遊戲，哪一題的答案會比較一致？
這個遊戲我第一次玩的時候，也很驚訝，希望在電腦前的你也有同樣的震撼。

我自己的感覺是：

1. 用無意義的單位來估計，是無意義的。

用公分來估計大樓的高度，就好比用(人-天)來估計軟體feature或bug的loading一樣。
假設，一個bug估計需要10人-天，我找5個人來，assign這群人這個bug，兩天以後，這個bug就解掉了嗎？那如果我找100個人來呢？

2. 絕對 vs 相對

在傳統的做法裡面，總會有一個人跳出來說：

以我過去的經驗跟目前專案成員的能力，我估計這個專案至少需要四個月的時間。

說這個話的人可能是PM，可能是資深的工程師、架構師之類的，糟糕一點的話，可能會是業務，總之是個說話有份量的人。於是，他說了，老闆就聽了，團隊也聽了。然後大家再抓一下debug的時間，再抓一下buffer ，於是經過一番討價還價以後，專案的時程可能就訂在六個月了。

很熟悉對吧。但是，為什麼是四個月？為什麼不是四個月又三天又七個小時三十六分鐘五十秒？又，為什麼是他估計、抓時間，而我們programmer在做呢？我做、你估計，我寫程式、你嘴砲，這樣合理嗎？為什麼不讓做事的人自己來估計要做多久呢？最重要的是，假如有人說跟你說，某個事情你四個月做得完，你覺得你四個月真的做得完嗎？或是你六個月，真的做得完嗎？

所以scrum的作法是，以task為單位，請每一位團隊成員參與，用相對的方法，估計這個task大概是那個task的幾倍大；這個bug大概是那個bug的幾倍大，然後，可以估出一個sprint裡面要做的事情的大小，再請團隊決定這一個sprint裡面能完成多少事情。

注意，在估計的時候，我們不再說需要多少時間了，我們說大小，或是，大家可以把他想成難度。雖然，大部分的情況下，比較難的事情會花比較多的時間。但是，也是有的情況是某些事情或bug很容易，但就是花時間，比如說改UI介面之類的；某些事情很難，但是可能改幾行關鍵的code，或是開啟硬體加速就好了。所以難度不等於時間，在scrum裡面，我們用點數代表，最後估計出來，點數大的就比較難，點數小的就簡單。

scrum 有一套planning poker的估計方法，很有趣，也可以形塑團隊的凝聚力。但篇幅關係，我就不說了。

3. 未知數

在上面的遊戲裡面，第二題，估計停車場的深度，通常大家會覺得超難，因為在圖上根本看不到。同樣的，專案kickoff的時候，也有很多看不到的困難是未知的，這時候能夠說出"這個案子四個月能完成"的人，你不會覺得他在唬爛你嗎？

在scrum的世界裡面，用相對的估計更能排除這些未知數帶來的影響。

4. 估計需要是準確的嗎？

回到問題的根本，估計到底在幹嘛？在猜麻。猜得準，很好啊；猜不準，正常的阿。

估計不需要是準確的，

估計是讓我們採取相對應的措施跟做法去面對它。

但是，老實說，估計的準好像比較好，對吧？所以更不應該讓PM去估計，因為做事的不是他們阿，請把專案的所有programmer跟Tester拉過來，問說，這個bug你們覺得大概是甚麼原因？你們覺得要多久可以修好？這樣會比較準。注意喔，態度要正面，這是討論的過程，而不是上對下的命令或是指責。

總結一下：

1. 用相對的方法去估計
2. 估計不需要是準確的，估計是讓我們採取相對應的措施跟做法去面對它。

這也是我在進入scrum的世界的時候，最難改過來的觀念。

在這邊跟大家分享。  :)