任务:评估迭代
此任务描述了如何评估与迭代评估结果相关的项目信息并决定适当的更改。
规程:项目管理
用途

此任务的目的是:

  • 确定迭代的成败
  • 捕获学到的教训以修改项目或改进流程
关系
角色主执行者: 其他执行者:
输入必需:
    可选:
      输出
        流程使用情况
        主要描述

        瀑布法相比,迭代法的一个突出优点是,迭代为评估进展与限制风险提供了天然的里程碑。在迭代中,必须继续评估进度和风险(如果非正式),以确保困难不会使项目偏离正轨。

        迭代 N 评估的摘要。



        步骤
        收集度量值
        目的 收集项目的质量和进度信息,以了解项目的状态并作出改进

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

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

        在迭代评估期间,检查度量值,决定所有操作,这些操作可能涉及到重新计划、重新加工、培训、重新组织等等,包括重访度量计划。类似地,在一个周期结束时,利用“事后复审”可以确保所收集的部分度量值能用来改进流程或作出估算。关于度量值的更多信息,请参阅 工作产品指南:度量值

        对于跨越数周甚至数月的迭代,度量值收集和报告将是持续的任务,而且定期有工作产品:状态评估来获取中间结果。

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

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

        • 迭代是否成功地满足其目标?
          • 是否减少或消除了风险?
          • 发布的迭代是否满足其功能和质量目标?性能和容量目标呢?
        • 是否需要对项目和将来的迭代计划进行更改?
        • 是否由于迭代期间的更改(作为要求对诸如项目开发流程之类的其他工作产品进行更改的结果),而使得任何在 工作产品:开发组织评估中获取的任何发现结果无效?
        • 迭代期间对于项目的开发流程是否存在任何困难?
        • 当前发行版的哪一部分将设置基线?哪一部分将要重做?
        • 是否识别了新的风险?
        • 是否发生了外部变化(市场中的变化、用户团体中的变化或需求的变化)?

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

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

        考虑外部变更
        目的 确保项目与“外界”保持连接

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

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

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

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

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

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

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

        拟订变更请求
        目的 更新项目计划工作产品。 

        根据这些评估结果,为远景风险列表软件开发计划迭代计划、项目的开发流程软件需求生成变更请求。



        更多信息
        指南