该帖子同步发自：(铁托的博客  访问该博客)

　　1 前言

　　在软件工程项目进行管理的过程中， WBS(WORK BREAKDOWN STRUATURE)工作(任务)分解结构作为项目管理的一种基本方法正在逐渐的走向成熟， 因为无论在计划阶段还是在执行阶段，WBS 都是一个有用的综合工具， 而且其应用也越来越灵活广泛，目前已成为软件工程项目管理过程中一种必不可少的基本方法。

　　WBS 工作(任务)分解结构简单来说就是将工程项目的各项目内容按其相关关系逐层进行分解，直到工作内容单一、便于组织管理的单项工作为止。合理的分解可以把各单项的工作在整个项目中的地位、相对关系用树形结构或锯齿列表的形式直观的表示出来。

　　这样表示可以使项目的管理者与各参与者直观的从整体上了解工程项目中的各项工作(任务)，便于从整体上协调和管理，并使各参与者明确了解自己承担的工作与全局的关系。

　　WBS 具有4 个主要用途：

　　1) 是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。

　　2) 是一个清晰地表示各项目工作之间的相互联系的结构设计工具。

　　3) 是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。

　　4) 定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。

　　通常情况下WBS 总是处于软件项目计划过程的中心，是制定进度计划、了解资源需求、统计成本预算、控制可能风险和决定采购计划等工作的重要基础。

　　2 实际分解中遇到的问题

　　先来看一个常见的软件项目WBS， 这个项目分解来源是Project软件中软件开发项目模板，可以看到这个分解非常详尽的描述了一次软件项目开发过程中所包含的各个部分， 应当说是一个相当好的分解。

　　但这个分解在实际应用情况下却有它的局限性。下面来详细分析：从这整个项目分解的结构中可以看出， 其分解的核心思路是按照软件开发瀑布模型思想为基础，按开发的顺序( 需求、设计、编程、测试)，并在前后增加了一些必要的相关工作。

　　那么，这样一个建立在瀑布模型基础上的分解在实际工作中能够顺利执行么? 当然可以! 其前提是执行这套分解程序的软件公司拥有非常成熟的管理流程，并在各个岗位都存在经验丰富的人员，才可能顺利按这样的计划执行。

　　但是目前中国的软件企业大多是中小型企业，有多少能拥有完善、灵活、标准的管理流程及各方面都完备的人才结构呢?

　　试想，要在这样一个详尽缜密、按部就班的项目分解流程下完成整个软件开发过程，首先，我们需要优秀的需求分析人员，如果没有，在项目开发过程中，就需要甲方更多的积极参与，才能得到相对准确的前期需求定义，从而减少后期的设计变更。

　　其次，需要有优秀的开发团队，才能保质保量按时实现需求中提出的功能。再次，还需要出色的培训人员，让客户可以顺利的接受并使用软件产品。但现在的项目能有几个有这样理想的状态呢?

　　在常见的开发过程中，我们经常会遇到的是甲方想法的反复无常，需求的不断变更，随之产生计划无休止调整，有时还会遇到人员无法预期的变动，而同时又有难以变化的交付日期，要在前期就去比较准确的完成这种情况下的一个工作分解，无疑难度很大。

　　3 解决方法

　　既然工作分解如此重要并且在实际中有效，那如何才能在项目的计划阶段就做出一个完善又可行的工作分解呢?

　　3.1 改变思考方法

　　上面的例子中，分解基本上是按时间的先后顺序，或工作实施顺序来分解的。但是WBS 分解中并没有要求分解的工作之间需要有一定的时间关系，主要的分解的原则是：一横向到边即百分百原则，指WBS 分解不能出现漏项，也不能包含不在项目范围之内的任何产品或活动;二纵向到底，指WBS 分解要足够细，以满足任务分配、检测及控制的目的。

　　根据这两个原则，没必要一定按照时间顺序或项目实施顺序来分解项目，完全可以按照其他的标准来分解，比如按照项目的最终交付成果来分就是一个不错的分解方式。

　　3.2 按目标分解

　　WBS (工作分解结构)：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。具体来说，就是在总体上按目标分解，局部可以按成熟的工作流程分解。这样就让项目管理者能够更多的从宏观的角度来把握整个项目的进展情况，而不是注重局部的工作，最终忽略了部分细节，使项目开发成功。

　　一般来说，需要交付的成果可能会有下面几种：软件，相关硬件，文档，培训，服务。建议建立可视化的项目可交付成果，以便估算工作量和分配工作。按目标分解的好处还有，在按交付成果分解的方式下，对项目中部分工作以外包方式组织，也提供了便捷的支持，可以很快明确外包部分的任务、目标、成果，为最终集成提供了方便，这点在做较大项目的时候尤其明显。因为分解出来的工作包本身就可以由惟一的一个部门或承包商负责。(用于在组织之外分包时，称为委托包 (Commitment Package))。

　　3.3 其他有效可行的分解方式

　　WBS 的分解还可以采用其他多种方式进行，包括：

　　1) 按产品的物理结构分解。

　　2) 按产品或项目的功能分解。

　　3) 按照实施过程分解。

　　4) 按照项目的地域分布分解。

　　5) 按照项目的各个目标分解。

　　6) 按部门分解。

　　7) 按职能分解。

　　这些分解方式可按实际情况灵活运用、混合使用。

　　3.4 WBS 的实践经验

　　最多使用20 个层次，多于20 层是过度的。对于一些较小的项目4-6 层一般就足够了。WBS 中的支路没有必要全都分解到同一层次，即不必把结构强制做成对称的。在任意支路，当达到一个层次时，可以作出所要求准确性的估算，就可以停止了。

　　一个WBS 分解中的局部范围可按工作的时间顺序分解，但最好计划人与实施者都能对这个局部工作有丰富的实践经验，或已经形成了针对这部分工作的成熟模型。分解后应达到：1) 活动结构清晰;2) 逻辑上形成一个大的活动;3) 集成了所有的关键因素;4) 包含临时的里程碑和监控点;5)所有活动全部定义清楚。

　　4 结束语

　　没有计划的项目是一种无法控制的项目。在高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。例如对于较为大型的软件开发项目的工作分解结构WBS 可采用二次WBS 方法。

　　即根据总体阶段划分的总体WBS 和专门针对详细设计或编码阶段的二次WBS。学会分解任务，只有将任务分解得科学、合理，才能心里有数、有条不紊地工作，才能统筹安排好时间。统一的、标准化的WBS分解体系对解决软件工程项目管理中存在的问题，对快速提高我们的项目管理水平具有重要意义。