敏捷方法的内容（4）
发表日期：2016-06-03被浏览： 2104次返回

发布和迭代计划

 

如同在基础级大纲[ISTQB_FL_SYL]中所描述的，计划是一项持续进行的活动，并且针对敏捷项目的生命周期也是同样适用的。在敏捷项目的生命周期中，有两种不同类型的计划活动：发布计划（release planning）和迭代计划（iteration planning）。

 

发布计划的最终目的是产品的发布，通常在具体项目开始之前的数个月就会开始筹划。发布计划定义甚至是重新定义了产品待办列表，可能还会将大的用户故事细化成一系列小的用户故事。发布计划为所有迭代的测试方法和测试计划提供了基准。发布计划是高层级别的文档。

 

在发布计划制订阶段，业务代表和项目团队成员合作创建用户故事并设定每一个故事的优先级（参见1.2.2节）。根据这些用户故事，团队会识别项目风险和质量风险并且对项目工作量做粗略的估算（参见3.2节）。

 

测试人员会参与到发布计划制订中，尤其在如下活动方面提供具有价值的输入：

• 定义可被测试的用户故事，包括验收准则；

 

• 参与到项目风险和质量风险的分析活动中；

 

• 根据关联的用户故事预估测试工作量；

 

• 定义必要的测试级别；

 

• 为发布而策划测试活动。

 

在发布计划创建完成后，指导第一次迭代活动的迭代计划就开始了。迭代计划着眼于一次单独的迭代过程的顺利完成并且主要的关注点在于迭代过程的冲刺待办列表。

 

在迭代计划过程中，项目团队根据发布过程的冲刺待办列表中优先级的高低，选择用户故事、进行用户故事的评估、对用户故事进行风险分析和对每一个用户故事进行工作估算。如果某个被选中的用户故事过于宽泛并且不能提供进一步的详尽阐述，项目团队有权拒绝把这一用户故事纳入到本次迭代的范围内，并根据优先级选取下一个用户故事。业务代表必须回答项目团队成员提出的每一个关于用户故事的问题，这样可以帮助团队成员理解如何去实施和测试每一个用户故事。

 

用户故事选择的数量基于已经建立的团队速率（team velocity）和选择的用户故事估算的规模。在迭代的内容完成后，用户故事被分解成任务，这些任务会由团队成员来执行。

 

测试人员会积极参与迭代计划过程，并在如下方面提供具有价值的输入：

 

• 参与用户故事的详尽风险分析；

 

• 确定用户故事的可测试性；

 

• 为用户故事创建验收测试；

 

• 把用户故事分解成工作任务（特别是测试任务）；

 

• 为所有的测试任务进行测试工作量估算；

 

• 从功能性和非功能性角度对被测试系统的特性进行识别；

 

• 支持并参与到多个测试级别的测试自动化过程中。

 

随着项目的进行，发布计划可能被调整，包括要求修改产品待办列表中的单个用户故事。这些变更可能是由外部或内部的因素导致的。常见的内部因素有项目组交付能力、速率和技术性问题。典型的外部因素有新市场和新机会的发现、新加入的竞争者和对业务的威胁导致发布目的和日期的变化。另外，迭代计划也会在迭代过程中更改。例如，在任务预估时被评估为相对简单的某个用户故事在实际的工作中被证明是远超预期的复杂。

 

这些变更给测试人员带来了挑战。为了制定测试计划，测试人员必须从更高高度上理解版本发布，同时，如同在基础级大纲[ISTQB_FY_SYL]1.4节所述的那样，为在迭代中进行测试开发，测试人员必须有足够的测试依据和测试准则。这些必备的信息必须尽早提供给测试人员，而且依照敏捷的原则，变更也必须要包括在内。在这进退两难的局面下，必须审慎的选择测试策略和撰写测试文档。

 

发布计划和迭代计划要关注的不仅是开发计划，还有测试计划。如下是着重要关注的测试相关问题：

• 测试的范围、以及此范围的延伸范围、测试目标和所做决策的理由；

 

• 执行各项测试活动的人员；

 

• 需要的测试环境和测试数据的准备、在什么时间节点需要它们。在项目之前或者进行中是否需要额外增加或者变更测试环境或测试数据；

 

• 功能性测试和非功能性测试所需的时间、顺序、依赖关系和前置条件等（例如以何种频率执行回归测试、需要依赖于别的功能和测试数据进行的测试），以及测试活动如何与开发活动关联或者有何种依赖；

 

• 需要关注的项目风险和质量风险。

值得注意的是，较大型的项目团队的工作量估算必须要包含足够完成必要测试活动的时间和工作量。