2015年3月5日 星期四

估計

擁抱改變 這篇文章中,我稍微聊到了傳統專案做法中,抓時程的方法。
我打算用這篇文章來稍微聊一下在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的世界的時候,最難改過來的觀念。
在這邊跟大家分享。  :)

沒有留言:

張貼留言