敏捷開發中, 對於故事的 estimation,
很多人常常會使用 story point 的方式來評估
基本上用 playing poker 的方式來評估
對每個 story 要得到一個 story point
它的重點不是要在於準
而是希望大家可以交流各自對這個 story 的考量
讓大家可以進行一次需求上的 continuous integration
得到的答案或許不準, 但是希望大家對於需求要做什麼有個共識
並且是那時候當下的最佳答案
不過大家還是對於 story point 有點陌生
總覺得出來的 2點, 3點, 5點 到底是什麼
跟最後的時間關係又是什麼?
其實根據 Story Point 的發明人 Ron Jeffries 說到
那時候大家估出來的時間是 ideal estimated time.
也就是在做這個 story 時, 如果不被擾, 沒有需要去開額外的會議
那個得出來時間就是 ideal estimated time
但是大家都知道, 工作就是常常被打斷, 被叫去開會, 或是做別的事情
原來估 2 天的, 可能最後完成要 4 天
因此, Ron Jeffries 那時會把 ideal time 乘以一個比例
來得到最後所需的時間, 也就是最後的估算時間 (final estimated time)
那個 ideal estimated time 就是 story point
final estimated time 就是轉換出來的時間
但是這跟 story 最後完成所需時間 (lead time) 可能還是不一樣
有人紀錄了 lead time 和 story point的結果, 發現他們兩者沒有所謂的正相關
也就是說 story point 小, 不見得 lead time 就小, 而是什麼答案都可能
所以 story point 只是幫助我們做估算, 但是在估算完畢後
我們就會捨棄 story point, 然後專注於看看如何減少 lead time
一般來說, 管理者不在乎你估出來 story point 是多少, 或者是不是很準
他們只希望 lead time 可以比較短, 並且 story 真的能完成
因此我們要思考如何能做到這些
哪我們可以怎麼做呢? 以下一些思路:
(1) 將 story 切小
對於大的 story 通常估算出來的答案, 大家會差很多,並且也不準
但是對於小的 story, 就算估算出來的答案不一致, 也不會差太多
所以我們要先把 story 切小, 最好大約是迭代長度的一半時間
(2) 同時進行的 story 數目不要太多
根據 little law, 如果 lead time 要短, WIP 要少
可以考慮 pair programming, 兩人一起開發, 讓同時開發的 story 變少
並且兩人一起看, 產生出來的程式品質比較好
做完後比較不會再被找到太多問題
讓時間不會因測試要再長出更多時間
這樣做對於開發人員有什麼好處呢？
(1) 不是所有事情都相同重要
將故事切小, 你會發現不是所有項目都有相同的優先順序
你可以先專注高價值的事情先做
如果時間到了, 有些低價值還沒完成, 便有機會商量是否分批交付
(2) 成就感
一大包故事要完成, 通常一個迭代很容易做不完
會拖延到 2-3 個迭代才完成
你就會質疑這個 agile 嗎? 並且很有挫折感
如果半個迭代到一個迭代就可以完成一個
我想對大家來說比較有成就感
(3) 學習其他人的技能
在 pair programming 的方式下, 你可以看到別人怎麼撰寫程式, 怎麼思考問題.
(4) 有機會做的比較快
如果是 pair programming, 因為一起討論
本來會卡關的地方, 有可能在討論後就解決了, 讓時間不會拖太長
發表迴響