close

From: http://teddy-chen-tw.blogspot.tw/2012/03/scrum-18story-point.html

================================================

這兩天提到story point估算的問題,剛剛在搞笑談軟工Facebook社團中,有一位鄉民問了一個很基本的問題:

幹嘛估算story point,有什麼用?

關於如何估算story point可以參考「如何估算 story point? 」、「Scrum 是什麼(16):Story寫得好才容易估算(上) 」以及「Scrum 是什麼(17):Story寫得好才容易估算(下) 」。至於估算stroy point的原因至少有:

  • 預估專案大小:假設你的團隊要開始一個新的專案,經過初估後,這個專案的story point為200。再假設你的團隊之前有實施過Scrum,依據歷史經驗平均每個sprint可以完成20個story point。此時便可「大膽假設」這個新的專案「大概需要」10個sprint左右才有可能做完。
  • 觀察專案進行進度:Scrum有一個術語叫「velocity」,指的是每個sprint結束後,團隊真正完成的story point數量。藉由持續觀察每個sprint的velocity,可作為團隊是否達到穩定產出的一個指標,也可做為團隊流程改善的參考。例如,專案剛開始的前三個月,團隊的velocity只有13,經過三個月之後,慢慢每個月的velocity可以有20左右。但是,突然有一個sprint的velocity降到只有8,這樣的差異便是很值得探討的問題。團隊在retrospective meeting中便可針對此現象加以討論,是否原先對於需求大小的估計太樂觀,抑或是這個sprint臨時被抓去做了一些與專案無關的事情導致velocity降低。
  • 增進團隊對於需求的了解:團隊成員在估算story point的過程中,一定會產生分歧。對於同一個story的估算,有人出20點,也有人出3點,這樣的差異是很常見的現象。藉由估算story point的過程,把團隊成員對於需求的「認知差距」突顯出來,並經過成員之間的互動與討論過程,拉近所有成員對於每一個需求的認知

Teddy認為估算story point的所有用途中,最後一點是最重要的。因為要每一個開發人員都要估點數,因此逼著大家一定要表態。因為大家都要出牌,所以就算有人想要假死(例如每次都出問號,都說自己不知道要怎麼估),也不能再默默的假死,必須在大庭廣眾之下假死。因為估算的過程很互動且透明,所以當估算結束之後,所有團隊成員對於這個專案到底是圓的還是扁的,就有了一定的了解。這樣的了解對於團隊「接下來要做什麼」建立了一定的共識,這對於後續的開發活動能否順利的進行有著決定性的影響。所以就算是暫且不論最後估出來的每一個story的story point大小為何,以及是否能有效地反映專案大小,估算story point這樣的活動,是Scrum中很重要的一環。

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 Foxbrush 的頭像
    Foxbrush

    Foxbrush

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