项目分解结构一般采用WBSWorks   Breakdown   Structure)方法,其步骤如下:   

1.工程项目的结构分析  
项目的总任务是完成确定的技术系统(功能、质量、数量等)的工程,完成这个任务是通过许多互相联系、互相影响、互相依赖的工程活动实现的。  
2.工程项目结构分析的主要工作  
1)工程项目的结构分解。  
2)项目单元的定义。  
3)项目单元之间逻辑关系的分析  
3.项目结构分解  
对一个项目进行结构分解,通常按系统分析方法,由粗到细,由总体到具体,由上而下地将工程项目分解成树型结构。结构分解的结果有:树型结构图项目结构分析表。  
4.项目结构分解过程  
1)将项目分解成单个定义的且任务范围明确的子部分(子项目)。  
2)研究并确定每个子部分的特点和结构规则,它的执行结果以及完成它所需的活动,以作进一步的分解。  
3)将各层次结构单元(直到最低层的工作包)收集于检查表上,评价各层次的分解结果。  
4)用系统规则,将项目单元分组,构成系统结构图(包括子结构图)。  
5)分析并讲座分解的完整性,如有可能让相关部门的专家或有经验的人参加,并听取他们的意见。  
6)由决策者决定结构图,并作相应的文件。  
7)在设计和计划过程中确定各单元的(特别是工作包)说明文件内容,研究并确定系统单元之间的内部联系。  
5.项目结构分解方法  
1)以产品结构进行分解。  
2)按平面或空间位置进行分解。  
3)按功能进行分解。  
4)按要素进行分解。  
5)按项目实施过程进行分解。

WBS对软件开发项目进行任务分解,我觉得主要是从两个方向进行分解:横向分解(对问题域进行拆分)和纵向分解(对实现过程进行拆分)。  
PMPProject   Management   Professional   Study   Guide》里边采用的就是纵向优先的拆分方法。  
而清华的那本《项目管理核心教程与PMP实战》比较乱,他举的两个例子都是纯粹的纵向分解,而他附录里的案例却是纯粹的横向分解。@_@  
我比较偏向于横向优先的拆分。  
因为纵向拆分通常意味着一个线性的过程,而横向的分解通常更利于迭代开发和FDD

进行任务分割时应当注意任务之间关于知识和技术的耦合程度,以及任务内关于知识和技术的内聚程度,以减少项目内耗。  
尽量做到低耦合,以降低对成员之间交流的依赖程度,让大多数成员(需要把握全局的骨干成员除外)无需考虑太多繁杂的、不相干的东西;尽量做到高内聚,让成员可以尽量发挥他的能力以及已经获得的项目相关信息。  
这些考虑很重要,但是却常常被忽略掉。

对于划分好的任务,要仔细地分析它的难点和工作量,这些东西都是任务分配必须的约束条件。  
一定要结合技术含量、相关知识的学习难度来深入考虑,切不可以表面数据(代码行/页数/功能点数)来评估。

任务分割完毕之后,就可以开始任务分配。  
任务分配的总则是减少对交流的依赖。

对于不同的人来说,同一个任务的难度是不相同的。  
因此要调整任务分配,让合适的人做合适的工作,减少整体难度。  
分配过程中,尽量把高耦合的任务分给同一个成员,避免把过多过琐碎的无关任务分给同一个成员。  
此外,分配任务时,还应当把任务相应的知识/技术要点列表,连同其他任务资料一起提交给成员,以便成员能够提前做好准备,做到胸有成竹,以避免不必要的技术风险。

如果工作量实在太大,或是工期要求太紧,不得不把高耦合任务甚至同一任务分给多个成员负责,这时候就要特别注意成员间工作相关知识的同步、信息的交流的问题。选择几个没有结怨的人,让这几个人坐在一起工作,就能使他们方便地交流。

如果由于成员调度、个人进度、需求变更、以前遗漏的任务或者某种不可抗力等原因,而不得不更改任务分配,这时候一定要考虑如何最大化地利用项目人员已经做过的工作、已经获得的项目相关信息,尽量减少任务更改而引起的交流、培训和再教育花费。