公司名稱CMMI指南文檔編號:公司名稱-SPI-PP-Guid-DOCWBS任務分解指南V1.0編寫：審核：批準：日期：日期：日期：

變更記錄版本文件容描述日期編寫審核批準

目錄1. 目的 42. 任務分解定義 43. 任務分解的類型 53.1. 清單類型 53.2. 圖表類型 64. 任務分解的過程 74.1. 基本步驟 84.2. 分解的標準 94.3. 分解結果的檢驗 95. 任務分解的注意事項 106. 任務分解的意義 11目的項目管理者經常會面臨項目失控的一些問題，例如進度嚴重落后、資源不足、資金緊缺等。項目失控和超出控制圍的問題，常常使項目經理處于被動。因此。采取積極的應對措施，做好計劃和控制好計劃是項目成功的必要條件，但不是充分條件。如果沒有計劃和控制是很難獲得項目的成功的。任務分解定義當要解決的問題過于復雜時，可以將問題分解，直到分解后的子問題容易解決；然后分別解決這些子問題。規劃項目時，也應該從任務分解開始，將一個項目分解為更多的工作細目或者子項目，使項目變得更小、更易管理、更易操作。目的是提高估算成本、時間和資源的準確性，使工作變得更易操作，責任分工更加明確。任務分解是對需求的進一步細化，是最后確定項目所有任務圍的過程。任務分解的結果是任務分解結構（WBS）。任務分解結構（WBS）是面向可交付成果的對項目元素的分組，它組織并定義了整個項目的圍。不包括在WBS工作就不是該項目的工作。任務分解結構（WBS）是一個分級的樹型結構，是對項目由粗到細的分解過程。任務分解結構每細分一個層次表示對項目元素更細致的描述。其中，任務分解結構的工作包是WBS的最低層次的可交付成果，項目完成時，應該完成這些交付成果，這些交付成果也可以分配給另外一位項目經理進行計劃和執行，也可以通過子項目的方式完成，這時工作包可進一步分解為子項目的WBS或各個活動，這種工作包應當由唯一一個部門（組織或者個人）或承包商負責。任務分解是項目評估的前提和自下而上評估算法的基礎。例如對于軟件項目A進行任務分解的過程如下圖所示。軟件項目A軟件項目A功能2功能2功能1功能2功能2功能1軟件項目A軟件項目A軟件項目A軟件項目A軟件項目A軟件項目A任務分解的類型一般說，進行任務分解時，可以采用清單或者圖表的形式表達任務分解的結果。清單類型采用清單類型的任務分解方式，就是將任務分解的結果以清單的表述形式進行層層分解的方式。現在以一個項目為例進行說明，這個項目的名字定義為“變化計數器”，它是統計程序大小的軟件工具，當修改一個程序的時候，這個工具可以統計各個版本之間有多少代碼行被增加、刪除或修改。這個項目的任務分解可以按照不同的標準進行分解，采用清單方式進行任務分解如下：1.變化計數器1.1.比較兩個版本的程序1.1.1.預處理 1.1.2.文件比較1.1.3.結果處理1.2.找出修改后的程序中增加和刪除的代碼行1.2.1.找出增加的代碼行 1.2.2.找出刪除的代碼行1.3.統計修改后的程序中增加和刪除的代碼行數1.3.1.統計增加的代碼行1.3.2.統計刪除的代碼行1.4.統計總的代碼行數1.5.設定標記以指示修改的次數1.6.在程序的頭部增加修改記錄圖表類型采用圖表類型的任務分解過程就是進行任務分解時采用圖表的形式進行層層分解的方式。例如，對于上面的“變化計數器”這個項目，采用圖表類型的分解結果如圖2所示。““變化計數器”版本比較記錄修改標記修改統計總行統計增刪行找出增刪行預處理增加行數刪除代碼增加代碼結果處理文件比較刪除行數任務分解的過程進行任務分解應該采取一定的步驟，并且分解過程中保持唯一的分解標準。任務分解的基本過程如圖2所示。輸入輸入分解WBS圖2任務分解的基本過程任務分解應該根據需求分析的結果和項目相關的要求，同時參照以往的項目分解結果進行。最終任務分解的結果是WBS。在分解過程中可以參照分解模板，進行一步一步詳細的分解。雖然每個項目是唯一的，但是WBS經常能被“重復使用”，有些項目在某種程度上是具有相似性的。例如從每個階段看，許多項目具有相同或相似的周期和因此而形成的相同或相似的工作細目要求。許多應用領域都有標準或半標準的可以當作樣板用的WBS。例如，圖3中是有些軟件企業進行項目分解的WBS模板，當然，本圖僅作為參照示例，不代表任何特定項目的具體分解標準，而且也不是唯一的參照模板。軟件系統發布版本軟件系統發布版本項目規劃需求分析總體設計詳細設計實現測試項目驗收合同簽訂計劃編制計劃確認驗收測試產品提交用戶培訓集成測試系統測試測試總結缺陷跟蹤手冊編寫編碼代碼評審單元測試接口設計模塊設計單元測試計劃編制策略確定開發標準確定架構設計集成測試計劃編制需求開發需求管理系統測試計劃編制圖3一個WBS模板基本步驟分解意味著分割主要工作細目，使它們變成更小、更易操作的要素，直到工作細目被明確詳細的界定，以有助于未來項目的具體活動（規劃、評估、控制和選擇）的開展，一般說，進行任務分解的基本步驟是：確認并分解項目的主要組成要素。通常，項目的主要要素是這個項目的工作細組。項目目標作為第一級的最整體的要素。項目的組成要素應該是有形的、可證實的結果來描述，目的是為了績效易檢測。當我們知道了主要構成要素后，這些要素就應該用項目工作怎樣開展，在實際中怎樣完成的形式來定義。有形的、可證實的結果既包括服務，也包括產品。確定分解標準，按照項目管理的方法分解，可以參照任何分解結構(WBS)模板進行任務分解，而且分解的時候標準要統一。分解要素是根據項目的實際管理二定義的。不同的要素有不同的分解層次。例如，項目生存期的階段可以當作第一層次的劃分，把第一層次中的項目細目在第二個階段繼續進行劃分。確認分解是否詳細，分解結果是否可以作為費用和時間估計的標準，明確責任。工作細目的分解如果在很久的將來才能完成的話，那么這種分解也就沒有了確定性。確定項目交付成果，交付成果是有衡量標準的，以此檢查交付結果。驗證分解正確性，驗證分解正確后，建立一套標號系統。分解的標準進行任務分解的標準應該統一，不能有雙重標準。選擇一種項目分解標準之后，在分解過程中應該統一使用此標準，避免因使用不同標準而導致的混亂，導致任務的重疊。可以采用生存期為標準；或者以功能（產品）組成為標準；或者以項目的組織單位為標準，或者采用其他的方法。分解結果的檢驗任務分解后，核實分解的正確性：更低層次的細目是否必要和充分？如果不必要或者不充分，這個組成要素就必須重新修正（增加細目、減少細目或修改細目）。最底層要素是否有重復？如果存在重復現象就應該重新分解。每個細目都有明確的、完整的定義嗎？如果不是，這種描述需修正或擴充。是否每個細目可以進行適當的估算？誰能擔負起滿意地完成這個項目的任務？如果沒有，修正是有必要的，目的是提供一個充分的管理控制。成功完成的任務分解結構（WBS）是對項目總圍的組織和界定。作為圍闡述，這個WBS通常是用來開發或鞏固一個達成共識的項目圍。項目的劃分每降低一個層次闡述，就要增加一個項目要素的詳細描述。任務分解結構（WBS）可以與組織分解結構（OBS）綜合使用，建立一個任務職責的對應關系。任務分解的注意事項進行任務分解時應注意如下事項：任務分解的規模和數量因項目而異。注意收集與項目相關的所有信息注意參看類似項目的任務分解結果，與相關人員討論。可以參照模板進行分解。先分大塊任務，然后再細分小的任務，最底層是可控的和可管理的，避免不必要的過細，最好不要超過7層。按照軟件項目的平均規模來說，推薦任務分解時至少拆分到一周的工作量（40小時）。每個工作包至少有一個提交物。定義任務完成的標準。任務分解結果必須有利于責任分配。可以準備WBS的字典。最后與相關人員進行評審。根據情況，任務分解中可以包括諸如管理、質量等任務的分解。當然也可以在后續的活動分解的時候，分解出相應的管理、質量等活動。WBS中的每一個具體細目通常都指定唯一的代碼，具體工作要素的闡述通常收集在WBS字典中。一個典型的項目分析字典，既包括了對工作包的闡述，也包括了對其他規劃資料（如進度表的日期、成本預算和員工分配等問題）的闡述。例如，如表1便是一個WBS字典的例子。表1WBS的字典實例WBS表示號BSM-LBL名稱BSN事件日志管理系統主題目標網管的安全管理系統描述存儲事件數據：記錄相應事件設置事件過濾：對某些事件可設置過濾瀏覽事件日志：對所有事件提供瀏覽功能規劃BSN事件日志生成歷史數據：可生成歷史事件報告