轉自：
http://www.javaeye.com/topic/5746說到任務分解，肯定就得說說WBS了。下邊是摘自網上的一段對WBS的介紹：
項目分解結構一般采用WBS（Works Breakdown Structure）方法，其步驟如下：
1．工程項目的結構分析
項目的總任務是完成確定的技術系統（功能、質量、數量等）的工程，完成這個任務是通過許多互相聯系、互相影響、互相依賴的工程活動實現的。
2．工程項目結構分析的主要工作
（1）工程項目的結構分解。
（2）項目單元的定義。
（3）項目單元之間邏輯關系的分析
3．項目結構分解
對一個項目進行結構分解，通常按系統分析方法，由粗到細，由總體到具體，由上而下地將工程項目分解成樹型結構。結構分解的結果有：①樹型結構圖②項目結構分析表。
4．項目結構分解過程
（1）將項目分解成單個定義的且任務范圍明確的子部分（子項目）。
（2）研究并確定每個子部分的特點和結構規則，它的執行結果以及完成它所需的活動，以作進一步的分解。
（3）將各層次結構單元（直到最低層的工作包）收集于檢查表上，評價各層次的分解結果。
（4）用系統規則，將項目單元分組，構成系統結構圖（包括子結構圖）。
（5）分析并講座分解的完整性，如有可能讓相關部門的專家或有經驗的人參加，并聽取他們的意見。
（6）由決策者決定結構圖，并作相應的文件。
（7）在設計和計劃過程中確定各單元的（特別是工作包）說明文件內容，研究并確定系統單元之間的內部聯系。
5．項目結構分解方法
（1）以產品結構進行分解。
（2）按平面或空間位置進行分解。
（3）按功能進行分解。
（4）按要素進行分解。
（5）按項目實施過程進行分解。 用WBS對軟件開發項目進行任務分解，我覺得主要是從兩個方向進行分解：橫向分解（對問題域進行拆分）和縱向分解（對實現過程進行拆分）。
《PMP：Project Management Professional Study Guide》里邊采用的就是縱向優先的拆分方法。
而清華的那本《項目管理核心教程與PMP實戰》比較亂，他舉的兩個例子都是純粹的縱向分解，而他附錄里的案例卻是純粹的橫向分解。@_@
我比較偏向于橫向優先的拆分。
因為縱向拆分通常意味著一個線性的過程，而橫向的分解通常更利于迭代開發和FDD。
進行任務分割時應當注意任務之間關于知識和技術的耦合程度，以及任務內關于知識和技術的內聚程度，以減少項目內耗。
盡量做到低耦合，以降低對成員之間交流的依賴程度，讓大多數成員（需要把握全局的骨干成員除外）無需考慮太多繁雜的、不相干的東西；盡量做到高內聚，讓成員可以盡量發揮他的能力以及已經獲得的項目相關信息。
這些考慮很重要，但是卻常常被忽略掉。
對于劃分好的任務，要仔細地分析它的難點和工作量，這些東西都是任務分配必須的約束條件。
一定要結合技術含量、相關知識的學習難度來深入考慮，切不可以表面數據（代碼行/頁數/功能點數）來評估。
任務分割完畢之后，就可以開始任務分配。
任務分配的總則是
減少對交流的依賴。
對于不同的人來說，同一個任務的難度是不相同的。
因此要調整任務分配，讓合適的人做合適的工作，減少整體難度。
分配過程中，盡量把高耦合的任務分給同一個成員，避免把過多過瑣碎的無關任務分給同一個成員。
此外，分配任務時，還應當把任務相應的知識/技術要點列表，連同其他任務資料一起提交給成員，以便成員能夠提前做好準備，做到胸有成竹，以避免不必要的技術風險。
如果工作量實在太大，或是工期要求太緊，不得不把高耦合任務甚至同一任務分給多個成員負責，這時候就要特別注意成員間工作相關知識的同步、信息的交流的問題。選擇幾個沒有結怨的人，讓這幾個人坐在一起工作，就能使他們方便地交流。
如果由于成員調度、個人進度、需求變更、以前遺漏的任務或者某種不可抗力等原因，而不得不更改任務分配，這時候一定要考慮如何最大化地利用項目人員已經做過的工作、已經獲得的項目相關信息，盡量減少任務更改而引起的交流、培訓和再教育花費。