WBS任务分解指南

可修编-.word.zl..word.zl.变更记录目录.目的4.任务分解定义4.任务分解的类型5清单类型5图表类型6.任务分解的过程7根本步骤8分解的标准9分解结果的检验9.任务分解的考前须知9.任务分解的意义11.word.zl..word.zl.可修编可修编-目的工程管理者经常会面临工程失控的一些问题，例如进度严重落后、资源缺乏、资金紧缺等。工程失控和超出控制围的问题，常常使工程经理处于被动。因此。采取积极的应对措施，做好方案和控制好方案是工程成功的必要条件，但不是充分条件。如果没有方案和控制是很难获得工程的成功的。任务分解定义当要解决的问题过于复杂时，可以将问题分解，直到分解后的子问题容易解决；然后分别解决这些子问题。规划工程时，也应该从任务分解开场，将一个工程分解为更多的工作细目或者子工程，使工程变得更小、更易管理、更易操作。目的是提高估算本钱、时间和资源的准确性，使工作变得更易操作，责任分工更加明确。任务分解是对需求的进一步细化，是最后确定工程所有任务围的过程。任务分解的结果是任务分解构造〔WBS〕。任务分解构造〔WBS〕是面向可交付成果的对工程元素的分组，它组织并定义了整个工程的围。不包括在WBS工作就不是该工程的工作。任务分解构造〔WBS〕是一个分级的树型构造，是对工程由粗到细的分解过程。任务分解构造每细分一个层次表示对工程元素更细致的描述。其中，任务分解构造的工作包是WBS的最低层次的可交付成果，工程完成时，应该完成这些交付成果，这些交付成果也可以分配给另外一位工程经理进展方案和执行，也可以通过子工程的方式完成，这时工作包可进一步分解为子工程的WBS或各个活动，这种工作包应当由唯一一个部门〔组织或者个人〕或承包商负责。任务分解是工程评估的前提和自下而上评估算法的根底。例如对于软件工程A进展任务分解的过程如下列图所示。

软件工程A软件工程软件工程A软件工程A一般说，进展任务分解时，可以采用清单或者图表的形式表达任务分解的结果。清单类型采用清单类型的任务分解方式，就是将任务分解的结果以清单的表述形式进展层层分解的方式。现在以一个工程为例进展说明，这个工程的名字定义为“变化计数器〞，它是统计程序大小的软件工具，当修改一个程序的时候，这个工具可以统计各个版本之间有多少代码行被增加、删除或修改。这个工程的任务分解可以按照不同的标准进展分解，采用清单方式进展任务分解如下：变化计数器比拟两个版本的程序预处理文件比拟结果处理找出修改后的程序中增加和删除的代码行找出增加的代码行找出删除的代码行统计修改后的程序中增加和删除的代码行数统计增加的代码行.word.zl..word.zl.统计删除的代码行统计总的代码行数设定标记以指示修改的次数在程序的头部增加修改记录图表类型采用图表类型的任务分解过程就是进展任务分解时采用图表的形式进展层层分解的方式。例如，对于上面的“变化计数器〞这个工程，采用图表类型的分解结果如图2所示。“变化计数器〃任务分解的过程进展任务分解应该采取一定的步骤，并且分解过程中保持唯一的分解标准。任务分解的根本过程如图2所示。图2任务分解的根本过程任务分解应该根据需求分析的结果和工程相关的要求，同时参照以往的工程分解结果进展。最终任务分解的结果是WBS。在分解过程中可以参照分解模板，进展一步一步详细的分解。虽然每个工程是唯一的，但是讨85经常能被“重复使用〃，有些工程在某种程度上是具有相似性的。例如从每个阶段看，许多工程具有一样或相似的周期和因此而形成的一样或相似的工作细目要求。许多应用领域都有标准或半标准的可以当作样板用的WBS。例如，图3中是有些软件企业进展工程分解的WBS模板，当然，本图仅作为参照例如，不代表任何特定工程的具体分解标准，而且也不是唯一的参照模板。

