摘要本文討論了一個作者參與的軟件項目的項目計劃制訂的若干問題項目所開發的產品是一種智能電子教學設備，該設備可以實時同步地將用戶在硬件端的書寫內容顯示在計算機屏幕上，并可以保存、編輯、打印用戶輸入的數據，聯網的計算機也可以實時觀看用戶的書寫過程，并且用戶還可以通過投影在硬件端的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對本項目的項目計劃成功制定帶來很大的幫助在上述三個策略的指導下，以及合適工具的輔助下，使最后形