如果你要估算粉刷一間公寓要多久時間, 你的做法可能如下:
(1) 會先知道公寓內某間房間 A 大約多大
(2) 然後再概算這間房間要花多久時間粉刷完成
(3) 接著再看看這間公寓的面積大約是這間房間的幾倍大
(4) 最後便可推出總時間 = 房間 A 粉刷時間 x 幾倍大
所以, 我們不直接面對整棟公寓, 而是先找出某一方間面積, 以及其粉刷時間, 才算出整體的粉刷時間.
同理, 敏捷評估也是利用相同的原理. 先找出某一個故事(房間 A), 概算這故事的複雜度(面積), 以及這故事大約要多久完成, 最後才推出整個系統要做多久
而這其中, 用來表示故事的複雜度, 我們稱之為故事點數 (story point), 是 agile 用來評估故事所利用的一種技巧.
這樣的做法在 agile 圈是很流行的, 可是對於不信服的人, 會提出很多質疑:
(1) 又不是做的人評估, 怎麼會準
(2) 我又不懂這部分, 怎麼知道要怎麼估
(3) 資深和資淺的人喊出來的差很多
(4) 有時候某項故事要很多人來做, 這中間 interaction 的複雜度很難估得準
(5) ...
是的, 在很多狀況下, 是不見得那麼準. 雖然很多時間, 我也安慰自己, 來估算就是一種機率, 並且也要看大家的經驗, 確實不容易很準, 但是至少比以前的方法準, 並且帶來以下好處:
(1) 大家可以早期交流意見
(2) 可以對需求更了解
(3) 對於評估結果雖不滿意但可以接受, 因為是大家一起做出來的
(4) ...
但是, 還是不準啊 …...
但是, 還是不準啊 …...
但是, 還是不準啊 …...
後面, 我看到這篇文章 Kanban work items - to slice or not to slice 這句話後:
"The size of a work item or it’s complexity has no correlation on the time it takes to deliver the work."
心理豁然開朗了, story point 這樣的做法, 比以前的作法有改進, 但是搞了半天還是跟團隊組織的文化有關, 如果你的組織
需求老是變動
老是誤解客戶的想法
老是叫員工去處理臨時發生的問題
老是叫員工去參加公司的活動
你的上下游老是出狀況
…...
也就是說, 如果你處理在一個沒有效率的組織當中, 即使你能把估算做得很好, 也經不起這麼多狀況劇的發生.
"不怕遇到神一樣的對手，就怕遇到豬一樣的隊友”, 這是 agile estimation 最怕的事情之一啊.
參考資料: Kanban work items - to slice or not to slice
全站熱搜
留言列表
