古人云“萬事預則立，不預則廢”，項目要成功必須做好計劃。軟件項目策劃是項目管理過程中基本的一個過程，軟件項目策劃的方法是軟件項目經理必須掌握的。在實際的項目策劃過程中，必須掌握以下的9個基本要點......
(1)掌握好項目策劃的時機
軟件項目策劃過程的輸出是文檔化的項目計劃書，在項目的不同階段都需要進行項目策劃，只不過在不同時機項目策劃的目的不同，花費的工作量也不同。當有了概要的客戶需求而沒有形成詳細的軟件需求規格說明書(SRS)時，進行項目策劃產生的是項目的概要計劃或者是里程碑計劃，當產生了詳細的SRS 后，項目策劃活動可以產生項目的詳細計劃，可以明確估計項目的規模、工作量、進度、資源等，作為項目管理的主要依據。當發生了需求變化或者項目計劃與實際存在比較大的偏差時，可以對項目進行重計劃。需要提醒注意的是在需求未確定的時候，進行軟件的估計是比較粗略的，此時不需要在項目策劃上花費太多的精力。
(2)任務一定要明確
在進行項目策劃時，建立工作任務分解(WBS)是必須要做的工作，即把
工作拆分成一個個獨立的、明確的任務，所謂明確的任務是指：
該任務一定有一個輸出結果;
輸出的格式有明確的定義;
輸出的內容有明確的檢測手段與驗收標準;
任務的時間是有具體要求的。
上述4個判定標準有一個達不到不能稱為是一個明確的任務。在實踐中，有一些任務難以定義的很明確，因為有些結果是難以預測的，比如說分析工作，具體的時間要求是難以準確預測的。任務如果不明確，無從談起任務是否做完了。
在項目組中往往由于前一階段的工作沒做好，造成后續階段的任務難以明確定義下來。設計沒有做完，編碼的工作不能定義的很清楚，往往會造成實際的編碼工作難以在要求的時間內完工，形成項目風險。
(3)識別的任務不要有遺漏
在軟件策劃時，常犯的一個毛病是：任務沒有識別全。在項目的實際執行過程，經常出現計劃外的、又必須執行的項目組的任務，而不是項目組外的干擾活動。為了識別的任務比較完備，可以建立任務識別指南以提醒項目經理。經常遺漏的任務包括：
項目管理類的任務，如項目計劃、計劃的變更、計劃評審等;
橫向關聯類的任務，如集成任務、需求跟蹤矩陣的制定與更新等;
項目交付物的制作任務，如用戶手冊的編寫、培訓教材的編寫等;
(4)任務的顆粒度要適中
在劃分任務時，任務的顆粒度不能太大，也不能太小。顆粒度太大，難以及時發現問題;顆粒度太小，會增加管理成本。任務的顆粒度小可以到半天，大到周，一般以小于3天為宜，也是說，項目經理能夠在1周中至少檢查2次成員的工作進展情況。適當的任務顆粒度一方面便于監控，另一方面也有利于調整任務。當出現任務拖期時，可以比較靈活地重新安排人員接手其他人員的任務。
(5)估計要盡可能的合理
為了保證估計的合理性，可以采用下面的措施：
借助歷史數據。歷史數據是“經驗”的量化，通過和歷史項目的數據對比，
可以降低估計的風險。需要注意的是，在借鑒歷史數據的時候，要注意數據的可比性，要考察項目類型是否類似、生命周期模型是否類似等。
采用多種估計方法互相驗證。在估計時可以采用多種估計方法，然后對多種方法的結果進行對比，通過分析其差異以判斷合理性。
細分任務。任務拆分的越詳細，越容易估計，越容易和歷史數據對比。
任務要完備。在估計的時候，要識別出所有的工作內容，不要有遺漏。
有估計經驗的人參與估計。一方面要對參與估計的人員進行培訓，另一方面需要在實踐中積累估計經驗，每次估計完成后，都要和實際的情況進行對比，經過3～5次的反復，則可以積累估計的經驗，提高估計的準確性。
(6)識別清楚任務之間的依賴關系
任務和任務之間存在下面的5種依賴關系：
輸入輸出關系。即A任務的輸出是B任務的輸入，A任務完成后，B任務才可以開始。比如編碼和測試之間的關系。
資源依賴關系。即A任務和B任務使用同一個資源，當資源為A使用時，不能為B使用，當資源為B使用時，不能為A使用。例如一個程序員不能同時做2個模塊的開發，必須做完一個模塊再做另一個模塊。
需求之間的接口關系。即A任務和B任務的輸出存在接口，2個部分的輸出需要組裝在一起，如果組裝的任務是C，則A，B任務未完成，C任務也無法開始。
調用關系。主要是對編碼任務而言，任務A的代碼為任務B的代碼所調用，則A必須先完成。
采購關系。如果存在需要采購的外部構件的話，則采購行為必須先完成。
定義了任務之間的依賴關系，可以識別出項目的關鍵路徑，以重點關注關鍵路徑。
(7)優先安排與系統架構有關的需求的開發
要優先安排關鍵功能需求、全局性功能需求、接口需求、非功能需求的開發，這些需求影響的范圍比較廣，一旦返工，工作量比較大，因此在安排任務前要先安排這些需求的設計、實現、測試與聯調。在計劃時若沒有安排好任務的順序，會造成在項目的后期階段比如聯調時，發現有些模塊無法聯調，需要寫測試程序或者等待其他模塊的完成。
(8)建立項目的里程碑
在項目進展的過程中，項目經理、PPQA、CM等從項目的不同的側面對項目組的進展進行了跟蹤，但是缺乏全面、系統地分析與評價，借助里程碑評審可以綜合各方面的分析數據進行判斷。在項目的里程碑處，一般是通過里程碑評審全面地對項目組外部的成員展示項目的進展，以判斷上一階段的工作是否完成，是否可以進入下一個階段。很多企業往往將里程碑評審搞成了一種形式，成了走過場，這違背了里程碑評審的初衷。在里程碑評審時，要注意是否全面評價了項目組的進展?是否對項目組外面的相關人員展示了項目組的進展?如果里程碑評審僅有項目組內部的成員參加，則往往大事化小，小事化了，掩蓋了真實的問題，不利于發現項目組中存在的問題。
(9)預留管理緩沖
在項目過程中總會存在突發事件和估計不準確的情況，因此可以在計劃中留有緩沖時間。對于緩沖時間可以有2種設置方法，一是固定緩沖，即每周或者月等固定地留有一定緩沖時間，如半天或1天等。二是在所有的與關鍵路徑接駁的任務之前留有固定比例的緩沖，如A任務是關鍵路徑上的任務，B任務不是關鍵路徑上的任務，但是B做完后，才可以做A，B和A是直接的先后時序關系，此時可以在B任務與A任務之間留有一定的緩沖時間，以降低進度風險。
管理緩沖應可以明確地識別出來，不要隱藏在每個任務中。
