摘要

　　本文討論了一個作者參與的軟件項目的項目計劃制訂的若干問題．項目所開發(fā)的產品是一種智能電子教學設備，該設備可以實時同步地將用戶在硬件端的書寫內容顯示在計算機屏幕上，并可以保存、編輯、打印用戶輸入的數據，聯網的計算機也可以實時觀看用戶的書寫過程，并且用戶還可以通過投影在硬件端的PC機畫面交互操作PC機．

　　作者是該項目的軟件開發(fā)組負責人兼軟件架構師．作者針對項目計劃的制定采取了：分而治之，逐步求精，經驗數據三個主要策略，從而得到較好的效果．

　　正文

　　2002年6月，作者所在公司啟動了一個項目，該項目開發(fā)出來的產品是一種智能教學設備，該設備可以實時同步地將用戶在硬件端的書寫內容顯示在計算機屏幕上，用戶可以保存、編輯、打印通過硬件端輸入到計算機的書寫內容，聯網的計算機也可以實時觀看用戶的書寫過程．另外，用戶還可以通過投影在硬件端的PC機顯示畫面交互地操作PC機．作者有幸全程參與該項目的開發(fā)，并且擔任了項目PC機軟件開發(fā)組的負責人兼軟件構架師的角色．對于這種實時通信且具有聯網功能的軟件項目，我認為首先需要制定一個良好的項目計劃，才可以保證項目開發(fā)的成功．

　　總結這次項目的經驗，我認為行之有效的策略有三個，分別是分而治之、逐步求精、經驗數據。下面就結合這三個策略詳細討論本次項目計劃的制訂。

　　一、分而治之

　　將一個過于復雜的問題分解成若干復雜度不那么高的小間題來依次解訣，這種方法人類已經采用了幾千年．這里我們也可以用于項目計劃的制定．因為整個考慮項目的方方面面來制定計劃其復雜度已經超過了人類處理問題的能力．為了解決這個問題，可以將整個項目分解為一些更小的組織體，逐一進行處理，這項工作也就是項目管理中的WBS（工作分解結構）。

　　比如針對這次項目中采取的RUP開發(fā)過程模型，我在完成需求管理計劃時我就將計劃內容分解成初始、細化、構建、移交四個階段來分別制定，最后合到一塊兒就是完整的需求管理計劃．

　　除了按時間段分解的角度來制定項目計劃，我制訂軟件開發(fā)計劃時同時按照了RUP過程方法的工作流的概念來分解項目計劃的制定工作，根據每個工作流在四個階段業(yè)界通用的工作量估計來制定計劃，安排工作人員以及相應的軟件資源。因為軟件開發(fā)計劃涉及到多個工作流，我認為以這種方式分解是合理的．同時因為本項目的特點，我省略了業(yè)務建模工作流，這是因為這次的產品是以硬件為主，軟件為輔的消費類產品，所以業(yè)務建模不是那么必要了．以不同的方式分解項目，可以從多個不同的角度來制定整個項目計劃，有利于全面、深入地了解項目，避免“瞎子摸象”的情況發(fā)生．

　　二、逐步求精

　　計劃工作其實是一種管理未來、管理未知的工作，而未來是變化莫測的，還存在許多自身無法掌握的因素，因此存在很大的難度．而解決這一困難的法寶就是逐步求精．按照先框架后細節(jié)，先粗后細地進行項目的計劃。

　　比如在這個項目中，在接受這個項目后就開始了做了一個初步計劃，這個計劃的內容主要是做出時間上的安排．因為打算在2003年的月需要用這個項目的產品申請國家中小企業(yè)創(chuàng)新基金的支持，所以完成時間就定在了2003年4月，預留一個月用于寫申請報告．總的時間進度確定后，大概分配了三個時間段：系統工程分析、軟件開發(fā)模型確定、軟件產品制造時間段、項目總結．

　　等到確定這改項目后的RUP 開發(fā)模型后，就可以繼續(xù)對項目計劃進行第二改求精了。其實RUP 過程中出體現了逐步求精的理念，比如在初始與細化兩個階段都要產生出項目計劃的制品．這樣我就可以在這個兩個階段對項目計劃逐步求精，比如在初始階段只是將我需要完成的項目計劃分為了需求管理計劃、軟件開發(fā)計劃、實施計劃，然后在細化階段我再具體地制定每類計劃的詳細內容．

