转自：
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。
进行任务分割时应当注意任务之间关于知识和技术的耦合程度，以及任务内关于知识和技术的内聚程度，以减少项目内耗。
尽量做到低耦合，以降低对成员之间交流的依赖程度，让大多数成员（需要把握全局的骨干成员除外）无需考虑太多繁杂的、不相干的东西；尽量做到高内聚，让成员可以尽量发挥他的能力以及已经获得的项目相关信息。
这些考虑很重要，但是却常常被忽略掉。
对于划分好的任务，要仔细地分析它的难点和工作量，这些东西都是任务分配必须的约束条件。
一定要结合技术含量、相关知识的学习难度来深入考虑，切不可以表面数据（代码行/页数/功能点数）来评估。
任务分割完毕之后，就可以开始任务分配。
任务分配的总则是
减少对交流的依赖。
对于不同的人来说，同一个任务的难度是不相同的。
因此要调整任务分配，让合适的人做合适的工作，减少整体难度。
分配过程中，尽量把高耦合的任务分给同一个成员，避免把过多过琐碎的无关任务分给同一个成员。
此外，分配任务时，还应当把任务相应的知识/技术要点列表，连同其他任务资料一起提交给成员，以便成员能够提前做好准备，做到胸有成竹，以避免不必要的技术风险。
如果工作量实在太大，或是工期要求太紧，不得不把高耦合任务甚至同一任务分给多个成员负责，这时候就要特别注意成员间工作相关知识的同步、信息的交流的问题。选择几个没有结怨的人，让这几个人坐在一起工作，就能使他们方便地交流。
如果由于成员调度、个人进度、需求变更、以前遗漏的任务或者某种不可抗力等原因，而不得不更改任务分配，这时候一定要考虑如何最大化地利用项目人员已经做过的工作、已经获得的项目相关信息，尽量减少任务更改而引起的交流、培训和再教育花费。