這個問題是我最常碰到的一個，也是我最難回答的一個。對這種問題最好的回答方式是用全職員工來推算天數。這非常容易，你只需要找出有多少個不重疊的功能特徵，然後每個人負責一個。一旦各個功能塊被分成了不能再分的任務，你計算需要多少人天，這就是你的答案。你無論如何都不可能用比這更少的時間開發完這個項目。
| “一個女人生一個孩子要10個月，不論你再增加多少個女人來做這事，都不會縮短這個時間”
“只有當一個任務的完成可以分配多人，並且不需要他們之間相互交流合作的情況下能完成時，人和月才能互相替換。” “往一個已經延遲的項目裏添加程序員只會使項目進一步延遲”(因爲項目中現有的人需要培訓新來的人) -《人月神話》 |
不幸的是，大部分人只想知道一個項目需要多少時間完成。這實際是個僞命題，因爲90%軟件成本的產生是發生在軟件發佈之後。這些費用會產生於修復bug、增加欠缺的功能、性能的改進、對新平臺進行支持(安卓就是一個大債主)或重寫質量差的老代碼來減少技術債務。即使是項目發佈前，對於如何合適的處理每一種報錯情況，這也是無法預先估計全的。從某種程度上，你就是被別人問了這樣一個問題：“我有一個問題，我想解決它，但我無法說清問題是什麼。請問解決這個問題需要多少時間？”
儘管預估很難，但程序員最終要找到一種預估的方法。雖然無法知道一個確切的答案，但我有3種方法能大致估計出一個軟件項目要花多少時間：
1.想要搞清楚一個事情需要多少時間完成，這最好的方法是找一個程序員已經完成的、相似的項目。對一些簡單的網站和應用來說非常有效，或者那些使用標準CRUD的項目也是適用。當項目小且簡單時這種方法最好用。這種方法可以用在軟件1.0版本時，但以後的版本就不行了，因爲這時你跟相參照的項目開始慢慢的產生差異，這時寫的代碼是你以前沒有寫過的。
2.我的好朋友、並且是以前的同事John Walker(不是這個John Walker)喜歡用這種方法。把項目拆解成最小的任務。然後記錄完成每個任務你認爲可能需要多少小時、天、周、月。遵循這種原則，如果一個任務需要幾小時，就是算成一天，如果需要數天，就是算成一週，如果是數週，就算成一月。如果超過一個月，那你就無法知道需要多少時間了，或你根本不知道要做什麼。
3.我有自己的預估方法，但事實上跟John的把任務拆分成最小的子任務的方法非常相似。我是以最壞的情況下每個最小單元需要的完成時間爲標準。彙總，然後乘以4。再向上取捨到最近的素數，就算是對我的這種沒譜的方法的諷刺吧。
對於大型的、獨特的項目，程序員幾乎無法知道它需要多少時間開發。它就是像在問“需要花多少時間能找到治療癌症的方法？”然而，大部分的管理部門都拒絕接受這種答案，於是，程序員只好玩一些花招，先弄清楚老闆們希望聽到的時間，然後加入一些餘地。還能有什麼辦法？通常都是超近路，這都是因爲要去追趕那個本不應該設置的最後期限。你需要明白，預估是困難的，需要運行計劃上的變更。除非你的程序員能將任務拆分小於一個月的子任務，千萬不要在軟件發佈時間上做任何市場活動計劃。
這最後一件需要注意的事是，當你在一個現有的軟件(比如2.0版，3.0版….)上增加新功能時，你需要追加20%用來對現有代碼進行重寫的時間(程序員稱之爲重構)。這是爲了償還技術債務，或爲未來的行動鋪路。人們以爲Google是拿出20%的時間用來創新，但我敢打賭，其實這大部分是來償還技術債務的。
估計一件事情要花多少事情是非常難的，通常也是不可能的。雖然你曾在一些小項目上有成功的預測，但隨着項目的發展你會感覺到越來越難。一個好的方法是給程序員留足額外的時間。很多年輕的程序員通常沒有這方面的經驗，所以，項目經理必須把他們估計出的時間乘以4。
來源：外刊IT