9.項目管理方面的工作。
項目管理工作主要有編制項目計劃、持續(xù)更新項目計劃、跟蹤計劃執(zhí)行、各種工作協調、指導項目組成員完成工作等等。
項目管理工作量一般占整個項目工作量的10-20%，項目不明確的東西越多、項目組成員水平越不足、項目組成員之間工作磨合度越不好，管理工作量越大。
項目管理在項目進行整個過程都需要持續(xù)進行，一般來說前期工作量會比較大，版本發(fā)布前后階段工作量也會比較大。項目管理前期工作抓得緊抓得好，會大大減輕后期的工作量。
10配置管理方面的工作。
什么叫配置管理？簡單說是對工作產品的管理，包括對各類文檔、各種記錄、代碼、數據庫、腳本、安裝程序、組件等等的管理。
軟件生產過程的工作產品可分為兩類：中間產物和終產物。
中間產物有：
1）工程類：需求文檔、設計文檔、測試方案、代碼、數據庫腳本、數據庫、測試腳本等。
2）管理類：開發(fā)計劃、測試計劃、培訓計劃、采購計劃、實施計劃等。
3）記錄類：會議記錄、郵件、缺陷等。
終產物是指終會交付給客戶的東西，一般有：組件、安裝程序、數據庫、用戶手冊、管理員手冊等。
針對不同的工作產品應采取不同的針對性管理辦法，很多公司會制定單獨的配置管理計劃。
11.質量保證方面的工作。
嚴格來說，質量保證是靠項目組全體來保證的，這里所說的質量保證是“狹義”的質量保證，是指：要確保項目組按照既定的規(guī)定、過程、標準來工作，需按照既定的格式要求產出相應工作產品。
對于以上十一點，實際項目估算中往往出現這樣的問題：
1.忘記包含項目前期工作的工作量。
2.沒有考慮商務、維護、配置管理、質量保證方面的工作。
3.需求調研、軟件設計、編碼、測試、實施方面的工作估計過少。
4.項目管理方面的工作量估計不足。
估算如何做出來？
這里開始所說的估算，全部都是指項目組對項目的估算，這個估算的目的是用來指導項目的具體工作。
有很多種估算辦法，大致可以分為兩類：
1.先得到軟件規(guī)模，然后根據公司實際的生產率由軟件規(guī)模導出工作量。
2.直接得到工作量。
第一類的常見方法有：功能點法、代碼行法，第二類的常見方法有Delphi估算法、微軟的由底而上估算法。
什么是軟件規(guī)模？我們先看看一個搬磚頭的估算。
假設有1000塊磚頭，它們的大小和重量一樣，每名工人每天能搬100塊磚頭，于是我們可以估算到需要10人日來搬完。10人日的意思是1名工人需要10天完成，而10名工人只需要1天搞定了。
這個1000塊代表了工作的規(guī)模，而生產率是100塊/日，這樣可以推算出工作量為10人日。建筑工程可以得到土石方量、混凝土量、鋼筋量等代表工作規(guī)模的數據，這樣比較容易推算出完成這些工作需要的工作量。
而軟件工程估算也希望能做到類似的效果，但用什么來代表軟件項目的工作規(guī)模呢？功能點和代碼行是常見的兩種軟件規(guī)模表示方式。
軟件規(guī)模是與軟件具體生產技術、項目管理辦法、項目組人員水平等無關的東西，軟件規(guī)模只和軟件項目本身的性質相關，如果我們能找到合適的統一的標準來度量每個項目的規(guī)模，這樣每個軟件項目之間可以進行橫向比較了。功能點法和代碼行法都希望能達致這樣的效果。
功能點法的基本思路是將復雜的軟件分解為一個一個獨立的粒度一致的功能點，附加一些調整系數，得到軟件規(guī)模。
我們的項目大部分是數據庫四輪馬車的操作（查詢、增加、修改、刪除），功能點法從比較高的層次對這些工作進行抽象，有一套嚴密的規(guī)則可以讓你將需求分解成一個一個的功能點。代碼行法思路也類似，不過分解的結果是代碼行而已。但一般來說代碼行與軟件的實現技術相關度太大，大家會更加偏愛功能點法。
功能點法和代碼行法有比較長的歷史，也有很多詳細資料，大家可以去查閱一下。這方法理論上很理想，但實踐效果很差，我還沒有見到一家能成熟應用并且取得比較好效果的公司。功能點法和代碼行法有這樣的一些難以解決的問題：
1.只適用于數據庫四輪馬車的操作的項目，高技術含量、創(chuàng)造性高的軟件不適用，如游戲軟件、計算機負責計算與決策軟件等。
2.我們絕大部分項目是需求不明確、設計不明確，并且工期很趕的，這兩個方法都無法適應這樣的現實條件。需求不明確基本上無法得到軟件規(guī)模，建筑工程為什么能做到，是因為需求和設計都十分明確了。
3.兩個方法的規(guī)則都很詳細，要花大量時間學習和實戰(zhàn)才能掌握。
4.由工作規(guī)模導出工作量這樣的思考方式，難以適用于軟件項目。項目組還是習慣列出具體的任務，逐條任務估計時間，而且只有這樣的工作方式才能讓項目組感覺更加踏實。
Dephi估算法是比較符合大家實際工作習慣，也是比較容易掌握的估算辦法。
Delphi法的大致方法如下：
1.找?guī)酌麑＜遥黄饘椖窟M行WBS，把項目的工作分解為十幾條多二三十條的工作項。
2.全部專家各自估計每條工作項的工作量，并向其他專家闡述自己的理由。
3.第一次各專家估出來的結果可能差異比較大，每位專家聽取別人的意見后，重新估算。
4.按照上述辦法，各專家反復估算幾次，一般次數是2-4次，各專家估計的工作量會越來越趨近，這個時候取全部專家的平均值。
普遍認為各專家的經驗與知識水平會嚴重影響結果的準確性，而我的實踐經驗是：應該讓項目組每個人自己來估算，也是讓大家來當專家，在這個基礎上可以再增加一兩名來自項目組外部的專家。
有時候覺得估算這個問題搞得太復雜了，各式各樣的方法是不是太夸張了？其實簡單的方法是讓負責該項工作的人自己來估計工作量，微軟的由底而上的估算方法是這樣做的，可謂返璞歸真啊！
