如何做有效的專案估時？
估時在專案管理領域中有各式各樣的方式，而對於估時的目的各專案角色也經常有不同看法:
- 我的部分大概兩三天吧
- 要看情況，先做做看再說
- 不知道，沒辦法估時
- 我不了解為何要做估時
凡事都要先從了解why開始，我們先來了解為何估時是必要的。
所有的估時算法，估時時間點都是為了回答一個問題：
我們是否能如期完成？
成員想知道多久後可以完成，這樣才能開始知道自己做的好不好
專案領導想知道多久後可以完成，這樣才知道何時可以得到用戶驗證
老闆想知道多久後可以完成，這樣才知道何時可以開始賺錢
PM想知道多久後可以完成，這樣才知道準時上線風險有多大
這樣大的問題，沒人可以一下子就回答出幾月幾日專案會開發完成上線賺錢
因此我們把問題拆小，把估的範圍切小，把功能拆解成小單位，把開發週期切割成小的時間週期，一路拆解成可被估時的大小，然後我們進行估時，估時後所有單位加起來，就會知道多久後專案可以完成。
如果專案不進行估時，一個項目參與者互相不知道各自部分多久會完成，就無法回答出這個項目要花多久時間， PM就無法計算出所有項目的時間，於是就無法計算出專案的釋出風險有多大，隨著一天一天離Deadline越來越近，準時上線變得越來越不可能。最終，趕不上Deadine，專案只能面臨趕鴨子上架、或是延長時程，增加開發成本也增加了盈利的門檻，簡單來說，不估時，專案成功的機會很低。
如何估時？
了解why，接下來就來講 how，在Estimates in Agile software development課程中，作者介紹了幾種常見的估時法：
- Complexity bucket
- Planning poker
- White Elephant size
- Quija board estimating
為何有這麼多種？
估時不就是直接講個時間，為何還要這麼多技巧方法？
原因是，實際上大部分情況一個項目是無法被精準的估出時間的。專案在開發時，經常會遇到臨時問題、隨機問題、規格修改、技術不熟悉等等不確定性，造成沒有一種絕對的方式可以精準的估時。在傳統軟體開發方法中甚至流傳一句話，把自己認為的估時乘上2，就是實際上會花費的時間XD。
我們無法估出精準的時間，但可以估計出相對的時間大小，用抽象的、客觀的方法幫助彼此思考，假如用三個圓形來表示三個項目的估時，用眼睛無法看出每個圓形的面積多少，但可以分辨出哪個圓形比較大。B圓形大概比A圓形大出多少，可能大概2倍大，那這時候可以說開發B項目會比A項目花出2倍的時間。
那實際上到底該怎麼知道總共會花多少時間，這時候只要先把最小的項目做完，測量一次花費時間當作單位，比如2天，這時候就可以估出做完大的圓形大概需要4天。
這種先跑一陣子再做估時的過程叫做錨定估時法，只要花費一些時間測試，就能大概估出總體花費的時間。
即使開發過程中，不斷會產生新的項目，但只要利用這種方法，跟過去做的項目大小做比較，就能持續快速估出要花費的時間。
但每種專案的商業性質、大小規模、團隊文化、團隊經驗這些因素，都會影響使用哪種估時方法較為合適。但邏輯皆是大同小異，掌握基礎邏輯，實際練習每種估時方法，將會幫助你為團隊找到合適的估時技巧。
至於項目大小如何估計、估計流程怎麼跑我們在之後的系列文章講解。
然而有沒有可能一開始訂出來的Size標準，到後面變得不適用？是有這可能的，因為項目不太可能一開始就全部估計完，軟體的規格經常需要修改，一開始制定的項目也可能到最後變得完全不一樣。那該如何避免Size標準失效？
答案也是 — 測試，當發現一個項目實際花費時間遠大於它代表的Size就是警訊，這時候應該集結各職種角色，重新跑一次錨定估時法調整Size標準，PM身為排程控制者，這些現象、應對方法要常記在心。
最後整理一下估時邏輯
- 攤開所有需求(目前想得到的)
- 將需求切割大小，直到參與成員都認為不可切割的程度
- 利用估時法將每個項目的size制訂出來
- 測試執行一段時間，錨定估法後，估出總體時間
- 當有新項目時利用size標準估出時間，加入排程
- 每個開發週期後檢視是否要重新調整size標準
