2.2.4　在敏捷型生命周期中使用WBS

对于需求不断变化或不确定性高的项目，在项目开始时通常无法完全明确项目的范围，而需要在项目期间逐渐明确。敏捷实践特意在项目的早期阶段缩短定义和协商范围的时间，同时花费更多的时间来建立用于不断探索和完善的过程。在多数情况下，不断涌现的需求往往导致期望的商业需求与最初描述的商业需求间存在差异。

敏捷实践有目的地构建并评审原型和发布版本以细化和完善需求。因此，范围在整个项目中被定义和重新定义。在敏捷方法中，产品待办事项列表构成了已知的需求。敏捷方法中的需求代表了史诗、特性或用户故事。

产品负责人在团队、相关方和商业分析专业人士的帮助下，创建产品待办事项列表。产品代办事项列表帮助团队了解如何在不产生浪费的情况下交付最高价值。

在敏捷型生命周期中，项目发起人和客户代表会定期参与项目，在创建可交付成果时提供反馈，并确保产品待办事项列表能反映当前的需求。

WBS通常与预测型生命周期相关联，并支持对项目的整个范围进行分解。当采用敏捷实践时，要将整个范围分解为更小的部分，从而支持待办事项列表或产品待办事项列表。

在敏捷型生命周期中，WBS包含商业价值项，这通常被称为需求、待办事项列表或用户故事。每个需求、待办事项列表项或用户故事都代表了交付该项所描述的用户功能所需的工作。每个需求、待办事项列表项或用户故事都交付了一个功能的小增量、输出或可交付成果。工作包代表了WBS中分解的最低层次。用户故事是敏捷项目中分解的最低层次。工作包和用户故事都向客户交付功能。工作包和用户故事都是关于做什么而不是如何做的。工作包大致等于用户故事。

对于在敏捷环境中执行的项目，团队期望需求会发生改变。迭代和增量方法能够提供反馈，以更好地规划项目的下一部分。图2-12显示了实现增量交付的两种可能的方法（基于迭代的敏捷方法和基于流程的敏捷方法），这都有助于敏捷项目与客户的需求保持一致，并可以根据需要进行调整。

在基于迭代的敏捷方法中，团队通过迭代（使用Scrum框架时的冲刺，它具有相同持续时间的时间盒）来交付完整的特性。在使用迭代的敏捷型生命周期中，有一个关于用户故事（工作包）规模的目标：用户故事应该在单次迭代（冲刺）中交付。如果用户故事不能在单次迭代（冲刺）中交付，则将用户故事拆分为更小的用户故事。

在基于流程的敏捷方法中，团队将根据自身的能力，从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。

下面是一些分解敏捷项目的不同方法，但不限于此：

◆ 产品、迭代、用户故事。

◆ 产品、发布、迭代、用户故事。

◆ 产品、发布、特性、迭代、用户故事。

◆ 产品、特性、发布、迭代、用户故事。

◆ 产品、史诗、特性、迭代、用户故事。

◆ 产品、特性、史诗、迭代、用户故事。

对于敏捷项目，存在各种各样的WBS场景。

第一种场景如图2-13所示。

◆ 项目名称或产品名称出现在WBS的第一层次。

◆ 迭代（冲刺）出现在WBS的第二层次（如1.1、1.2、1.3、1.4、1.5等）。

◆ 用户故事出现在WBS的第三层次。敏捷项目中的用户故事是分解的最低层次，具有与工作包相似的特征。用户故事和工作包都可产生一个或多个可交付成果或功能。

第二种场景如图2-14所示。

◆ 项目名称或产品名称出现在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所示。