>>>  技術話題—商業文明的嶄新時代  >>>

簡體     傳統

　英文原文：How long would this project take?

　　這個問題是我最常碰到的一個，也是我最難回答的一個。對這種問題最好的回答方式是用全職員工來推算天數。這非常容易，你只需要找出有多少個不重疊的功能特征，然后每個人負責一個。一旦各個功能塊被分成了不能再分的任務，你計算需要多少人天，這就是你的答案。你無論如何都不可能用比這更少的時間開發完這個項目。

“一個女人生一個孩子要10個月，不論你再增加多少個女人來做這事，都不會縮短這個時間”

“只有當一個任務的完成可以分配多人，并且不需要他們之間相互交流合作的情況下能完成時，人和月才能互相替換。”

“往一個已經延遲的項目里添加程序員只會使項目進一步延遲”(因為項目中現有的人需要培訓新來的人)

-《人月神話》

　　不幸的是，大部分人只想知道一個項目需要多少時間完成。這實際是個偽命題，因為90%軟件成本的產生是發生在軟件發布之后。這些費用會產生于修復bug、增加欠缺的功能、性能的改進、對新平臺進行支持(安卓就是一個大債主)或重寫質量差的老代碼來減少技術債務。即使是項目發布前，對于如何合適的處理每一種報錯情況，這也是無法預先估計全的。從某種程度上，你就是被別人問了這樣一個問題：“我有一個問題，我想解決它，但我無法說清問題是什么。請問解決這個問題需要多少時間？”

　　盡管預估很難，但程序員最終要找到一種預估的方法。雖然無法知道一個確切的答案，但我有3種方法能大致估計出一個軟件項目要花多少時間：

1. 想要搞清楚一個事情需要多少時間完成，這最好的方法是找一個程序員已經完成的、相似的項目。對一些簡單的網站和應用來說非常有效，或者那些使用標準CRUD的項目也是適用。當項目小且簡單時這種方法最好用。這種方法可以用在軟件1.0版本時，但以后的版本就不行了，因為這時你跟相參照的項目開始慢慢的產生差異，這時寫的代碼是你以前沒有寫過的。
2. 我的好朋友、并且是以前的同事John Walker(不是這個John Walker)喜歡用這種方法。把項目拆解成最小的任務。然后記錄完成每個任務你認為可能需要多少小時、天、周、月。遵循這種原則，如果一個任務需要幾小時，就是算成一天，如果需要數天，就是算成一周，如果是數周，就算成一月。如果超過一個月，那你就無法知道需要多少時間了，或你根本不知道要做什么。
3. 我有自己的預估方法，但事實上跟John的把任務拆分成最小的子任務的方法非常相似。我是以最壞的情況下每個最小單元需要的完成時間為標準。匯總，然后乘以4。再向上取舍到最近的素數，就算是對我的這種沒譜的方法的諷刺吧。

　　對于大型的、獨特的項目，程序員幾乎無法知道它需要多少時間開發。它就是像在問“需要花多少時間能找到治療癌癥的方法？”然而，大部分的管理部門都拒絕接受這種答案，于是，程序員只好玩一些花招，先弄清楚老板們希望聽到的時間，然后加入一些余地。還能有什么辦法？通常都是超近路，這都是因為要去追趕那個本不應該設置的最后期限。你需要明白，預估是困難的，需要運行計劃上的變更。除非你的程序員能將任務拆分小于一個月的子任務，千萬不要在軟件發布時間上做任何市場活動計劃。

　　這最后一件需要注意的事是，當你在一個現有的軟件(比如2.0版，3.0版….)上增加新功能時，你需要追加20%用來對現有代碼進行重寫的時間(程序員稱之為重構)。這是為了償還技術債務，或為未來的行動鋪路。人們以為Google是拿出20%的時間用來創新，但我敢打賭，其實這大部分是來償還技術債務的。

　　估計一件事情要花多少事情是非常難的，通常也是不可能的。雖然你曾在一些小項目上有成功的預測，但隨著項目的發展你會感覺到越來越難。一個好的方法是給程序員留足額外的時間。很多年輕的程序員通常沒有這方面的經驗，所以，項目經理必須把他們估計出的時間乘以4。

網載 2014-07-03 10:56:36