在适应型或敏捷型生命周期中，通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。
采用适应型生命周期，在应对大量变更，需要相关方持续参与项目；
将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时成为产品未完项）。
在适应型或敏捷型生命周期中，发起人和客户代表应该持续参与项目，随同可交付成功的创建提供反馈意见，并确保产品未完项反映他们的当前需求。----迭代评审会
适应型生命周期的项目，则使用未完项（包括产品需求和用户故事）反映当前需求。

知识点展开：

• 1、迭代式开发：每次迭代前规划好本次迭代的具体任务，每次迭代后产出可运行、可演示的交付成果。
• 2、频繁参与：适应型项目需要关键相关方（如产品负责人、客户、发起人等）频繁参与到每个迭代前的规划或迭代后的评审会，以提供对产品的期望、反馈以及对增量的验收。尽早且频繁地让相关方参与项目，有利于尽早调整后续迭代以拥抱相关方不断变化的需求。
• 3、产品未完项（Product Backlog，PB表）：即产品待办列表，源于客户、发起人，经过产品负责人，由产品负责人对其中的各需求项进行价值优先级排序。

在敏捷或适应型环境中需要考虑得因素

在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过发布多个版本来明确需求。范围会在整个项目期间被定义和在定义。在敏捷方法中，把需求列入未完项。

知识点展开：

• 1、敏捷的早期计划：项目早期快速创建两个高层级计划：产品路线图（极其粗略地描述产品随版本的演进）、版本计划（粗略地规划当前版本，称为发布计划）
• 2、采用原型法渐进式地明确需求：项目过程中每一次迭代结束时，以及每一个版本结束时，都会让关键相关方对已开发的增量、已开发的版本进行评审，并提供反馈以及新的需求。

收集需求的工具：用户故事

知识点展开：
一个用户故事代表一项独立的需求。可用于产品待办列表中对每个需求项的具体描述。因这种需求描述形式永远以产品的用户为主。作为<旅客>，我想要<注册成为XX旅店会员>，以便<使用网上预订房间的服务>。

定义范围的描述

在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。

知识点展开：
敏捷的渐进明细：项目初始阶段快速根据相关方的期望而制定高层级计划：产品愿景、产品路线图、版本计划；接着，在每次迭代之前才详细规划本次得带所需开发的内容，从而产生详细的迭代计划（仅规划当前迭代，当前迭代结束后在考虑下一次迭代）。

创建WBS的描述

可以将长篇故事分解成用户故事。

知识点展开：