成功進行軟體項目策劃的九個基本要點

來源:互聯網
上載者:User
古人云“萬事預則立,不預則廢”,項目要成功必須做好計劃。軟體項目策劃是專案管理過程中最基本的一個過程,軟體項目策劃的方法是軟體專案經理必須掌握的。在實際的項目策划過程中,必須掌握以下的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任務之間留有一定的緩衝時間,以降低進度風險。

  管理緩衝應可以明確地識別出來,不要隱藏在每個任務中。

  相信上述的9個要點一定能夠給您的項目策劃實踐帶來協助!

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.