假設(shè)有1000塊磚頭，它們的大小和重量一樣，每名工人每天能搬100塊磚頭，于是我們可以估算到需要10人日來搬完。10人日的意思是1名工人需要10天完成，而10名工人只需要1天就搞定了。
這個1000塊代表了工作的規(guī)模，而生產(chǎn)率就是100塊/日，這樣就可以推算出工作量為10人日。建筑工程可以得到土石方量、混凝土量、鋼筋量等代表工作規(guī)模的數(shù)據(jù)，這樣就比較容易推算出完成這些工作需要的工作量。
而軟件工程估算也希望能做到類似的效果，但用什么來代表軟件項目的工作規(guī)模呢?功能點和代碼行是常見的兩種軟件規(guī)模表示方式。
軟件規(guī)模是與軟件具體生產(chǎn)技術(shù)、項目管理辦法、項目組人員水平等無關(guān)的東西，軟件規(guī)模只和軟件項目本身的性質(zhì)相關(guān)，如果我們能找到合適的統(tǒng)一的標(biāo)準(zhǔn)來度量每個項目的規(guī)模，這樣每個軟件項目之間就可以進(jìn)行橫向比較了。功能點法和代碼行法都希望能達(dá)致這樣的效果。
功能點法的基本思路是將復(fù)雜的軟件分解為一個一個獨立的粒度一致的功能點，附加一些調(diào)整系數(shù)，得到軟件規(guī)模。
我們的項目大部分是數(shù)據(jù)庫四輪馬車的操作(查詢、增加、修改、刪除)，功能點法從比較高的層次對這些工作進(jìn)行抽象，有一套嚴(yán)密的規(guī)則可以讓你將需求分解成一個一個的功能點。代碼行法思路也類似，不過分解的結(jié)果是代碼行而已。但一般來說代碼行與軟件的實現(xiàn)技術(shù)相關(guān)度太大，大家會更加偏愛功能點法。
功能點法和代碼行法有比較長的歷史，也有很多詳細(xì)資料，大家可以去查閱一下。這方法理論上很理想，但實踐效果很差，我還沒有見到一家能成熟應(yīng)用并且取得比較好效果的公司。功能點法和代碼行法有這樣的一些難以解決的問題：
1.只適用于數(shù)據(jù)庫四輪馬車的操作的項目，高技術(shù)含量、創(chuàng)造性高的軟件不適用，如游戲軟件、計算機(jī)負(fù)責(zé)計算與決策軟件等。
2.我們絕大部分項目是需求不明確、設(shè)計不明確，并且工期很趕的，這兩個方法都無法適應(yīng)這樣的現(xiàn)實條件。需求不明確基本上無法得到軟件規(guī)模，建筑工程為什么能做到，是因為需求和設(shè)計都十分明確了。
3.兩個方法的規(guī)則都很詳細(xì)，要花大量時間學(xué)習(xí)和實戰(zhàn)才能掌握。
4.由工作規(guī)模導(dǎo)出工作量這樣的思考方式，難以適用于軟件項目。項目組還是習(xí)慣列出具體的任務(wù)，逐條任務(wù)估計時間，而且只有這樣的工作方式才能讓項目組感覺更加踏實。
Dephi估算法是比較符合大家實際工作習(xí)慣，也是比較容易掌握的估算辦法。
Delphi法的大致方法如下：
1.找?guī)酌Y深專家，一起對項目進(jìn)行WBS，把項目的工作分解為十幾條最多二三十條的工作項。
2.全部專家各自估計每條工作項的工作量，并向其他專家闡述自己的理由。
3.第一次各專家估出來的結(jié)果可能差異比較大，每位專家聽取別人的意見后，重新估算。
4.按照上述辦法，各專家反復(fù)估算幾次，一般次數(shù)就是2-4次，各專家估計的工作量會越來越趨近，這個時候取全部專家的平均值。
普遍認(rèn)為各專家的經(jīng)驗與知識水平會嚴(yán)重影響結(jié)果的準(zhǔn)確性，而我的實踐經(jīng)驗是：應(yīng)該讓項目組每個人自己來估算，也就是讓大家來當(dāng)專家，在這個基礎(chǔ)上可以再增加一兩名來自項目組外部的專家。
有時候覺得估算這個問題搞得太復(fù)雜了，各式各樣的方法是不是太夸張了?其實最簡單的方法就是讓負(fù)責(zé)該項工作的人自己來估計工作量，微軟的由底而上的估算方法就是這樣做的，可謂返璞歸真啊!
微軟由底而上的估算方法大致是這樣的：對項目各項工作進(jìn)行分解后(即俗稱的wbs：work breakdown structure，工作分解結(jié)構(gòu))，每個任務(wù)落實負(fù)責(zé)人，由負(fù)責(zé)人對自己的任務(wù)進(jìn)行估計。這個辦法有以下好處：
1. 最終該任務(wù)是由這個人來完成的，他估計多少時間才能