NoEstimate - Allen Holub

上週同事分享了這個 Allen Holub 的影片
花了一點時間觀看並做了些筆記
在此紀錄一些小小心得

估算永遠都是在猜，而且總是猜不對

Allen Holub 說應該不要再對 tasks 做估算
因為從過去經驗來看
永遠都在猜而且也總是猜錯 (就是說估不準啦)
而你一旦有了估算，就會很自然地出現 deadline
有了 deadline，團隊就很容易被迫加班為了趕上 deadline
因此他認為估算導致了團隊無法 agile

加入機率在估算裡面

他提到 Steve McConnell (Code Complete 作者) 在 Software Estimation 書中提到一些方法
The Clean Coder (Uncle Bob 的書) 裡面也有提到 PERT
簡單說就是你不能只估一個時程
你應該要附加上這個時程可能實現的機率是多少，例如 20%
但 Allen Holub 說其實聽的人對 20% 這個數字是沒有概念的
他用可以裝填五顆子彈的左輪手槍來說明機率
(我覺得很棒的例子 XD)
當這把左輪手槍裡面只裝著四顆子彈時
你用這把左輪手槍指著自己的頭開槍
成功 (存活) 的機率就叫做 20%
一顆一顆拿掉機率就變成 40% -> 60% -> 80%
你說時程有 80% 機率會成功實現
跟此時開槍有 80% 不會轟掉腦袋
講者說就算是 80% 他也不會覺得開心 XD
很好的體現了這樣的估算其實也不一定有幫助

建議數有幾個 stories 不要用 story points

作者提到使用 story points 有個目的是要模糊估時這件事情
然而因為 story points 是個數字
很多時候會自然地被轉換成估時
所以他建議改用 Trivial、Easy、Normal、Hard、Herculean、Don't Know
這樣的字眼來避免 story points 變成工時
但你仍會需要一個可以評估的基準來做很多商業上的決策
他建議使用 projection 的方式 (可以從 24:28 開始看)
就是利用一個 iteration 可以完成多少個 stories
與 backlog 中的 stories 的總數去做 projection
你會得到一個做完所有 stories 可能的時間點
而根據研究結果發現用 stories 總數與 story points 總數
彼此的誤差大概只有 7% ~ 8% 左右
因此他建議不要再做 story points 的估算
(當然估算 story points 的過程帶來的溝通效果還是要做
只是不再要大家估算這個 story 是多少 points)

在前公司待的團隊一開始 team lead 就說我們不要估點數
大家有個默契就是一張票盡量評估約三天左右完成
然後就這樣一直執行了兩年多 (今年過完就三年了)
超過三天還是沒做完怎麼辦
通常會看情況是否可以拆開分段做
還是真的就是要多過三天
那就繼續做到完為止