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建議如果可能的話，儘量採用右手邊這一種的（光看圖好像無法區分有何不同 
），在會議場地布置一些電腦，讓與會者可以親自操作系統，然後開發團隊在旁邊觀察試用者的反應。這種方式對於遊戲開發專案特別有效。
***
友藏內心獨白：Sprint review如果還有提供下午茶就更好了
。
照片是叉燒包~
回覆刪除