活动:
|
目的 | 为状态和改进收集关于项目的质量和进度信息 |
根据项目的度量计划,此步骤涉及到以下工作:
在迭代评估期间,检查度量值,决定所有操作,这些操作可能涉及到重新计划、重新加工、培训、重新组织等等,包括重访度量计划。类似地,在循环结束时,“事后复审”可以确保收集到的一些度量值能用来改进流程,或用于估计目的。
对于跨越数周甚至数月的迭代,度量值收集和报告将是持续的活动,而且伴随有定期的工件:状态评估来捕获中间结果。
目的 | 比较迭代的实际结果和预期结果。 |
当接近每个迭代的结束时,核心项目团队应举行会议来评估迭代,应将注意力集中于以下方面:
相对于为迭代计划建立的以下评估条件,评估迭代的结果:功能、性能、容量和质量度量。使用从测试活动中生成的度量值和步骤收集度量值作为评估的基础(如果可用),以量化评估;定性的度量对于先启(也许还对于早期迭代)已足够,但随后的精化、构造和移交必须依赖特定的测试度量来评估质量、性能、容量等等。解决迭代期间执行的状态评估中捕获到的其它未解决问题,以及项目经理的问题列表中的任何其它问题。
如果所有风险均已减小到可以接受的水平,所有功能均已实施,所有质量目标均已达到,则产品就完成了。对于在移交阶段结束时实现产品的完成,良好的计划和执行是至关重要的。
目的 | 确保项目保持与“外部世界”连接 |
项目团队很容易变得如此关注于内部,以至于他们不了解项目团队以外的世界发生的变化。业务可能发生改变,从而添加、更改或除去关键需求。或者竞争对手可能带着类似产品进入市场,从而导致市场时机选择需求、功能或目标产品成本发生改变。
在给定外部环境的当前状态的情况下,项目计划(包括里程碑)是否仍有效? 风险是否已发生改变,从而迫使重新考虑迭代计划? 是否正在构造正确的产品,远景是否仍然有效? 产品团队是否处在交付该产品的轨道上? 是否由于外部环境的不断改变而必须更改流程?
使用这些讨论的结果,为远景、风险列表、项目计划、迭代计划或开发案例生成变更请求。
目的 | 确保评估条件是现实的。 |
有时候迭代会因为目标设得过高而达不到预期。设置高目标是重要的,但有时雄心勃勃和异想天开之间存在微妙的界线。项目团队受到那些能使他们充分施展能力的目标的激励,但如果目标始终超出他们的能力,他们容易变得士气低落。有些目标可使项目团队觉得富有挑战性,同时又不会感到无法完成,定义这样的目标有时会在其内部执行几次迭代,因为团队学会了协作,也了解了自己的局限。
检查评估条件,确定它们是否现实。有时候迭代的好处在于揭示特定的需求不像最初想的那样重要,最初本来认为它本身很有价值。项目常常遭到复杂但又价值不大的需求的破坏,这些需求常常由受到最新技术迷惑又过于急切的用户强加;一次或两次迭代可以重新设置他们的预期,并使他们将注意力集中在能提供真正价值的功能。
有时候迭代将揭示实施某个特定功能的代价非常高昂,或者该功能会创建不可维护的体系结构。应重访该功能的业务案例,以查明该功能是应保留在范围内,还是可能要进行修订,以使得能以成本效率较高的方法达到需求。
目的 | 更新项目计划工件。 |
根据评估结果,为远景、风险列表、项目计划、迭代计划、开发案例和需求创建变更建议。
Rational Unified Process
|