2.2 采用生命周期创建WBS
在项目的实施过程中，可以采用不同的项目生命周期。项目生命周期指的是项目从启动到结束所经历的一系列阶段，它为项目管理提供了一个基本框架。不论项目涉及的具体工作是什么，这个基本框架都适用。这些阶段可以是顺序的、迭代的或交叠的。所有项目都可以映射到如图2-1所示的通用生命周期。
图2-1 《PMBOK®指南》所述的关键组件在项目中的相互关系
项目管理团队要确定各个项目最适合的生命周期。项目生命周期需要具有足够的灵活性，以应对项目中包含的各种因素。可以通过以下方法实现生命周期的灵活性：
◆ 识别需要在各个阶段实施的过程。
◆ 在合适的阶段实施已识别的过程。
◆ 调整阶段的各种属性（如名称、持续时间、退出标准和准入标准）。
WBS有助于项目经理、项目领导者、相关方和参与者对项目产生的最终产品、可交付成果或输出（输出可以是产品、服务或结果）建立清晰的愿景。更准确地说，WBS为项目提供了包括交付产品、服务或结果所涉及工作的清晰愿景。
WBS的创建因每个项目所选择的生命周期而异，而项目和子项目集组成了项目集WBS。
项目生命周期可以是预测型的、迭代型的、增量型的或敏捷型的：
◆ 在预测型生命周期中，在生命周期的早期阶段确定项目范围、时间和成本。对任何范围的变更都要进行仔细的管理。预测型生命周期也可能指的是瀑布型生命周期。
◆ 在迭代型生命周期中，项目范围通常在项目生命周期的早期被确定，但时间及成本估算将随着项目团队对产品理解的不断深入（滚动规划）而定期修改。迭代通过一系列重复的循环活动来开发产品。
◆ 在增量型生命周期中，通过在一定时间内的一系列迭代，渐进地增加产品的功能以产出可交付成果。只有在最后一次迭代后，可交付成果具有了必要的和足够的能力，它才能被视为完成。
◆ 在敏捷型生命周期中，通过一系列的迭代来交付所需的功能。这些迭代的持续时间很短，通常持续1～4周。迭代通过一系列重复的循环活动来开发产品。
混合型生命周期是预测型生命周期和敏捷型生命周期的组合。那些已知的或有确定需求的项目可遵循预测型开发生命周期，而那些仍在发展变化的项目可遵循敏捷型生命周期，这更易于适应范围的蔓延和变更。
在所有的项目生命周期中，WBS包括由项目领导者、相关方、内部和外部参与者（如团队成员和分包商）要完成的所有工作。WBS对要执行的工作的目标和可交付成果提供了清晰的陈述。项目团队使用WBS与相关方进行沟通。
不同的项目生命周期具有以下特点，如《敏捷实践指南》中的表3-1所示：
WBS层次的深度取决于项目的规模、复杂性及计划和管理它所需的详细程度。WBS由执行组织要完成的整个范围的多级层次结构组成。但是，具体的层次数量应便于有效地管理、执行和监控项目。
2.2.1 在预测型（瀑布型）生命周期中使用WBS
在具有较高的确定性、稳定的需求和低风险的情况下，可以采用预测型生命周期。因此，在预测型生命周期中，项目活动通常按顺序执行。当采用预测型生命周期时，团队需要详细的计划来知道要交付什么及如何交付。在项目的开始阶段，团队创建详细的需求、范围说明书、WBS、WBS词典和计划。通常，团队直到项目结束才交付商业价值（见图2-2）。
图2-2 预测型生命周期
在预测型生命周期中，项目范围、时间和成本在生命周期的早期阶段被确定。通过正式的变更管理流程来对范围的任何变更进行仔细的管理。预测型生命周期也被称为瀑布型生命周期。
典型的预测型生命周期WBS遵循以下惯用做法：
◆ 项目名称出现在WBS的第一层次。
◆ 项目阶段或主要项目可交付成果通常出现在第二层次。
◆ 第三层次和其他下级层次（取决于第二层次）可以用来表示可交付成果、控制账户或工作包。
◆ 根据项目的规模和复杂性，WBS分解可以继续进行。
◆ WBS组件的最低层次被称为工作包。
图2-3展示了基于阶段WBS的常用做法。
图2-3 预测型生命周期WBS示例，其中项目阶段位于WBS的第二层次
图2-4展示了基于可交付成果WBS的常用做法。
图2-4 预测型生命周期WBS示例，其中主要可交付成果位于WBS的第二层次
随着项目范围的逐步细化，迭代地演化WBS，直到整个项目的范围已经被基准化。
在预测型生命周期中，项目的范围基准是经过批准的项目范围说明书、WBS和相应的WBS词典。基准仅通过正式的变更控制程序进行变更，并在项目实施期间作为比较的基础，如图2-5所示。
图2-5 甘特图样式的预测型生命周期示例
2.2.2 在迭代型生命周期中使用WBS
在迭代型生命周期中，通过连续的原型法或概念证明来改进产品或结果。每个新的原型都能带来新的（或额外的）相关方反馈和团队见解。在下一个周期中，团队集成这些新的信息，并通过重复一个或多个项目活动来重新构建原型。
当项目的复杂性高、变更频繁，或者项目范围受到相关方的不同观点、技术进步或期望的最终产品的支配时，采用迭代型生命周期更有优势。当采用迭代型生命周期时，可能需要更长的时间，因为它是为学习而优化的，而不是为交付速度而优化的。在迭代型生命周期中，通常直到项目结束都不会交付实质性的商业价值。在某些情况下，采用迭代型生命周期可提高进入下一个里程碑或为下一阶段获得关键批准的可能性。
在迭代型生命周期中，项目范围通常在项目生命周期的早期确定，但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。迭代方法通过一系列重复的循环活动来开发产品，而增量方法通过渐进地增加产品功能来开发产品，如图2-6所示。
图2-6 迭代型生命周期示例
在迭代型生命周期中，WBS的表示通常遵循以下惯用做法：
◆ 项目名称出现在WBS的第一层次。
◆ 第二层次表示项目阶段（迭代）。重复项目的多个初始阶段（迭代），直到相关方对分解达成一致。此外，项目的后期阶段（迭代）会重复进行，直到项目交付最终的输出。
◆ 第三层次和其他下级层次可以用来表示可交付成果或工作包。
◆ 根据项目的规模和复杂性，WBS分解可以继续进行。
◆ WBS组件的最低层次被称为工作包。
图2-7展示了基于阶段WBS的惯用做法。
图2-7 迭代型生命周期WBS示例，其中迭代位于WBS的第二层次
随着项目范围的逐步细化，WBS迭代地演化，直到范围中的每次迭代分别被基准化。
在迭代型生命周期中，项目的范围基准是经过批准的项目范围说明书、WBS和相应的在项目生命周期中详细阐述的WBS词典。基准仅通过正式的变更控制程序进行变更，并在项目实施期间作为比较的基础，如图2-8所示。
图2-8 甘特图样式的迭代型生命周期示例
2.2.3 在增量型生命周期中使用WBS
有些项目会对交付速度进行优化。许多企业和项目无法等待所有的事情全部完成，在这种情况下，客户愿意接受整个解决方案的一个部分。这种对少量可交付成果的频繁交付被称为增量型生命周期。
在增量型生命周期中，可交付成果是通过一系列迭代产生的，这些迭代在预定的时间框架内连续地添加功能。只有在最后一次迭代后，可交付成果具有了必要的和足够的能力及价值，它才能被视为完成，如图2-9所示。
图2-9 增量规模变化的生命周期
与一次交付一个最终产品相比，在增量型生命周期中，将更频繁地优化工作，以为项目发起人、相关方或客户交付价值。只有在最后阶段（迭代）完成后，项目的最终产品才被认为是完成的。
在增量型生命周期中，WBS的表示通常遵循以下惯用做法：
◆ 项目名称、产品名称或方案名称出现在WBS的第一层次。
◆ 项目阶段（也被称为迭代）出现在WBS的第二层次。在每个阶段（迭代），都将分析、设计、构建、测试，并向客户交付价值。
◆ 第三层次和其他下级层次可以用来表示可交付成果和/或工作包。
◆ 根据项目的规模和复杂性，WBS分解可以继续进行。
◆ WBS组件的最低层次被称为工作包。
图2-10展示了基于阶段WBS的惯用做法。
图2-10 增量型生命周期WBS示例，其中迭代位于WBS的第二层次
随着项目范围的逐步细化（通过滚动规划），WBS迭代地演化，直到范围中的每个阶段（迭代）分别被基准化。
在增量型生命周期中，项目的范围基准是经过批准的项目范围说明书、WBS和相应的特定迭代的WBS词典。基准仅通过正式的变更控制程序进行变更，并在项目实施期间作为比较的基础，如图2-11所示。
图2-11 甘特图样式的增量型生命周期示例
2.2.4 在敏捷型生命周期中使用WBS
对于需求不断变化或不确定性高的项目，在项目开始时通常无法完全明确项目的范围，而需要在项目期间逐渐明确。敏捷实践特意在项目的早期阶段缩短定义和协商范围的时间，同时花费更多的时间来建立用于不断探索和完善的过程。在多数情况下，不断涌现的需求往往导致期望的商业需求与最初描述的商业需求间存在差异。
敏捷实践有目的地构建并评审原型和发布版本以细化和完善需求。因此，范围在整个项目中被定义和重新定义。在敏捷方法中，产品待办事项列表构成了已知的需求。敏捷方法中的需求代表了史诗、特性或用户故事。
产品负责人在团队、相关方和商业分析专业人士的帮助下，创建产品待办事项列表。产品代办事项列表帮助团队了解如何在不产生浪费的情况下交付最高价值。
在敏捷型生命周期中，项目发起人和客户代表会定期参与项目，在创建可交付成果时提供反馈，并确保产品待办事项列表能反映当前的需求。
WBS通常与预测型生命周期相关联，并支持对项目的整个范围进行分解。当采用敏捷实践时，要将整个范围分解为更小的部分，从而支持待办事项列表或产品待办事项列表。
在敏捷型生命周期中，WBS包含商业价值项，这通常被称为需求、待办事项列表或用户故事。每个需求、待办事项列表项或用户故事都代表了交付该项所描述的用户功能所需的工作。每个需求、待办事项列表项或用户故事都交付了一个功能的小增量、输出或可交付成果。工作包代表了WBS中分解的最低层次。用户故事是敏捷项目中分解的最低层次。工作包和用户故事都向客户交付功能。工作包和用户故事都是关于做什么而不是如何做的。工作包大致等于用户故事。
对于在敏捷环境中执行的项目，团队期望需求会发生改变。迭代和增量方法能够提供反馈，以更好地规划项目的下一部分。图2-12显示了实现增量交付的两种可能的方法（基于迭代的敏捷方法和基于流程的敏捷方法），这都有助于敏捷项目与客户的需求保持一致，并可以根据需要进行调整。
图2-12 基于迭代的和基于流程的敏捷型生命周期
在基于迭代的敏捷方法中，团队通过迭代（使用Scrum框架时的冲刺，它具有相同持续时间的时间盒）来交付完整的特性。在使用迭代的敏捷型生命周期中，有一个关于用户故事（工作包）规模的目标：用户故事应该在单次迭代（冲刺）中交付。如果用户故事不能在单次迭代（冲刺）中交付，则将用户故事拆分为更小的用户故事。
在基于流程的敏捷方法中，团队将根据自身的能力，从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。
下面是一些分解敏捷项目的不同方法，但不限于此：
◆ 产品、迭代、用户故事。
◆ 产品、发布、迭代、用户故事。
◆ 产品、发布、特性、迭代、用户故事。
◆ 产品、特性、发布、迭代、用户故事。
◆ 产品、史诗、特性、迭代、用户故事。
◆ 产品、特性、史诗、迭代、用户故事。
对于敏捷项目，存在各种各样的WBS场景。
第一种场景如图2-13所示。
图2-13 敏捷型生命周期WBS示例，其中迭代位于WBS的第二层次
◆ 项目名称或产品名称出现在WBS的第一层次。
◆ 迭代（冲刺）出现在WBS的第二层次（如1.1、1.2、1.3、1.4、1.5等）。
◆ 用户故事出现在WBS的第三层次。敏捷项目中的用户故事是分解的最低层次，具有与工作包相似的特征。用户故事和工作包都可产生一个或多个可交付成果或功能。
第二种场景如图2-14所示。
图2-14 敏捷型生命周期WBS示例，其中发布位于WBS的第二层次
◆ 项目名称或产品名称出现在WBS的第一层次。
◆ 发布出现在WBS的第二层次（如发布1、发布2、发布3等）。
◆ 迭代（冲刺）出现在WBS的第三层次（如1.1.x、1.2.x、1.3.x、1.4.x、1.5.x等）。
◆ 用户故事（工作包）出现在WBS的第四层次。
还有其他发布、特性和迭代的组合。在敏捷型生命周期的项目中，WBS随着需求的更新而更新，这意味着WBS的基准不会在项目的开始时出现。WBS的最终版本只有在项目完成时才知道，如图2-15所示。
图2-15 甘特图样式的基于迭代的敏捷型生命周期示例
2.2.5 关键概念/特征
以下术语和定义（按字母顺序排列）是在《PMI项目管理术语词典》、《PMBOK®指南》和《敏捷实践指南》中定义的与WBS相关的术语。这些术语和本实践标准的术语表中列出的其他术语都有助于理解WBS在项目管理实践中所起的整体作用。
◆ 活动（Activity）。在进度计划中所列，并在项目过程中实施的工作组成部分。
◆ 控制账户（Control Account）。一种管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值比较，以测量绩效。
◆ 可交付成果（Deliverable）。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力。
◆ 独立型活动（Discrete Effort）。能够予以规划并测量，且会产出特定输出的活动。（注：独立型活动是用于计算工作绩效的三种挣值管理活动之一。）
◆ 支持型活动（Level of Effort）。一种不产生明确的最终产品，而按时间流逝来度量的活动。（注：支持型活动是用于计算工作绩效的三种挣值管理活动之一。）
◆ 规划包（Planning Package）。控制账户可以包括一个或多个规划包。规划包是一个工作内容已知但详细进度活动未知的，低于控制账户的WBS组件。
◆ 范围（Scope）。项目所提供的产品、服务和成果的总和。
◆ 范围基准（Scope Baseline）。经过批准的范围说明书、WBS和相应的WBS词典，能够通过正式的变更控制程序进行变更，并被用作与实际成果进行比较的依据。
◆ 工作分解结构组件（Work Breakdown Structure Component）。工作分解结构任意层次上的任何要素。
◆ 工作分解结构元素（Work Breakdown Structure Element）。包含在单个工作分解结构中的任何单个工作分解结构组件及其关联的WBS属性。
◆ WBS词典（WBS Dictionary）。针对WBS中的每个元素，详细描述可交付成果、活动和进度信息的文件。
◆ 工作包（Work Package）。WBS最低层次的工作，针对这些工作来估算并管理成本和持续时间。
在实践中有多种类型的WBS分解。不同的来源将WBS标识为行动导向型、代办事项导向型、合同导向型、可交付成果导向型、阶段导向型、产品导向型、项目集导向型，甚至是一种组合，从而产生了一种混合方法。虽然在分解的类型中没有特别提到，但是一种新兴的类型是位置导向型。
只采用一种分解类型的WBS比较少见，在通常情况下，一个WBS会融合多种分解的类型。七种分解的类型代表了在实践中发现的典型WBS。表2-1提供了有关分解的类型及WBS示例的重点描述，以帮助读者应用这些概念。
表2-1 分解的类型
不管分解的类型是什么，WBS的第一层次都表示项目名称、产品名称或计划名称。这些分解的类型适用于预测型、迭代型、增量型和敏捷型的生命周期或混合方法。在本实践标准的后续部分，将说明如何组合不同的分解类型。