To be, or not to be, that is the question.
但是, 在Scrum的世界裡
To estimate, or not to estimate, that is NOT the question.
因為估算是必要的
真正的問題是：如何正確估算？
為何要估算 (待辦事項PBI, Product Backlog Item)？
-
如果不估算 (the so-called No Estimation)，就不知道工作速率
-
工作速率讓我們知道，多少工作能/已完成，才知道下一個期間/Sprint可以完成多少工作
-
知道我們是在加速(讚！)還是在減速(請立即改善！)
-
知道何時可以完成專案或產品的開發(我們到底做到哪裡了？)
-
但如果用錯估算方法，那就是搬石頭砸自己的腳
如何正確估算？
用小時估算?
-
一週正常工作時數是40小時，如果要做更多提高效率，那只能加班增加工作時數
-
說好預估2小時可以完成，最後8小時完成的話，沒人會滿意，只會令人洩氣
不必估算?
-
估算沒有價值，所以我們不該做
-
估算浪費很多時間
-
估算總是不準確
更好的方法：用相對大小點數估算
Scrum之父 Jeff Sutherland博士正宗傳授
相對大小點數估算的優勢：
-
更簡單、更快速、更準確
-
有效掌握團隊效率
-
易於計算加快速率
← 如何簡單、快速、準確來描述
這個罐子有多大？
(請將游標移至照片上，就能看到"相對大小"的超能力!)
如何使用點數估算？
前提：
-
利用相對大小值
-
例如：紐約中央公園有多大？ 843英畝！(你知道843英畝到底多大嗎？)
-
利用相對大小值 ～ 紐約中央公園大約是台北大安森林公園13倍，就清楚易懂多了
-
使用費氏數列(Fibonacci number)作為估算的點數
-
先了解每個要估算的待辦事項(PBI, Product Backlog Item)的內容，利用有效的視訊會議、面對面會議來了解討論，不要只是寫在JIRA或是其他工具
注意事項：
-
在估算中，共識是不必要的，也不是辯論，只是你對其相對大小的看法
-
最後決定的點數，不一定是費氏數列的數字
-
估算是由團隊中真正做產品開發/專案工作的人估算，不是由主管或專案經理來估
開始估算：簡單三步驟
-
團隊一起選擇某個大家都清楚的PBI做為基礎參考點數，設定它為3個故事點數(story point)
-
自己想自己的，比對參考點數所需的工作來估算另一個PBI應該是多少點數(必須是估算撲克牌上的費氏數列)
-
團隊的每個人用估算撲克牌，數1、2、3、亮出自己估算的點數
-
當所有人的估算值落在三個連續的費氏數列以內，則取所有人的估算值的平均(四捨五入)，就是該PBI的故事點數，然後繼續估算下一個PBI
-
當所有人的估算值不是落在三個連續的費氏數列以內，必須請最高和最低點數的人說明其估算理由；然後所有人再次亮出估算點數牌，若經過三次說明及亮牌，所有點數仍未落在三個連續費氏數列之數字之內，則刪除最高和最低點數並取其他點數之平均值
-
例1: 三輪後點數為 8、3、5、2、3
平均數值為 (3+5+3)/3=3.67=4
例2: 三輪後點數為 3、2、5、8、5、13
平均數值為 (3+5+8+5)/4=5.2=5
如果下圖中樂高直升機是3點，那麼請問其他的樂高會是幾點呢？
如何估算大型專案/產品開發？
-
拋開瀑布式的想法，不要使用WBS(Work Breakdown Structure)，因為非常曠日費時(可以花上幾個星期，而尚未開始真正動工)、並且會給人錯誤的自信(我們已經條列所有事情，所以計劃一定完美無缺，對吧？)
-
有一種更好的方法叫做大型專案/產品開發的估算
有興趣學習大型專案/產品開發的估算方法，
敬請email告知(support@agilegrandmaster.com)
或來電洽詢(02-2660-5360)
估算可以很簡單有趣，更快速，並且更準確，前提是如果你學的是True Scrum
企業敏捷轉型導入/實作帶領
Scrum Master/Product Owner國際雙認證課程
Scrum@Scale(多團隊大規模Scrum)國際認證課程
Scrum團隊實作帶領
歡迎隨時洽詢
02-2660-5360
敏捷大師管理顧問有限公司
