(对于迭代而言)按时间排序的一组活动和任务,具有分配的资源,且包含任务依赖关系;一个细分的计划。 
角色: 项目经理 
可选/发生: 必需。
模板和报告:
     
示例:
     
UML 表示: 不适用。
更多信息:  
活动的输入:   活动的输出:  

用途 到页首

以下人员使用迭代计划:

  • 项目经理,用以计划迭代任务和活动,安排资源需求并根据时间表跟踪进度
  • 项目团队成员,用以了解他们需要做什么、何时需要以及依赖于其它的哪些活动

计时 到页首

对于即将进行的迭代,其迭代计划是在当前迭代中计划的。按需要在迭代期间修改。

一个迭代计划是下一个迭代计划的输入信息。迭代结束后,该迭代计划就失效了。

职责 到页首

项目经理负责迭代计划的完整性。

定制 到页首

迭代计划需要细致地详细描述要做的事项,这样就会明确任何时候的真正职位和职责。通常,将使用某种项目计划工具(如 Microsoft® Project)。

附加信息 到页首

这是一个迭代的精细计划。通常存在两个这样的计划:一个用于当前迭代,而另一个构建中的计划用于下一个迭代。

要定义迭代的内容,则需要:

  • 项目计划
  • 项目的当前状态(跟踪中、后期、大量问题、需求渐变等等)
  • 必须在迭代结束前完成的一系列场景或用例
  • 必须在迭代结束前处理的一系列风险
  • 必须并入产品的一系列变更(错误修正、需求变更)
  • 必须完全实现的一系列主要类或包

必须对这些列表划分等级。迭代的目标应是积极的,这样,在出现困难时,可根据各项的等级从迭代中略去各项。

评估条件

每次迭代都通过评估得出结论。对于此次迭代评估,您将相对于为迭代计划建立的评估条件来评估迭代结果。

迭代条件在每次迭代之前确立,同时确立要在迭代中达到的功能组、质量和性能的目标。达到这些目标的实际情况将是不同的。例如,对于给定的迭代,可能会超出功能集要求,勉强达到质量要求,而缺乏性能。

另外,可以将目标表示为最低目标和期望目标。例如,如果开发速度和职员配备级别允许,可能将在此次迭代中尝试实现所需的功能组和某些期望的功能。



Rational Unified Process   2003.06.15