摘要
本文討論了一個作者參與的軟件項目的項目計劃制訂的若干問題．項目所開發的產品是一種智能電子教學設備，該設備可以實時同步地將用戶在硬件端的書寫內容顯示在計算機屏幕上，並可以保存、編輯、打印用戶輸入的數據，聯網的計算機也可以實時觀看用戶的書寫過程，並且用戶還可以通過投影在硬件端的PC機畫面交互操作PC機．
作者是該項目的軟件開發組負責人兼軟件架構師．作者針對項目計劃的制定採取了：分而治之，逐步求精，經驗數據三個主要策略，從而得到較好的效果．
正文
2002年6月，作者所在公司啓動了一個項目，該項目開發出來的產品是一種智能教學設備，該設備可以實時同步地將用戶在硬件端的書寫內容顯示在計算機屏幕上，用戶可以保存、編輯、打印通過硬件端輸入到計算機的書寫內容，聯網的計算機也可以實時觀看用戶的書寫過程．另外，用戶還可以通過投影在硬件端的PC機顯示畫面交互地操作PC機．作者有幸全程參與該項目的開發，並且擔任了項目PC機軟件開發組的負責人兼軟件構架師的角色．對於這種實時通信且具有聯網功能的軟件項目，我認爲首先需要制定一個良好的項目計劃，纔可以保證項目開發的成功
總結這次項目的經驗，我認爲行之有效的策略有三個，分別是分而治之、逐步求精、經驗數據。下面就結合這三個策略詳細討論本次項目計劃的制訂。
一、分而治之
將一個過於複雜的問題分解成若干複雜度不那麼高的小間題來依次解訣，這種方法人類已經採用了幾千年．這裏我們也可以用於項目計劃的制定．因爲整個考慮項目的方方面面來制定計劃其複雜度已經超過了人類處理問題的能力．爲了解決這個問題，可以將整個項目分解爲一些更小的組織體，逐一進行處理，這項工作也就是項目管理中的WBS（工作分解結構）。
比如針對這次項目中採取的RUP開發過程模型，我在完成需求管理計劃時我就將計劃內容分解成初始、細化、構建、移交四個階段來分別制定，最後合到一塊兒就是完整的需求管理計劃．
除了按時間段分解的角度來制定項目計劃，我制訂軟件開發計劃時同時按照了RUP過程方法的工作流的概念來分解項目計劃的制定工作，根據每個工作流在四個階段業界通用的工作量估計來制定計劃，安排工作人員以及相應的軟件資源。因爲軟件開發計劃涉及到多個工作流，我認爲以這種方式分解是合理的．同時因爲本項目的特點，我省略了業務建模工作流，這是因爲這次的產品是以硬件爲主，軟件爲輔的消費類產品，所以業務建模不是那麼必要了．以不同的方式分解項目，可以從多個不同的角度來制定整個項目計劃，有利於全面、深入地瞭解項目，避免“瞎子摸象”的情況發生．
二、逐步求精
計劃工作其實是一種管理未來、管理未知的工作，而未來是變化莫測的，還存在許多自身無法掌握的因素，因此存在很大的難度．而解決這一困難的法寶就是逐步求精．按照先框架後細節，先粗後細地進行項目的計劃．
比如在這個項目中，在接受這個項目後就開始了做了一個初步計劃，這個計劃的內容主要是做出時間上的安排．因爲打算在2003年的月需要用這個項目的產品申請國家中小企業創新基金的支持，所以完成時間就定在了2003年4月，預留一個月用於寫申請報告．總的時間進度確定後，大概分配了三個時間段：系統工程分析、軟件開發模型確定、軟件產品製造時間段、項目總結．
等到確定這改項目後的RUP 開發模型後，就可以繼續對項目計劃進行第二改求精了。其實RUP 過程中出體現了逐步求精的理念，比如在初始與細化兩個階段都要產生出項目計劃的製品．這樣我就可以在這個兩個階段對項目計劃逐步求精，比如在初始階段只是將我需要完成的項目計劃分爲了需求管理計劃、軟件開發計劃、實施計劃，然後在細化階段我再具體地制定每類計劃的詳細內容．
比如在初始階段時架構設計考慮以MFC爲平臺，根據這個決定軟件開發計劃的制定是比較粗略的，在細化階段架構設計進一步詳細，這時已經清楚各個模塊和MFC的Doc/View主結構的接口定義，以及各模塊之間的接口定義，這時我就可以根據所需開發的模塊制定計劃。比如這時我就計劃了特效界面模塊開發分兩次迭代，第一次迭代計劃一個月時間，第二次迭代兩週時間，第一次迭代需要完成放大和縮小、樹形選擇、縮略顯示等主要的界面效果，第二次迭代的主要任務是根據用戶反饋進行修改調整．
三、經驗數據
要制定一個良好的計劃離不開精確的估算．不過項目計劃是在項目開發的早期制定的，而在早期要完成精確的估算是非常困難的．要解決這個問題的關鍵就在於“經驗數據”．由於整個軟件產業都還十分年輕，經驗數據的積累都普遍不足，才導致這一現象的出現．
但是因爲這次項目開發的產品在國內還沒有開發過，再加上公司沒有積累深厚系統的項目歷史數據．針對面臨的困難，我選用了FP功能點分析作爲項目主要的估算方法．因爲FP方法中有大量項目經驗數據可以從網絡上獲得，同時其數據功能TLF、EIF，以及事務功能EI、EO、EQ的計算對經驗數據依賴不強，只需對概念理解正確一般就可以正確估算了．在估算成本的時候，因爲公司以前的生產率數據是以LOC爲單位的，我利用軟件工程書籍中的“逆火”經驗數據，將LOC轉換爲功能點單位，當然，這裏必然導致一些誤差。爲了降低估算誤差，最後使用Delphi專家分析法對估算結果進行了調整．
Delphi方法是一種集策法，也就是通過多名專家對估計值的不斷校正的方法．當然，請專家增加了項目成本，不過最後得到高質量的項目計劃還是值得的．比如，在某專家的建議下我們改變了自行開發網絡層組件的計劃，而是採購現有的完全可以解決項目需求的成熟的中間件產品，這個策略的調整在後來證明是正確的．一開始犯錯誤的原因是由於我們網絡開發經驗不足把用戶需求想複雜了．
最後談一下使用的工具軟件．在制定項目計劃過程中我採用了Microsoft的Project 2003繪製甘特圖．因爲項目的進度安排是和項目中每個人都是息息相關的，所以在做甘特圖前我首先徵集了大家對文字和條形圖效果的意見，然後按大家的意見進行了美化，比如用鮮豔的顏色標識關鍵任務，放大任務摘要信息，突出里程碑信息等．這在有些項目管理者看來似乎是小事，不過我認爲一個賞心悅目的甘特圖可以帶給觀看者好的心情，而好的心情可以大大提高工作效率。
同時，考慮創新基金支持的項目在交互期限上有很大壓力，所以在定義甘特圖任務的依賴關係時我採取了業界慣用的“時間盒”的技術，也就是在每個任務的任務信息對話框中“前置任務”一欄中的“延隔時間”我填入5%-15%，也就是說當任務完成90%左右時就可以結束轉而執行下一個任務．因爲本項目中的所有人員幾乎是全程參與，所以我不是很擔心每個任務遺留的少量問題在下一階段沒有負責人去解訣。
配合Project 2003使用的估算軟件是Software Productivity Research的KnowledgePlan.這款工具軟件的最新版加強了對Microsoft Project 2003以及RUP開發模型的支持，而且其中的Project Template功能允許用戶採用自己定製的WBS來進行估算，這些因素使得KnowledgePlan對本項目的項目計劃成功制定帶來很大的幫助．
在上述三個策略的指導下，以及合適工具的輔助下，使最後形成的計劃有效地指導了後期的開發活動。項目開發出來的產品通過了專家的鑑定，獲得了國家中小企業創新基金的支持．
項目完成後發現的問題是早期計劃的估算結論偏差還是較大，看來還是受到缺乏經驗數據或者經驗數據不夠精確的影響，所以在以後的工作中需要開展有效的度量的工作，爲公司積累覆蓋面廣且儘量精確的經驗數據．