【公眾號 “專案管理研究所” 將會第一時間更新文章並[分享行業分析報告]】
歸檔於軟體專案管理初級學習路線
第五章 軟體專案任務分解
《初級學習路線合集 》
前言
大家好，這節我們學習軟體專案管理---任務分解方法。介紹類比，模板參照，自上而下，自下而上的WBS任務分解方法、
一、類比方法
有些專案有相同或相似的週期，因此而形成的相同或相似的工作細目，那麼這些專案進行任務分解的時候，可以採用類比的方法。
二、模板參照
如果某專案有可以參照的WBS模板，例如這個圖就是用專案可以參照的WBS模板，在進行任務分解時，可以採用模板參照方法進行任務分解，比較方便。
三、自上而下
自上而下是最主要最常規的任務分解方法，是從一般到特殊，從專案的大型著手，根據一定的邏輯和結構分解成子專案。
這是一個“變化計數器”系統，這個專案是比較兩個程式之間程式碼變化情況，根據需求首先分解為版本比較等六個細目這是第二層，其次是第三層。
其實任務分解的層次沒有統計的標準，可以根據對任務的工作量，任務安排來決定。例如版本比較細目再分解為三個細目，這樣可以更好的估算和分配任務，其他以此類推，直到分解到足夠清晰，詳細為止。
四、自下而上
那麼自上而下是對細目大致有把握的，需求有了解，熟悉的。
如果對專案不夠清晰，可以採用自下而上的方法。
例如下圖：從特殊到一般，從先定義特殊任務開始，那麼這些特殊任務沒有很強的邏輯關係。
例如對專案的需求不清楚，我們可以找一個白板，將想到的所有工作細目直接寫在白板上，可能很隨意，沒有邏輯關係，然後我們按照一定的邏輯關係組織起來，形成更高階別的WBS。一般情況下，自下而上的分解方法很少使用。
WBS任務分解建議
- 最低層是可控可管理的，但是不必要過細。
- 每個Work package必須有一個提交物。
- 定義任務完成的標準。
- 分解結果有利於責任分配。
- 任務分解有個規則叫做88規則，既大於8小時，小於80小時，而軟體專案比較特殊，所以我們推薦任務分解到40小時以內，敏捷專案分解到小時。
總結
總之 通過任務分解方法可以將專案分解到足夠小，方便後續的任務估算。
到這裡，第五章 第二節任務分解方法就講解完畢！下一節介紹敏捷任務分解方法~
如果您覺得這篇文章有幫助到您的的話不妨點贊支援一下喲~~?
後續將持續更新【軟體專案管理初級學習路線】的全知識點，大家感興趣的多多關注博主喲~
————————————————