软件项目任务分解的思考1刖H在软件工程项目进行管理的过程中，WBS（WORK BREAKDOWN STRUATURE）工作 （任务）分解结构作为项目管理的一种基本方法正在逐渐的走向成熟，因为无论 在计划阶段还是在执行阶段，WBS都是一个有用的综合工具，而且其应用也越 来越灵活广泛，目前已成为软件工程项目管理过程中一种必不可少的基本方法。WBS工作（任务）分解结构简单来说就是将工程项目的各项目内容按其相关 关系逐层进行分解，直到工作内容单一、便于组织管理的单项工作为止。合理的 分解可以把各单项的工作在整个项目中的地位、相对关系用树形结构或锯齿列表 的形式直观的表示出来。这样表示可以使项H的管理者与各参与者直观的从整体上了解工程项目中 的各项工作（任务），便于从整体上协调和管理，并使各参与者明确了解自己承担 的工作与全局的关系。WBS具有4个主要用途：1）是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和 有效地管理项目的工作。2）是一个清晰地表示各项目工作之间的相互联系的结构设计工具。3）是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计 划工具。4）定义了里程碑事件，可以向高级管理层和客户报告项FI完成情况，作为 项目状况的报告工具。通常情况下WBS总是处于软件项目计划过程的中心，是制定进度计划、了 解资源需求、统计成木预算、控制可能风险和决定采购计划等工作的重要基础。2实际分解中遇到的问题先来看一个常见的软件项目WBS,这个项H分解来源是Project软件中软 件开发项月模板，可以看到这个分解非常详尽的描述了一次软件项目开发过程中 所包含的各个部分，应当说是一个相当好的分解。但这个分解在实际应用情况下却有它的局限性。下面来详细分析：从这整个 项目分解的结构中可以看出，其分解的核心思路是按照软件开发瀑布模型思想 为基础，按开发的顺序（需求、设计、编程、测试），并在前后增加了一些必要 的相关工作。那么，这样一个建立在瀑布模型基础上的分解在实际工作中能够顺利执行么?当然可以！其前提是执行这套分解程序的软件公司拥有非常成熟的管理流程，并 在各个岗位都存在经验丰富的人员，才可能顺利按这样的计划执行。但是目前中国的软件企业大多是中小型企业，有多少能拥有完善、灵活、标 准的管理流程及各方面都完备的人才结构呢？试想，要在这样一个详尽缜密、按部就班的项目分解流程下完成整个软件开 发过程，首先，我们需要优秀的需求分析人员，如果没有，在项目开发过程中， 就需要甲方更多的积极参与，才能得到相对准确的前期需求定义，从而减少后期 的设计变更。其次，需要有优秀的开发团队，才能保质保量按时实现需求中提出的功能。 再次，还需要出色的培训人员，让客户可以顺利的接受并使用软件产品。但现在的项目能有儿个有这样理想的状态呢？在常见的开发过程中，我们经常会遇到的是甲方想法的反复无常，需求的不 断变更，随之产生计划无休止调整，有时还会遇到人员无法预期的变动，而同时 乂有难以变化的交付日期，要在前期就去比较准确的完成这种情况下的一个工作 分解，无疑难度很大。既然工作分解如此重要并且在实际中有效，那如何才能在项R的计划阶段就 做出一个完善乂可行的工作分解呢?3.1改变思考方法上面的例子中，分解基本上是按时间的先后顺序，或工作实施顺序来分解的。 但是WBS分解中并没有要求分解的工作之间需要有一定的时间关系，主要的分解的原则是：一横向到边即白分白原则，指WBS分解不能出现漏项，也不能包含不在项目范围之内的任何产品或活动;二纵向到底，指WBS分解要足够细，以 满足任务分配、检测及控制的目的。根据这两个原则，没必要一定按照时间顺序或项目实施顺序来分解项目，完 全可以按照其它的标准来分解，比如按照项R的最终交付成果来分就是一个不错 的分解方式。3.2按目标分解WBS (工作分解结构)：以可交付成果为导向对项目要素进行的分组，它归纳 和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。具体来 说，就是在总体上按目标分解，局部可以按成熟的工作流程分解。这样就让项目 管理者能够更多的从宏观的角度来把握整个项目的进展情况，而不是注重局部的 工作，最终忽略了部分细节，使项目开发成功。一般来说，需要交付的成果可能会有下面儿种：软件，相关硬件，文档，培 训，服务。建议建立可视化的项目可交付成果，以便估算工作量和分配工作。按 月标分解的好处还有，在按交付成果分解的方式下，对项目中部分工作以外包方 式组织，也提供了便捷的支持，可以很快明确外包部分的任务、目标、成果，为 最终集成提供了方便，这点在做较大项目的时候尤其明显。因为分解出来的工作 包本身就可以由惟一的一个部门或承包商负责。(用于在组织之外分包时，称为委托包(Commitment Package)o3.3其它有效可行的分解方式WBS的分解还可以采用其它多种方式进行，包括:1）按产品的物理结构分解。2）按产品或项目的功能分解。3）按照实施过程分解。4）按照项目的地域分布分解。5）按照项目的各个耳标分解。6）按部门分解。7）按职能分解。这些分解方式可按实际情况灵活运用、混合使用。3.4 WBS的实践经验最多使用20个层次，多于20层是过度的。对于一些较小的项目4-6层一 般就足够了o WBS中的支路没有必要全都分解到同一层次，即不必把结构强制做 成对称的。在任意支路，当达到一个层次时，可以作出所要求准确性的估算，就 可以停止了。一个WBS分解中的局部范围可按工作的时间顺序分解，但最好计划人与实 施者都能对这个局部工作有丰富的实践经验，或已经形成了针对这部分工作的成熟模型。分解后应达到：1）活动结构清晰;2） 逻辑上形成一个大的活动;3）集成了所有的关键因素;4）包含临时的里程碑和 监控点;5）所有活动全部定义清楚。没有计划的项Fl是一种无法控制的项目。在高技术行业，口新月异是主要特 点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。例如对于较为大型的软件开发项目的工作分解结构WBS可采用二次WBS方法。即根据总体阶段划分的总体WBS和专门针对详细设计或编码阶段的二次WBS。学会分解任务，只有将任务分解得科学、合理，才能心里有数、有条不紊 地工作，才能统筹安排好时间。统一的、标准化的WBS分解体系对解决软件工程 项目管理中存在的问题，对快速提高我们的项目管理水平具有重要意义。