最近翻到 Ron Jeffries 寫的一篇文章, 知道了 Story Point 的來源
 
Ron Jeffries 是誰, 他算是跟 Kent Beck 同時期大神, 也是 XP 的創始人之一 (其他兩位是 Kent Beck 和 Ward Cunningham)
 
在這篇文章提到, 故事(Story) 最初是按時間估算的: 實現故事所需的時間. 一開始他們是用 ideal day (理想天數), 也就是在沒有任何打擾的狀況下, 你完成這件事情需要的時間. 有了這個時間, 再乘上一個 load factor (他們通常是乘以 3 ), 就是他們估出來完成這件事情所需要的時間. 例如估出要 5 個理想天數, 這時候團隊交出來的時間就會是 3 x 5 = 15 天
 
可是這樣討論過程就會很混肴, 因為中間你可能搞不清楚, 你現在在提的是理想天數, 還是最後交出的天數. 為了避免這樣的混淆. Ron 就說 5 這個數字是 Story Point, 而 15 則是評估出來的數字.
 
漫談故事點數估算(Story Point Estimation) @ David Ko的學習之旅:: 痞客邦::
 
所以這段往事讓我想到
 
(1) 大家還是習慣用人天或是人時來估算, 這是天性. 這不能怪大家聽到 story point 後覺得很困惑, 然後最終就變成工時
 
(2) 因為不可能有理想天數這個情況發生, 畢竟工作時的打擾太多, 真正剩下能工作的時間太少. 確實需要乘一個比例才是比較符合現狀的答案. 這是不留 buffer, 而是反映現狀. (我不是藉口, 哈哈)
 
(3) 所以某種程度 story point 其實就是時間. 一天就最多是 24 小時. 因為 story points 會變成 velocity, 你一直在要求團隊 velocity 變高, 這是不對的. 因為 2 個星期的迭代就是 10 個工作天, 最多你就能做 10 個 story points (假設一個 story point 對應一天), 你不可能再更高了. 除非你一直加班.
 
 
所以, 也許我們就回歸天數來估計吧, 並且思考一下 load factor 這件事.
 
並且不要要求 velocity 一直提高, 他只能提高到迭代長度的時間. 並且不要忘記還要扣掉 scrum 開會的時間.
arrow
arrow
    文章標籤
    Agile Story Point Scrum
    全站熱搜
    創作者介紹
    創作者 kojenchieh 的頭像
    kojenchieh

    David Ko的學習之旅

    kojenchieh 發表在 痞客邦 留言(0) 人氣()