WBS的概念、分解策略、作用、分解原则和方法

1.引言
渐进明细是项目的特点，但这并不意味着不需要计划。没有计划或者是随意的不负责任的计划的项目是一种无法控制的项目。在软件高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。例如对于较为大型的软件开发项目的工作分解结构WBS可采用二次WBS方法，即根据总体阶段划分的总体WBS和专门针对系统设计或编码阶段的二次WBS。这其中部分的原因是需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计误差范围也是比较大的。更为重要的原因是，需求往往不是编码工作分解的准确依据，因为一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，因此只有在需求分析完成以后才能准确地得到系统设计或编码阶段的二次WBS，根据代码模块的合理划分而得出的二次WBS才能在系统设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。

2.基本概念
WorkBreakdownStructure（WBS）工作分解结构：对应当由项目团队执行以便实现项目目标，并创造必要的可交付成果工作，按可交付成果所做的层次分解。WBS将项目的整个范围组织在一起并加以明确。每向下分解一个层次，就意味着项目工作的定义深入了一步。WBS最终分解为工作细目。WBS的层次结构以可交付成果为对象，包括内部和外部可交付成果。（ 2004年版PMBOK指南） WorkPackage（工作细目，也翻译为工作任务包），工作细目包括为完成该工作细目可交付成果或项目工作组成部分而必需的计划活动和进度里程碑。（2004年版PMBOK指南）
Control A cｃｏｕｎｔ（控制账目，CA），是综合范围、预算、实际费用和进度，并对绩效进行测量的管理控制点，控制账目设置在工作分解结构（在选定水平上的具体组成部分）的事先选定的管理点上。每一个控制账目都可以包含一个或多个的工作细目，但是每一个工作细目只可以在同一个控制账目相联系。（2004年版PMBOK指南）

3.对WBS的理解
从以上解释，我们得出如下结论，WBS是将项目加以定义，明确项目工作任务的。由此可见，WBS在项目管理的重要地位，所以“没有WBS，就没有项目管理”。对于WBS定义的理解，我个人认为应在以下两方面重点加以理解：
第一方面，就是WBS的单元，即WBS层次结构的对象，它是以“Deliverables（可交付成果）”为分解导向，而不是以“ScheduleActivity（计划活动）”为分解导向。 WBS的最底层次为WorkPackage（工作细目），工作细目包括为完成该工作细目可交付成果或项目工作组成部分而必需的计划活动和进度里程碑。为什么WBS的最底层次不是ScheduleActivity（计划活动）而是WorkPackage（工作细目）呢？
首先WBS是作为项目范围管理的工具、技术，项目范围管理关注点是项目的组成部分，它面向的是可交付成果，而不是过程。
其次WBS定义的是项目及其组成部分，是ScheduleActivity（计划活动）定义的依据，而不是去定义ScheduleActivity（计划活动）；
第三ScheduleActivity（计划活动）是项目进度表的单个组成部分，不是WBS的组成部分。对于这一点，很多人理解上可能有困难。因为，习惯说法是活动是由各项具体工作构成的，而上面的定义我们从字面上看的习惯说法与PMBOK的定义正好相反，但是从本质上去理解两者应该是相同的，只是说法不同。因为在项目管理尚未引进中国以前，我们把活动等同于项目。
第二方面，就