PO或老闆:軟體甚麼時候能夠上線?甚麼時候可以給客戶用?
1. 列出必要開發的功能(PBI)
2. 並依重要性排出優先順序(Priority)
3. 必要功能粒度相對大小評估(T-Shirt Size):S, M, L, XL
4. 使用sprint0進行穿刺實驗(Spkie):
(1) 從PBI中挑選S、M、L各一個項目放入sprint0,開始開發
(2) 開發過程中,紀錄S、M、L各需要多少Story Point(開發時間)
(因為是估算,其實精確在幾點幾分完成不是重點,真正耗費的總時數才重要,為了統計平均用)
(3) 推算一個sprint的產出速率 (每個sprint可以產出多少story point)
注意PBI 的 size 是否有大到超出
sprint 的範圍,也就是一個 sprint 做不完某一種 size 的 PBI 。若有此情況,則需考慮拆細 PBI 並調校 size 的定義。
5. 所有的PBI進行 story point加總
6. 初估團隊速率與專案完成時間
7. 每次sprint結束後,持續修正團隊速率與PBI size的估算,看看是否還是能夠如期完工。(Yesterday weather)
8. 重新檢視與評估需要的完成時間
(1) 按照目前速率,是否能如期完成所有功能
(2) 如果無法如期完成,有甚麼選項可以選:
1)
延期 (團隊工作速率(工時)不變):需要延多久
2)
調整功能重要性順序,刪減較不重要的功能 (團隊工作速率(工時)不變):刪哪些就可如期完成、只刪去A或B功能,要延期多久可以交付軟體
3)
加班(增加工時):每天要加班多久,才能如期完成
舉例:若S、L、M分別用了5、13、20 Hr,這三個PBI共用了1週的時間完成,則:
* 團隊的Velocity為(5 Hr
+ 13 Hr + 20 Hr) / 0.5sprint = 76 Hr / sprint
(通常一個完整的sprint為期兩週,所以1週就是0.5個sprint)
* S、L、M各 size 對應的 story point 基準為5 Hr、13 Hr、20 Hr
* 專案總共有S、M、L各2個PBI,完整的product backlog為76 Hr。目前已經完成S、M、L各一,剩下的 product
backlog 大小為 38,只需要38 Hr / 76 Hr/sprint
= 0.5 sprint就可以完成,也就是1週。
{Reference}
Why are
software development task estimations regularly off by a factor of 2-3?
[英文]
https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=kw
[中文]
http://www.inside.com.tw/2013/10/24/why-the-last-20-of-work-takes-the-same-amount-of-time-as-the-first-80
Why
Software Development Estimations Are Regularly Off
https://diegobasch.com/why-software-development-estimations-are-regu
Scrum Estimation-Story Points and Planning Poker
https://dotblogs.com.tw/hatelove/2015/11/23/scrum-estimation-story-points-and-planning-poker
Scrum Estimation-如何估算專案時程
https://dotblogs.com.tw/hatelove/2015/12/19/scrum-project-schedule-estimation
Scrum Estimation-Dog Point Game
https://dotblogs.com.tw/hatelove/2015/12/01/scrum-estimation-dog-point-game