l

2010年5月4日 星期二

如何估算 story point?

5/03 22:29 5/04 00:30

前幾天實驗室學弟問了 Teddy 一個在 Scrum 中如何估算 story point 的問題,在此 Teddy 談一下自己曾經試過的兩種估算方法。首先假設 Scrum 團隊有四個開發人員,每一個 sprint 長度為兩週 (10 個工作天)。

方法一

【2015/05/26】方法一已不建議使用,請直接看方法二。原因請參考Scrum 是什麼(13):為什麼不建議使用focus factor?〉。

首先將 1 個 story point 定義為『一個理想的工作天 (八小時)』。在估算Story 與 Task 的時候採用相同的單位 (也就是都以 story point 估算來估算),並使用 focus factor 來調整團隊實際可貢獻於專案的時間。

這個方法是 Teddy 從《 Scrum and XP from the Trenches》這本書學來的,在 sprint planning 開始的時後,要知道這個 sprint 可以挑多少 story 出來做,首先就要估算這個團隊可用的 story point。估算方法如下:

開發人數 x 可以獲得的工作天數 x focus factor

在一個四個開發人員,sprint 長度為兩週的專案裡 (沒有人請假,如果有人請假要扣掉請假的天數),可以得到

4 x 10  = 40, 也就是說理想上這個團隊有 40 個 story points 可以使用。也就是說,理論上這個團隊可以完成 40 個 story points 的需求。

但是大家都知道,不可能一天 8 個小時都在從事開發工作,有時候要開會,回 e-mail,MSN 打屁一下,泡杯咖啡,上廁所,吃下午茶等等。有時候要回答客戶問題,或是應付老闆三不五時丟出來奇怪的要求。也可能公司環境太吵或是在大熱天冷氣突然壞掉,害你無法專心寫程式。有太多因素造成實際上不可能達到 40 story points 這個『理想值』。所以,就必須要把這個理想值打個折,至於要打幾折的這個數字,就叫做『focus factor』。focus factor = 1 就表示理想值 (買東西不打折),facus factor = 0 就表示沒有任何生產力 (買東西不用錢啦)。當然 1 和  0 應該都是不合理的數值,至於這個值應該要給多少,每個團隊不一定,總之概念上就是 focus factor 越高表示團隊專注力越高,也就是大部分的時間都可以用來從事 sprint planning 所規劃的開發活動。對於一個剛開始採用 Scrum 的團隊,可以選用 70% 左右的值。

所以,我們得到了 40 * 0.7 = 28 (story points)

接下來假設  Product Owner  挑選了 A, B, C, D, E 這五個 stories,團隊成員估算出這五個 stories 的 story point 分別為:

A : 8 story points   ......8
B : 5 story points   ......13
C : 13 story points ......26
D : 3 story points   ......29
E : 5 story points    ......34

由於團隊預計只有 28 story points 可以使用,如果要完成 A-D,則需要 29 story points,因此如果保守一點那麼這個 sprint 就只會挑出 A-C (26 story points) 這三個 stories 來施工。當然此時 Scrum Master 也可以詢問團隊成員,是否有信心可以完成 A-D,如果大家都覺的 ok,那麼也可以挑選 A-D 。

假設我們保守一點選擇了 A-C 這三個 stories,接下來就是將 story 細分,列出完成每一個 story 所需的 tasks (task 才是真正的施工內容)。典型的 task 有:寫 acceptance test cases, 設計物件,設計介面,設計資料庫,coding,unit testing,寫文件等等。基本上估算 task 所使用的單位應該是『小時』。但是由於 story point 是沒有單位的 (當然你可以用 1 story point = 8 hours 這種『匯率』來換算),如果估算 story 用 story point,而估算 task 用 hour,那麼團隊成員會不自主的去換算,造成估算困擾,因此有一種簡單的方法就是 task 也用 story point 估算。

舉個例子,假設 Story A 是 8 story points,經過 task breakdown 之後團隊列出了以下幾個 tasks:

  • Write acceptance tests: 8 hours (1 story point)
  • Design UI: 8 hours (1 story point)
  • Write UI code: 13 hours (1.625 story point)
  • Write DAO code: 13 hours (1.625 story point)
  • Write DAO unit tests: 8 hours (1 story point)
  • Test: 5 hours (0.625 story point)

Task 所需時間加起來 55 hours = 6.875  story points。這時候你會想,ㄟ (馬總統上身),剛剛估算 Story A 是 8 story points,但是實際列出完成這個 story 所需的 tasks 只需要 6.875 story points,那麼是要把 Story A 改成 6.875 story points,還是增加 task 所需的時間,想辦法把 task 的總時間也變成 8 story points?不知道鄉民們在剛開始嘗試 Scrum 時會不會有類似的困擾?Teddy 剛開始採用 Scrum 時是有這樣的困擾,也嘗試過三種修正方案:

  1. 不理他,還是用原本估算的 Story 所得到的 story point 來作為這個 sprint 可以完成多少 stories 的依據。
  2. 不理他,但是改用所有 task 加總的時間來作為這個 sprint 可以完成多少 stories 的依據。
  3. 改用 bottom-up 的方式來估算一個 Story 的 story point。也就是說,先不估算 A, B, C, D, E 的 story point,而是直接做 task break down,然後把每一個 story 的 task 的加總作為該 story 的 story point (有點繞口)。

