WBS任务分解指引.docx

文档编号：公司名称-SPI-PP-GUid-DOCWBS任务分解指南编写：日期：日期：日期：CMMI指南公司名称变更记录版本文件内容描述日期编写审核批准目录1 .42 任务分解定义4工任务分解的类型5. 清单类型5. 图表类型6生任务分解的过程7. 根本步骤8. 分解的标准9分解结果的检验9d任务分解的考前须知106.任务分解的意义111.目的工程治理者经常会面临工程失控的一些问题,例如进度严重落后、资源缺乏、资金紧缺等.工程失控和超出限制范围的问题,常常使工程经理处于被动.因此.采取积极的应对举措,做好方案和限制好方案是工程成功的必要条件,但不是充分条件.如果没有方案和限制是很难获得工程的成功的.2 .任务分解定义当要解决的问题过于复杂时,可以将问题分解,直到分解后的子问题容易解决；然后分别解决这些子问题.规划工程时，也应该从任务分解开始,将一个工程分解为更多的工作细目或者子工程,使工程变得更小、更易治理、更易操作.目的是提高估算本钱、时间和资源的准确性,使工作变得更易操作，责任分工更加明确.任务分解是对需求的进一步细化,是最后确定工程所有任务范围的过程.任务分解的结果是任务分解结构(WBS).任务分解结构(WBS)是面向可交付成果的对工程元素的分组,它组织并定义了整个工程的范围.不包括在WBS工作就不是该工程的工作.任务分解结构(WBS)是一个分级的树型结构,是对工程由粗到细的分解过程.任务分解结构每细分一个层次表示对工程元素更细致的描述.其中,任务分解结构的工作包是WBS的最低层次的可交付成果,工程完成时,应该完成这些交付成果,这些交付成果也可以分配给另外一位工程经理进行方案和执行，也可以通过子工程的方式完成,这时工作包可进一步分解为子工程的WBS或各个活动,这种工作包应当由唯一一个部门组织或者个人)或承包商负责.任务分解是工程评估的前提和自下而上评估算法的根底.例如对于软件工程A进行任务分解的过程如下列图所示.3 .任务分解的类型一般说,进行任务分解时,可以采用清单或者图表的形式表达任务分解的结果.3.1. 清单类型采用清单类型的任务分解方式,就是将任务分解的结果以清单的表述形式进行层层分解的方式.现在以一个工程为例进行说明,这个工程的名字定义为“变化计数器，它是统计程序大小的软件工具,当修改一个程序的时候,这个工具可以统计各个版本之间有多少代码行被增加、删除或修改.这个工程的任务分解可以根据不同的标准进行分解,采用清单方式进行任务分解如下：1 .变化计数器.比拟两个版本的程序1.1.1. 预处理1.1.2. 文件比拟1.1.3. 结果处理.找出修改后的程序中增加和删除的代码行1.2.1. 找出增加的代码行1.2.2. 找出删除的代码行.统计修改后的程序中增加和删除的代码行数1.3.1. 统计增加的代码行1.3.2. 统计删除的代码行.统计总的代码行数.设定标记以指示修改的次数.在程序的头部增加修改记录3.2. 图表类型采用图表类型的任务分解过程就是进行任务分解时采用图表的形式进行层层分解的方式.例如,对于上面的“变化计数器这个工程,采用图表类型的分解结果如图2所示.“变化计数器"4 .任务分解的过程进行任务分解应该采取一定的步骤，并且分解过程中保持唯一的分解标准.任务分解的根本过程如图2所示.图2任务分解的根本过程任务分解应该根据需求分析的结果和工程相关的要求，同时参照以往的工程分解结果进行.最终任务分解的结果是WBS.在分解过程中可以参照分解模板,进行一步一步详细的分解.虽然每个工程是唯一的,但是WBS经常能被“重复使用，有些工程在某种程度上是具有相似性的.例如从每个阶段看,许多工程具有相同或相似的周期和因此而形成的相同或相似的工作细目要求.许多应用领域都有标准或半标准的可以当作样板用的WBS.例如，图3中是有些软件企业进行工程分解的WBS模板，当然，本图仅作为参照例如,不代表任何特定工程的具体分解标准,而且也不是唯一的参照模板.图3一个WBS模板4.1. 根本步骤分解意味着分割主要工作细目，使它们变成更小、更易操作的要素,直到工作细目被明确详细的界定，以有助于未来工程的具体活动（规划、评估、限制和选择）的开展,一般说,进行任务分解的根本步骤是：1）确认并分解工程的主要组成要素.通常,工程的主要要素是这个工程的工作细组.工程目标作为第一级的最整体的要素.工程的组成要素应该是有形的、可证实的结果来描述，目的是为了绩效易检测.当我们知道了主要构成要素后,这些要素就应该用工程工作怎样开展,在实际中怎样完成的形式来定义.有形的、可证实的结果既包括效劳,也包括产品.(2)确定分解标准,根据工程治理的方法分解,可以参照任何分解结构(WBS)模板进行任务分解,而且分解的时候标准要统一.分解要素是根据工程的实际管理二定义的.不同的要素有不同的分解层次.例如,工程生存期的阶段可以当作第一层次的划分,把第一层次中的工程细目在第二个阶段继续进行划分.(3)确认分解是否详细,分解结果是否可以作为费用和时间估计的标准，明确责任.工作细目的分解如果在很久的将来才能完成的话,那么这种分解也就没有了确定性.(4)确定工程交付成果,交付成果是有衡量标准的，以此检查交付结果.(5)验证分解正确性,验证分解正确后,建立一套标号系统.4.2. 分解的标准进行任务分解的标准应该统一,不能有双重标准.选择一种工程分解标准之后，在分解过程中应该统一使用此标准,防止因使用不同标准而导致的混乱,导致任务的重叠.可以采用生存期为标准；或者以功能(产品)组成为标准；或者以工程的组织单位为标准,或者采用其他的方法.4.3. 分解结果的检验任务分解后,核实分解的正确性：更低层次的细目是否必要和充分如果不必要或者不充分，这个组成要素就必须重新修正(增加细目、减少细目或修改细目).最底层要素是否有重复如果存在重复现象就应该重新分解.每个细目都有明确的、完整的定义吗如果不是,这种描述需修正或扩充.是否每个细目可以进行适当的估算谁能担负起满意地完成这个工程的任务如果没有,修正是有必要的，目的是提供一个充分的治理限制.成功完成的任务分解结构(WBS)是对工程总范围的组织和界定.作为范围阐述,这个WBS通常是用来开发或稳固一个达成共识的工程范围.工程的划分每降低一个层次阐述,就要增加一个工程要素的详细描述.任务分解结构(WBS)可以与组织分解结构(OBS)综合使用，建立一个任务责任的对应关系.5 .任务分解的考前须知进行任务分解时应注意如下事项：任务分解的规模和数量因工程而异.注意收集与工程相关的所有信息注意参看类似工程的任务分解结果,与相关人员讨论.可以参照模板进行分解.先分大块任务，然后再细分小的任务，最底层是可控的和可治理的，防止不必要的过细,最好不要超过7层.根据软件工程的平均规模来说,推荐任务分解时至少拆分到一周的工作量（40小时）.每个工作包至少有一个提交物.定义任务完成的标准.任务分解结果必须有利于责任分配.可以准备WBS的字典.最后与相关人员进行评审.根据情况,任务分解中可以包括诸如治理、质量等任务的分解.当然也可以在后续的活动分解的时候,分解出相应的治理、质量等活动.WBS中的每一个具体细目通常都指定唯一的代码,具体工作要素的阐述通常收集在WBS字典中.一个典型的工程分析字典,既包括了对工作包的阐述,也包括了对其他规划资料如进度表的日期、本钱预算和员工分配等问题）的阐述.例如,如表1便是一个WBS字典的例子.表1WBS的字典实例WBS表示号BSM-1.B1.名称BSN事件日志治理系统主题目标网管的平安治理系统描述D存储事件数据：记录相应事件2）设置事件过滤：对某些事件可设置过滤3）浏览事件日志：对所有事件提供浏览功能4）规划BSN事件日志5）生成历史数据：可生成历史事件报告6）治理BSN事件日志：可以调整BSN事件的配置参数完成的任务1,2,3已经完成责任者完成的标识通过质量保证部的验收报告备注6 .任务分解的意义任务分解结构（WBS）提供了工程范围基线,是范围变更的重要输入,而且有了任务分解,工程经理可以集中注意力到工程的目标上,不必为细枝末节伤脑筋.同时,任务分解结构给开发工程提供了一个实施框架,其中明确了责任,为评估和分配任务提供具体的工作包,是进行估算和编制工程进度的根底,对整个工程成功的集成和限制起到非常重要的作用.