當上級過來詢問『這個工作要作多久？』你要怎麼回答呢?
範圍呢? 它可能是：
* ㄧ個功能的小修改。
* 新增一個完整的功能。
* 一個人的專案開發。
* 一個3到5個人的開發團隊要接手一個新專案。
* 一個古老系統的重新開發，人力、時程…,都要一起估算。
* …
* 哈，可能只是一個構想，但總要估個時間來作參考啊。
而你可能是一個工程師或是這個專案的負責人，請問要如何估算開發的時程呢？
.
(基本上；不管你怎麼估算，都不會太準確的《這是軟體開發的特性，不是個人的問題，別太在意》。不如花一點時間，多收集一些資料，然後運用參考、比較的方式來進行估算，這樣會準確許多。但! 這還是在猜測。 不如針對整個開發團隊訂下簡單的規範，讓大家一起來遵循，會有意義的多。以下是我建議的做法: 「信心點估算法」)
.
長久以來，我們都用直覺或是猜測的方式來回答這個問題，即便是曾經作過，有經驗可供參考。但基本上；還是很難像補輪胎的師傅一樣的回答: 大約 10 分鐘!
.
※ 對個人而言
工程師由第一天開始寫程式開始，就會被不斷的問到這個問題，怎麼回答呢? 老實說，只要你是用猜的，他就不會準! 但；如果不用猜的話那要怎麼辦。正式的回答是:
「給我一點時間，讓我進一步了解一下! 」
— 接著； 用科學的方法: 盡快的依靠觀察、組織、搜尋，用切割成小的區塊再整合起來的方式去架構出來你需要的估算，最基本的作法就是切割成小組件來估算，在一塊兒的加總起來(Divide and Conquer)。
.
老闆當然不會給你太多時間去進一步了解一下的! 很快的，工程師就必須給出一個預估的時間(把我這篇文章給老闆過目一下，老闆在閱讀的時候還可以換取一些時間)，接著呢! 這時候；就應該趕緊去理解這個問題，要明白當你越快弄清楚了，成功的機率就越大!(軟體開發的過程，就是一種學習的過程，學得越好，程式才會越正確)
圖一. 運用信心點的估算方式
請注意!
第一次的估算純粹是猜測，不是承諾。要我真正的承諾，等我的信心點出現。
第二次的估算，是有信心後的估算，它是承諾。
上面這一張圖是我上課的時候常常建議給學員們的方式，在第一時間點(專案還沒開始時，時間=0)，不要甚麼都不做就去猜，至少要透過「進一步了解一下」的方式，才給出「預估」的時間。
然後在專案進行到產生「信心點」時，再來給上級「承諾」。此時的承諾可能要比當初的預估時間要準確許多了。這是我經常要求工程師的動作，隨著我們對專案問題的了解越來越深入，自然會越有把握何時會做完(這個時候務必讓主管也知道一下，這一點非常重要，它叫做專案的透明度)。
上面的「信心點」就是我們對自己工作的把握程度。我一般把它訂在專案開始後 1/5 到 1/3的時間範圍內(這裡的比例是根據不確定性錐的曲線所得來的(Cone of Uncertainty)，1/5到1/3的時候剛好是不確定椎急速收斂的區間，這個時候是我們對專案的相關智識快速增加的區間，也就是我們開始大量熟悉它的時候，因此我習慣在這個時候要求工程師給予承諾。工程師經常在還不到1/5時就跑過來拍胸脯了。好啊! 有信心是好事!)。通常在時間到了(到達1/3的開發時間)的時候，我會再要求工程師給一次估算，然後慎重其事地說，這一次可是「承諾」了。雖然這個承諾基本上還是猜測，但他至少是一個較值得我們一起去努力達成的，一個比較有意義的奮鬥目標(其實他的意義已經遠勝於承諾的價值了)。
這樣子的做法是對工程師的一種尊重。但是工程師應該要主動做這件事，不需要主管再來確認。(請參考: Steve McConnell 的不確定性錐)
.
【制定簡單的規則】
一、當我們被要求要做估算時，不要在第一時間就做出回答。應該要花一點時間，多收集一些資料，運用參考、比較的方式，來做第一次的估算。(請參考2002年諾貝爾獎得主Daniel Kahneman所著的: 快思慢想 ，他說沒有經過較多時間思考就做的回答，往往錯誤率會偏高且容易被問題所誤導)
二、在提出估算之後，要持續去追求對專案問題的瞭解，盡快找到「信心點」，在產生了信心之後，主動向主管做出承諾。承諾是第二次的估算。然後團隊就可以以此為共同的目標，努力的去實踐它了。
.
工程師如何估算工時？ 讓他依照團隊所制定的簡單規範來做預估，千萬不要讓工程師各自為政沒有一定的準則在做估算，上面的二個簡單規則，歡迎參考，我稱它為「信心點估算」，信心點越提前，我們就能越快獲得工程師的承諾。而提前的因素很多，多做測試就是一個，請這方面的專家來演講也是一個。
.
為什麼要給工程師二次估算的機會呢? 因為這樣做是值得的。
.
(還記得實施Scrum的時候，會要求團隊自我管理時要制定簡單的規範嗎? 這就是了! 但我還是囉嗦一下，執行簡單規則要成功必須有一個要素，那就是「共識」! 一定要有共識；讓團隊、老闆看一下這篇文章，討論一下，制定你們自己的規則。造成共識是成功的第一步…)
.
※ 至於對團隊的專案預估。如果你還在採用一個人一天工作八小時來作估算! (我的天啊!這個時代還有人這麼做嗎? )請問你上班時不開會或接電話或上網嗎? 這個議題待下回再聊了!
.
值得參考的一本書: [軟件估算：“黑匣子”揭秘]， by: Steve McConnell
Ruddy Lee 分享空間 
