Sprint planning 會議會拖很久, 其中一個原因, 是決定這個 sprint 可以完成多少個 story.
這件事情之所以會慢, 是因為要工程師估時程. 他需要了解需求是什麼, 可能要拆解工作, 要想想可能會有多少插單進來, 或者他有多少把握做完等等, 要考慮的東西可能非常多, 因此, 他不能不慎重, 不能不多想想.
但是每次都這樣搞, 時間能不拖久嗎?
可是每次都花這麼多時間, 估出來的結果有比較準嗎?
會不會覺得花這麼時間得出這麼不準的結果, ROI 會不會太低呢?
因此, 敏捷在估算方面, 採取的相對估算法, 而非絕對估算法.
他不去叫你估這個故事要做多少人天, 而是要你估這個故事相對某個故事而言, 要花幾倍的 effort 去做.
絕對值真的很難估, 相對值就容易很多.
叫你估 101 大樓有多高, 你可能猜了很久, 但依然是錯誤的. 但是問你說 101 是總統府的幾倍高, 或許你就算得比較快, 並且大多數人的答案都很接近.
不過, 這樣還是太麻煩了.
你可以用 yesterday weather. 每次你只要數上次 sprint 完成多少故事, 這次迭代其實大約就是完成多少故事.
如果你想要精確點, 你可以算出上三次迭代完成故事的平均值, 這樣這個數字就沒那麼死, 會根據最近狀況做調整.
你看看這樣是不是很快就可以完成估算了. 並且ROI ＋準確性 說不定和之前你算人天差不多. 那你幹嘛還搞這麼久, 這麼累呢?
全站熱搜
留言列表
