搞笑談軟工: 我在第二次Certified ScrumMaster課程學到的事（4）

2012年12月13日星期四

我在第二次Certified ScrumMaster課程學到的事（4）

Dec. 10 14:38~15:10

今天談一下velocity與sprint review。

Velocity

Teddy在《Scrum 是什麼（18）：到底為什麼要估算Story Point哩？》提到估算story point的幾個原因，其中有一點是可以「預估專案大小」，今天用Emerson畫的一張圖來說明。請參考上圖，假設團隊經過幾個sprint之後，發現團隊最大、最小、平均的velocity（每個sprint完成的story point總數）與機率分別是：

最大：20 (5%)
最小：5 (25%)
平均：15 (70%)

假設團隊在本次產品發表之前，一共有1000個story point的功能需要完成，因此可以依據以上數據畫出三條線，用來預估產品釋出的時間可能落在哪個範圍之內。舉個例子：

最大：1000 / 20 = 50 sprint，有5%的機率可以在第50個sprint的時候就可以完成全部功能。
最小：1000 / 5 = 200 sprint，有25%的機率需要在第200個sprint的時候才能夠做完全部功能。
平均：1000 / 15 = 66.6 ==> 67 sprint，有70%的機率可以在第67個sprint的時候完成全部功能。

在採用story point預估專案大小的同時，如果也能夠知道團隊的velocity，就可以利用這個方法來估算產品釋出的時間。

***

Sprint Review

Sprint review的目的是希望Product Owner、客戶或是其他有興趣的鄉民，可以針對開發中的產品提供一些回饋的意見。會議進行的方式可以參考《Scrum 是什麼（8）：Sprint Demo Meeting》，上圖是Emerson在課程中提到的兩種進行模式。左手邊這一種是傳統的sprint review方式，由開發人員操作系統給其他與會者看。傳統方式的互動性比較不足，Emerson建議如果可能的話，儘量採用右手邊這一種的（光看圖好像無法區分有何不同挑眉質疑），在會議場地布置一些電腦，讓與會者可以親自操作系統，然後開發團隊在旁邊觀察試用者的反應。這種方式對於遊戲開發專案特別有效。