項目計劃技巧對于現今的軟件開發(fā)人員來說是必需的。這里有一些幫助您有效地計劃下一個項目的建議。

　　認識到信心來自規(guī)劃的過程，而不是計劃本身。

　　創(chuàng)建項目計劃會迫使您早在編寫代碼之前就考慮如何構建您的系統？？減少項目的風險，因為您已經考慮了各種策略和方法并且已經選擇了最有意義的一項。您的目的不應該只是不花氣力產生一個計劃；它應該是一個實際可行的計劃，您可以根據它來成功管理您的項目。

　　軟件過程推動計劃的開發(fā)每個軟件過程都有一個不同的集合，它包括組織團隊的活動方法以及規(guī)劃項目常用的技術。由于這個原因，基于 Rational Unified Process （RUP）的項目規(guī)劃不同于OOSP項目的規(guī)劃，而OOSP項目的規(guī)劃也不同于eXtreme Programming （XP） 項目的規(guī)劃。不同的過程有不同的計劃。

　　從粗粒度的計劃開始在項目將要開始時，應該制定一個粗粒度的、確定項目高級活動和預期里程碑的計劃。粗粒度的計劃將組織成迭代？？根據項目的大小和性質，每次迭代通常在三周到八周之間發(fā)生（四周到六周為更佳）。其中一些迭代將集中在項目初期，而很多迭代將集中在整個應用的功能部分開發(fā)，還有一些迭代集中在將您的系統轉變成產品。

　　實施者應該是計劃人員創(chuàng)建項目計劃的最佳人員是負責實施該計劃的人員。當規(guī)劃由一個人創(chuàng)建而由另一個人實施時，如果項目不能按時完成或超出預算，他們不太會相信計劃，而很有可能會責備它。也就是說，參與項目的每個人都應該投入到項目計劃的開發(fā)和進展中。

　　不要忘記“不該忘記的事”

　　計劃不僅要反映需求設計、建模、編程和測試的“真實”工作，而且還應該反映輔助活動（然而仍是重要的），它包括：休假和法定假日、培訓和教育、項目管理活動（如規(guī)劃和人員管理）、開銷（如系統當機時間、會議和回復電子郵件）、體系結構定義、測試之后的系統返工、系統交付、與重用相關的活動（如普遍化）。

　　將任何設想和約束編入文檔規(guī)劃時您總要作一些假設，如能夠及時獲得應用程序服務器的新發(fā)行版，或可以得到熟悉您正在應用的技術和技巧的開發(fā)人員。同時，您將在一些約束下工作，如影響計劃的強制截止期限或資源限制。將這些假設和約束編入文檔，這樣，當您實施項目的任何時候更新計劃時，都可以記起您先前做出的一些“不尋常”決定。

　　認識到不同的資源意味著不同的計劃十名有經驗的開發(fā)人員組成的團隊創(chuàng)造出的成效要遠遠多于十名初學者組成的團隊所創(chuàng)造的成效。要想更加實際的話，您的計劃必須反映項目可使用的資源的真實情況。

　　創(chuàng)建現實的計劃項目組必須相信其項目的目的、估價和時間表。要做到這點，您必須真實地規(guī)劃，避免規(guī)劃超出您能理解的范圍。僅當您打算研究未知事項時，才能容忍無知。

　　只規(guī)劃有價值的事IBM DeveloperWorks 網站提供了許多可應用于您項目的最佳實踐。然而，根據項目的性質，不是所有這些技術都將適合于您的獨特情況。要將這些最佳實踐簡單地看作是您放置在“項目管理工具箱”中的工具，您可以根據需要適當使用這些工具。

　　適當使用項目管理工具一些項目管理工具，如Microsoft Project，提供了重要功能 如Gantt圖表（活動時間表）的開發(fā)、規(guī)劃與實際結果的比較、PERT 圖表（網絡圖表）的開發(fā)、任務的定義、任務之間相關性的定義、對任務的資源分配和資源平衡。所有這些事情似乎象是一個好主意，并且它們通常是好主意，但它們還需要許多精力來創(chuàng)建和維護，而且很少為項目組提供實際價值。的確，它讓一些項目管理人員感到富有成效。的確，高級管理喜歡看見您有一個計劃。但是，沒有一行代碼是由所有這個活動產生的。規(guī)劃是有價值的活動；但投入大量的時間來創(chuàng)建規(guī)劃圖表通常不是有價值的活動。