先講修正方案三,這種方法開發人員很容易了解,但是其實是不太符合 Scrum 精神。因為原本估算 story point 的目的是用來評估不同 story 之間的『相對大小』,並不是要得到一個精確的數值說 Story A 是 6.25 story points,Story B 是 5.125 story points ...。先估算 task 然後再把 task 加總的時數換成該 Story 的 story points 看起來很合理也比較『精確』,但是卻完全失去了原本估算 『Story 相對大小』的精神,而且還會引伸出『當實際施工時,發現原本估算的 task 時間不準,那麼是否要重新調整 Story 的 story point 這類的問題』 。

***

後來 Teddy 上過 Certified ScrumMaster 課程之後,慢慢體會修正方案二應該是比較好的方法,這也衍生出 Teddy 在這邊要介紹的第二種方法:

方法二

估算 Story 採用 story point,估算 Task 採用小時。Story point 本身沒有單位,每一個 Story 的 story point 是採用『相對大小』來估算的,不用拘泥於 1 story point = 8 hours 這樣的單位換算。至於每個 sprint 可以完成多少 stories,則是以 task 加總的時數來計算。

在 sprint planning 開始的時後,要先計算團隊在這個 sprint 可用的『工作時數』,計算方法如下:

開發人數 x 可以獲得的工作天數 x 每日工作小時

在一個四個開發人員,sprint 長度為兩週的專案裡 (沒有人請假,如果有人請假要扣掉請假的天數),可以得到

4 人 x 10  天 x 一天工作時數 (5 小時) = 200 小時

這邊雖然省略了 focus factor,直接填入團隊(平均)每天可實際投入開發的時數,當然這個時數也是打過折的,所以效果和 focus factor 是類似。Teddy 曾經在某本書中 (忘了哪一本了) 看到一個員工平均一天可以有 5 個小時不受干擾的工作時間就已經很不錯了,因此後來 Teddy 都直接用 5 個小時來估算團隊可以投入的時間。

得到了預計可以投入的工作時數之後,其他的步驟就和 Teddy 在方法一中所說得很類似了,只是這個 sprint 可以完成多少 stories 是在估算 task 階段才決定的。以剛剛的例子:

A : 8 story points   ......8
B : 5 story points   ......13
C : 13 story points ......26
D : 3 story points   ......29
E : 5 story points    ......34

當估算完 Story 的 story points 時,這時候還不確定可以完成多少個 stories。假設經過 task breakdown,得到完成這些 stories 所需的時間為:

A : 55 hours       ....55
B : 16 hours       ....71
C : 48 hours       ....119
D : 22 hours       ....141
E : 25 hours       ....166

結果發現雖然 A-E 的 story points 為 34,但是實際施工預估時間卻只要 166 小時,所以在這個 sprint 除了可以完成 A-E 之外,還可以再選新的 story 進來。

鄉民甲:為什麼 Story A (8 story points) 需要 55 小時,而 Story C (13 story points) 明明比 Story A 要大,卻只要 48 小時?是不是代表 Story C 的 story points 要重估?

Teddy 回答:不需要。再強調一次,Story 的是估算彼此之間的『相對大小』,例如,你要做使用者新增,查詢,刪除,修改這四個 stories。團隊成員認為這四個 stories『大小』是差不多的,因此都估 5 story points。假設你在 Sprint 10 先完成了『新增』這個 story,由於這是這系列的第一個 story,你需要設計資料庫,所以你花了 35 小時,但是後面三個 stories 並不需要設計資料庫,你可能分別花了 28, 25, 31 小時。實際施工所花的時間會受到很多因素影響,例如認領工作的人對於該工作的熟悉度,是否在該工作中使用到新的技術,不確定性的高低,發生難解的 bugs,生病或是和男女朋友吵架導致精神不佳等等。但是這並不代表『Story 的大小改變了』,所以不需要因為 task 預估或是實際花費的時間來修改 story points,除非當初估算 story 的相對大小估錯了。

再舉個日常生活的例子。老師叫學生去操場拔草,小胖身強體壯,『預估』只要 1 小時就可以拔完。如果是換成瘦小體弱的小英,則『預估』需要 3 小時。同樣一個 Story (操場拔草),小胖 1 個小時可以做完,小英需要 3 小時,我們需要重估這個 Story 的『大小』嗎?當然不需要,因為操場裡面的草,不會因為要去拔它的人不同而有任何改變。所以,只要在估算所有 story 時採用『相對大小』的方式來預估,那麼就不需要因為『預估』所需完成該 story 的 task 時間或是『實際完成』的 task 來重新調整 story point 了。長此以往,團隊還是會得到一個穩定的 velocity (每一個 sprint 實際完成的 story points)。

***

友藏內心獨白:以上來賓言論不代表本台立場。

7 則留言:

  1. 我說學長,您還真是非常有心寫這麼一大篇 XD

    回覆刪除
  2. 學長這篇文章非常實用啊,一直都覺得估story跟估task 似乎存在著難捨難分的情結...

    原來story point重點在於評估相對大小,而不是硬邦邦的對應到工作時數。

    回覆刪除
  3. To Lililala:

    我寫的每一篇都差不多這麼長,難道你以前都沒看完...XD

    To zwshen:

    多介紹一點你們實驗室的學弟妹來看...讀者募集中...每次寫完都懷疑有沒有人看得懂我在胡說些什麼...

    回覆刪除
  4. 我覺得篇篇都是精華阿 :D

    回覆刪除
  5. button-up => bottom-up ?!

    回覆刪除
  6. To 路過鄉民:

    感謝指正,錯誤以修正。

    回覆刪除