目的
  • 确定迭代的成败
  • 捕获学到的教训以修改项目或改进流程
角色: 项目经理 
频率:每个迭代一次
步骤
输入工件:   结果工件:  
工具向导:  

工作流程明细:  

迭代法优于瀑布法的主要优势之一是迭代为评估进度和界定风险提供了天然的里程碑。在迭代中,必须继续评估进度和风险(如果非正式),以确保困难不会使项目偏离正轨。

迭代 N 评估的摘要。

 

收集度量值 回到页首

目的 为状态和改进收集关于项目的质量和进度信息

根据项目的度量计划,此步骤涉及到以下工作:

  • 收集原始度量值
  • 计算、验证和确认度量值
  • 将度量值包含在状态评估报告中

在迭代评估期间,检查度量值,决定所有操作,这些操作可能涉及到重新计划、重新加工、培训、重新组织等等,包括重访度量计划。类似地,在循环结束时,“事后复审”可以确保收集到的一些度量值能用来改进流程,或用于估计目的。

对于跨越数周甚至数月的迭代,度量值收集和报告将是持续的活动,而且伴随有定期的工件:状态评估来捕获中间结果。

评估迭代的结果 回到页首

目的 比较迭代的实际结果和预期结果。 

当接近每个迭代的结束时,核心项目团队应举行会议来评估迭代,应将注意力集中于以下方面:

  • 迭代是否成功地满足其目标?
    • 是否减少或消除了风险?
    • 发布的迭代是否满足其功能和质量目标?性能和容量目标呢?
  • 是否需要对项目和将来的迭代计划进行更改?
  • 迭代期间对于开发流程存在任何困难吗?
  • 当前发行版的哪一部分将设置基线?哪一部分将要重做?
  • 是否识别了新的风险?
  • 是否发生了外部变化(市场中的变化、用户团体中的变化或需求的变化)?

相对于为迭代计划建立的以下评估条件,评估迭代的结果:功能、性能、容量和质量度量。使用从测试活动中生成的度量值和步骤收集度量值作为评估的基础(如果可用),以量化评估;定性的度量对于先启(也许还对于早期迭代)已足够,但随后的精化、构造和移交必须依赖特定的测试度量来评估质量、性能、容量等等。解决迭代期间执行的状态评估中捕获到的其它未解决问题,以及项目经理的问题列表中的任何其它问题。

如果所有风险均已减小到可以接受的水平,所有功能均已实施,所有质量目标均已达到,则产品就完成了。对于在移交阶段结束时实现产品的完成,良好的计划和执行是至关重要的。

考虑外部变更 回到页首

目的 确保项目保持与“外部世界”连接

项目团队很容易变得如此关注于内部,以至于他们不了解项目团队以外的世界发生的变化。业务可能发生改变,从而添加、更改或除去关键需求。或者竞争对手可能带着类似产品进入市场,从而导致市场时机选择需求、功能或目标产品成本发生改变。

在给定外部环境的当前状态的情况下,项目计划(包括里程碑)是否仍有效? 风险是否已发生改变,从而迫使重新考虑迭代计划? 是否正在构造正确的产品,远景是否仍然有效? 产品团队是否处在交付该产品的轨道上? 是否由于外部环境的不断改变而必须更改流程?

使用这些讨论的结果,为远景、风险列表、项目计划、迭代计划或开发案例生成变更请求。

检查评估条件 回到页首

目的 确保评估条件是现实的。 

有时候迭代会因为目标设得过高而达不到预期。设置高目标是重要的,但有时雄心勃勃和异想天开之间存在微妙的界线。项目团队受到那些能使他们充分施展能力的目标的激励,但如果目标始终超出他们的能力,他们容易变得士气低落。有些目标可使项目团队觉得富有挑战性,同时又不会感到无法完成,定义这样的目标有时会在其内部执行几次迭代,因为团队学会了协作,也了解了自己的局限。

检查评估条件,确定它们是否现实。有时候迭代的好处在于揭示特定的需求不像最初想的那样重要,最初本来认为它本身很有价值。项目常常遭到复杂但又价值不大的需求的破坏,这些需求常常由受到最新技术迷惑又过于急切的用户强加;一次或两次迭代可以重新设置他们的预期,并使他们将注意力集中在能提供真正价值的功能。

有时候迭代将揭示实施某个特定功能的代价非常高昂,或者该功能会创建不可维护的体系结构。应重访该功能的业务案例,以查明该功能是应保留在范围内,还是可能要进行修订,以使得能以成本效率较高的方法达到需求。

创建变更请求 回到页首

目的 更新项目计划工件。 

根据评估结果,为远景、风险列表、项目计划、迭代计划、开发案例和需求创建变更建议。



Rational Unified Process   2003.06.15