基本思路是將復雜的軟件分解為一個一個獨立的粒度一致的功能點，附加一些調整系數，得到軟件規(guī)模。
我們的項目大部分是數據庫四輪馬車的操作（查詢、增加、修改、刪除），功能點法從比較高的層次對這些工作進行抽象，有一套嚴密的規(guī)則可以讓你將需求分解成一個一個的功能點。代碼行法思路也類似，不過分解的結果是代碼行而已。但一般來說代碼行與軟件的實現技術相關度太大，大家會更加偏愛功能點法。
功能點法和代碼行法有比較長的歷史，也有很多詳細資料，大家可以去查閱一下。這方法理論上很理想，但實踐效果很差，我還沒有見到一家能成熟應用并且取得比較好效果的公司。功能點法和代碼行法有這樣的一些難以解決的問題：
1.只適用于數據庫四輪馬車的操作的項目，高技術含量、創(chuàng)造性高的軟件不適用，如游戲軟件、計算機負責計算與決策軟件等。
2.我們絕大部分項目是需求不明確、設計不明確，并且工期很趕的，這兩個方法都無法適應這樣的現實條件。需求不明確基本上無法得到軟件規(guī)模，建筑工程為什么能做到，是因為需求和設計都十分明確了。
3.兩個方法的規(guī)則都很詳細，要花大量時間學習和實戰(zhàn)才能掌握。
4.由工作規(guī)模導出工作量這樣的思考方式，難以適用于軟件項目。項目組還是習慣列出具體的任務，逐條任務估計時間，而且只有這樣的工作方式才能讓項目組感覺更加踏實。
Dephi估算法是比較符合大家實際工作習慣，也是比較容易掌握的估算辦法。
Delphi法的大致方法如下：
1.找?guī)酌Y深專家，一起對項目進行WBS，把項目的工作分解為十幾條最多二三十條的工作項。
2.全部專家各自估計每條工作項的工作量，并向其他專家闡述自己的理由。
3.第一次各專家估出來的結果可能差異比較大，每位專家聽取別人的意見后，重新估算。
4.按照上述辦法，各專家反復估算幾次，一般次數就是2-4次，各專家估計的工作量會越來越趨近，這個時候取全部專家的平均值。
普遍認為各專家的經驗與知識水平會嚴重影響結果的準確性，而我的實踐經驗是：應該讓項目組每個人自己來估算，也就是讓大家來當專家，在這個基礎上可以再增加一兩名來自項目組外部的專家。
有時候覺得估算這個問題搞得太復雜了，各式各樣的方法是不是太夸張了？其實最簡單的方法就是讓負責該項工作的人自己來估計工作量，微軟的由底而上的估算方法就是這樣做的，可謂返璞歸真?。?/SPAN>
微軟由底而上的估算方法大致是這樣的：對項目各項工作進行分解后（即俗稱的wbs：work breakdown structure，工作分解結構），每個任務落實負責人，由負責人對自己的任務進行估計。這個辦法有以下好處：
1. 最終該任務是由這個人來完成的，他估計多少時間才能做完，這個時間才是最接近實際的。
2. 負責該任務的人進行估算的時候，肯定需要認真思考這個任務的風險，需要做哪些具體的工作，這樣更容易在未開始工作之前就發(fā)現更多的潛在問題。相反如果由項目經理來分配時間，這個人就可能不會去思考這個任務了。
3. 做這個任務的人會有被重視和尊重的感覺，他會很重視自己承諾的完成時間，并且想法設法按時間完成。這樣會減少很多項目管理時間，因為每個任務負責人都會主動地跟蹤好自己的工作。
其實微軟這個方法根本就沒有什么特別，所有正常人都可以想到這個方法，但仍然有很多人去追求那些不太靠譜的估算方法。
這個方法還是有這樣的一些問題的：
1.有人會估算偏小，比方他說需要5天，但往往10天還完不成。
2.有人估算過于保守。
3.項目的進度要求就是很