怎麼估都估不準是軟體產業心頭永遠的痛。
上CSM的時候，有同學問到Scrum可以讓時程估計（Estimation）變準確嗎？Trainer Bas說：不行，但Water Fall 可以嗎？（鄉民：根本就是詭辯啊！！！ ）
那在敏捷開發中，我們要如何處理預估呢？
估不準有很多原因，最根本的原因是軟體摸不得，看不到，不像蓋大樓或電視，可以做一些模型來確認。使用者只能在腦中想象軟體的流程，而只有在使用者真正用軟體的那個剎那他才能決定這是不是他要的。
第一步要先認命認清現實
接受預估絕不可能準，就是既然他叫預估，就表示跟現實會有落差。如果我們團隊都估很準呢？每次說的都做得完，這是團隊有意無意不願意挑戰的smell，如果估計跑一百公尺要一個小時，不管怎麼跑用滾的也可以達成，打安全牌的這種估計有意義嗎？
心態上接受預估不準有幾個好處，第一不會花太多時間估計，反正都不準就憑直覺別花時間去過度分析。第二是不會拿估計不準來秋後算賬，連帶提高團隊的積極挑戰的態度，猜的準就算命買樂透就好幹嘛寫程式。
第二步是把需求分解
這是縮小誤差最有效的方法。要掃完全世界的廁所要多久？全台灣的廁所呢？全台北？整棟辦公室？拆解到有把握的程度，個別估計後在相加起來會是比較靠譜的數字。
最後要利用估計充分溝通交換資訊，最好找有相關經驗的人參與估計，過去的經驗不但可以幫忙分解，還可以提供之前遇到的問題或解法，這都是非常珍貴的訊息。如果沒有有經驗的人呢，就摸著石頭過河吧。從風險最高的部分開始實作，隨著時間不確定性會慢慢降低。資訊交換好後，千萬別花時間爭論要花多少時間。
總結一下敏捷中的估計：接受估不準，把需求分解到夠小，利用估計充分溝通交換資訊。
有人會說，那預估不準要怎麼簽合約呢？時程總不能亂押吧？
理論上的回答如敏捷宣言說的與客戶合作 重於 合約協商。跟顧客協商用包月 Time and Material 的方式合作才是正解。公司內部的客戶就比較好處理，關係打好一點，排出Product Backlog，跟客戶和老闆有共識按照順序做下來。
問對問題很重要，不要問客戶要做那些功能，要問客戶如果我們先做一個功能，哪一個功能現在對你最重要。
實務上在台灣很多甲方公司沒辦法接受這種合約，但在全球軟體外包產業中，印度和東歐很多軟體開發公司都是跑包月制，顯示世界上很多甲方都認知到白紙黑字不會產出好的產品。沒辦法接受敏捷開發的公司將因做不出好產品而被淘汰，當然，除了政府坐莊再爛都要去用的除外。
圖片：https://www.cartoonstock.com/directory/e/estimation.asp
在〈神啊，請讓我估的準一點吧 – 如何預估軟體時程〉中有 1 則留言