图3一个WBS模板根本步骤分解意味着分割主要工作细目，使它们变成更小、更易操作的要素，直到工作细目被明确详细的界定，以有助于未来工程的具体活动〔规划、评估、控制和选择〕的开展，一般说，进展任务分解的根本步骤是：确认并分解工程的主要组成要素。通常，工程的主要要素是这个工程的工作细组。工程目标作为第一级的最整体的要素。工程的组成要素应该是有形的、可证实的结果来描述，目的是为了绩效易检测。当我们知道了主要构成要素后，这些要素就应该用工程工作怎样开展，在实际中怎样完成的形式来定义。有形的、可证实的结果既包括效劳，也包括产品。确定分解标准，按照工程管理的方法分解，可以参照任何分解构造（WBS）模板进展任务分解，而且分解的时候标准要统一。分解要素是根据工程的实际管理二定义的。不同的要素有不同的分解层次。例如，工程生存期的阶段可以当作第一层次的划分，把第一层次中的工程细目在第二个阶段继续进展划分。确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任。工作细目的分解如果在很久的将来才能完成的话，那么这种分解也就没有了确定性。确定工程交付成果，交付成果是有衡量标准的，以此检查交付结果。验证分解正确性，验证分解正确后，建立一套标号系统。分解的标准进展任务分解的标准应该统一，不能有双重标准。选择一种工程分解标准之后，在分解过程中应该统一使用此标准，防止因使用不同标准而导致的混乱，导致任务的重叠。可以采用生存期为标准；或者以功能〔产品〕组成为标准；或者以工程的组织单位为标准，或者采用其他的方法。分解结果的检验任务分解后，核实分解的正确性：更低层次的细目是否必要和充分？如果不必要或者不充分，这个组成要素就必须重新修正〔增加细目、减少细目或修改细目〕。最底层要素是否有重复？如果存在重复现象就应该重新分解。每个细目都有明确的、完整的定义吗？如果不是，这种描述需修正或扩大。是否每个细目可以进展适当的估算？谁能担负起满意地完成这个工程的任务？如果没有，修正是有必要的，目的是提供一个充分的管理控制。成功完成的任务分解构造〔WBS〕是对工程总围的组织和界定。作为围阐述，这个WBS通常是用来开发或稳固一个达成共识的工程围。工程的划分每降低一个层次阐述，就要增加一个工程要素的详细描述。任务分解构造〔讨85〕可以与组织分解构造〔OBS〕综合使用，建立一个任务职责的对应关系。任务分解的考前须知进展任务分解时应注意如下事项：任务分解的规模和数量因工程而异。注意收集与工程相关的所有信息注意参看类似工程的任务分解结果，与相关人员讨论。可以参照模板进展分解。先分大块任务，然后再细分小的任务，最底层是可控的和可管理的，防止不必要的过细，最好不要超过7层。按照软件工程的平均规模来说，推荐任务分解时至少拆分到一周的工作量〔40小时〕。每个工作包至少有一个提交物。定义任务完成的标准。任务分解结果必须有利于责任分配。可以准备讨85的字典。最后与相关人员进展评审。根据情况，任务分解中可以包括诸如管理、质量等任务的分解。当然也可以在后续的活动分解的时候，分解出相应的管理、质量等活动。WBS中的每一个具体细目通常都指定唯一的代码，具体工作要素的阐述通常收集在WBS字典中。一个典型的工程分析字典，既包括了对工作包的阐述，也包括了对其他规划资料〔如进度表的日期、本钱预算和员工分配等问题〕的阐述。例如，如表1便是一个WBS字典的例子。表1WBS的字典实例WBS表示号BSM-LBL名称BSN事件日志管理系统主题目标网管的平安管理系统描述存储事件数据：记录相应事件设置事件过滤：对某些事件可设置过滤浏览事件日志：对所有事件提供浏览功能规划BSN事件日志生成历史数据：可生成历史事件报告管理BSN事件日志：可以调整BSN事件的配置参数完成的任务1，2，3已经完成责任者完成的标识通过质量保证部的验收报告备注6