這個項目要多久開發完成?

>>>  技術話題—商業文明的嶄新時代  >>> 簡體     傳統

 英文原文: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

[新一篇] 這些年 馬云犯過的4個大錯

[舊一篇] 孤獨星球公布世界十大必看奇跡:中國獨占三處
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表