　　比如在初始階段時架構設計考慮以MFC為平臺，根據這個決定軟件開發(fā)計劃的制定是比較粗略的，在細化階段架構設計進一步詳細，這時已經清楚各個模塊和MFC的Doc/View主結構的接口定義，以及各模塊之間的接口定義，這時我就可以根據所需開發(fā)的模塊制定計劃。比如這時我就計劃了特效界面模塊開發(fā)分兩次迭代，第一次迭代計劃一個月時間，第二次迭代兩周時間，第一次迭代需要完成放大和縮小、樹形選擇、縮略顯示等主要的界面效果，第二次迭代的主要任務是根據用戶反饋進行修改調整。

　　三、經驗數據

　　要制定一個良好的計劃離不開精確的估算．不過項目計劃是在項目開發(fā)的早期制定的，而在早期要完成精確的估算是非常困難的．要解決這個問題的關鍵就在于“經驗數據”．由于整個軟件產業(yè)都還十分年輕，經驗數據的積累都普遍不足，才導致這一現象的出現。

　　但是因為這次項目開發(fā)的產品在國內還沒有開發(fā)過，再加上公司沒有積累深厚系統的項目歷史數據．針對面臨的困難，我選用了FP功能點分析作為項目主要的估算方法．因為FP方法中有大量項目經驗數據可以從網絡上獲得，同時其數據功能TLF、EIF，以及事務功能EI、EO、EQ的計算對經驗數據依賴不強，只需對概念理解正確一般就可以正確估算了．在估算成本的時候，因為公司以前的生產率數據是以LOC為單位的，我利用軟件工程書籍中的“逆火”經驗數據，將LOC轉換為功能點單位，當然，這里必然導致一些誤差。為了降低估算誤差，最后使用Delphi專家分析法對估算結果進行了調整。

　　Delphi方法是一種集策法，也就是通過多名專家對估計值的不斷校正的方法．當然，請專家增加了項目成本，不過最后得到高質量的項目計劃還是值得的．比如，在某專家的建議下我們改變了自行開發(fā)網絡層組件的計劃，而是采購現有的完全可以解決項目需求的成熟的中間件產品，這個策略的調整在后來證明是正確的．一開始犯錯誤的原因是由于我們網絡開發(fā)經驗不足把用戶需求想復雜了。

　　最后談一下使用的工具軟件．在制定項目計劃過程中我采用了Microsoft的Project 2003繪制甘特圖．因為項目的進度安排是和項目中每個人都是息息相關的，所以在做甘特圖前我首先征集了大家對文字和條形圖效果的意見，然后按大家的意見進行了美化，比如用鮮艷的顏色標識關鍵任務，放大任務摘要信息，突出里程碑信息等．這在有些項目管理者看來似乎是小事，不過我認為一個賞心悅目的甘特圖可以帶給觀看者好的心情，而好的心情可以大大提高工作效率。

　　同時，考慮創(chuàng)新基金支持的項目在交互期限上有很大壓力，所以在定義甘特圖任務的依賴關系時我采取了業(yè)界慣用的“時間盒”的技術，也就是在每個任務的任務信息對話框中“前置任務”一欄中的“延隔時間”我填入5%-15%，也就是說當任務完成90%左右時就可以結束轉而執(zhí)行下一個任務．因為本項目中的所有人員幾乎是全程參與，所以我不是很擔心每個任務遺留的少量問題在下一階段沒有負責人去解訣。

　　配合Project 2003使用的估算軟件是Software Productivity Research的KnowledgePlan.這款工具軟件的最新版加強了對Microsoft Project 2003以及RUP開發(fā)模型的支持，而且其中的Project Template功能允許用戶采用自己定制的WBS來進行估算，這些因素使得KnowledgePlan對本項目的項目計劃成功制定帶來很大的幫助。

　　在上述三個策略的指導下，以及合適工具的輔助下，使最后形成的計劃有效地指導了后期的開發(fā)活動。項目開發(fā)出來的產品通過了專家的鑒定，獲得了國家中小企業(yè)創(chuàng)新基金的支持。

　　項目完成后發(fā)現的問題是早期計劃的估算結論偏差還是較大，看來還是受到缺乏經驗數據或者經驗數據不夠精確的影響，所以在以后的工作中需要開展有效的度量的工作，為公司積累覆蓋面廣且盡量精確的經驗數據。