活动：评估迭代
与瀑布式方法相比，迭代方法的一个突出优点是：迭代为评估进展与限定风险提供了天然的里程碑。在迭代内部，必须连续不断地评估进度与风险（在非正式情况下），这样可保证任何难题都不会使项目脱离正轨。
收集指标 
目的
|
本步骤以项目评测计划为基础，涉及以下工作：
- 收集原始指标
- 计算、核实指标并使其生效
- 将指标纳入状态评估报告
状态评估期间将检查指标并决定操作。这可能涉及重新计划、再利用工具、培训、重新组织等，也包括再次检查评测计划。相似地，在一个周期接近尾声时，利用“事后复审”能够确保所收集的部分指标可被用来改进流程或作出估算。
有关指标的详细信息，请参见指南： 指标中找到该示例。
评估迭代结果
目的
|
在每次迭代接近尾声时，核心项目团队应针对以下问题召开会议评估迭代：
- 是否成功实现迭代目标？
- 风险是否降低或排除？
- 此次发布是否实现了预期的功能和质量目标？是否实现性能和容量目标？
- 是否需要对项目和未来迭代计划进行变更？
- 当前发布版的哪些部分可建立基线？哪些部分必须返工？
- 是否发现了新的风险？
- 是否发生外部变更（市场、用户群或需求本身的变更）？
根据针对迭代计划制定的评估标准，对迭代结果进行评估。需要评测以下几方面：功能、性能、容量、质量。依据从测试活动与收集指标步骤得到的指标对评估进行量化；在先启阶段（也许还可在迭代初期），有定性评测就已足够；但在随后的精化、构建与产品化阶段，则必须依赖特定的测试评测来评估质量、性能、容量等方面。
如果所有风险都已缓解到可承受的程度，所有功能都得以实施，且所有质量目标都已达到，则产品即告完工。妥善的计划与执行对于在产品化阶段后期实现上述目标至关重要。
考虑外部变更
目的
|
项目团队总是着眼于内部，因而很容易忽视团队外界的变化。业务可能会改变，如增加、变更或取消关键需求。还可能由于竞争对手的同类产品打入市场，引起面市时间需求、特性或目标产品成本的变化。
考虑到当前的外部环境，项目计划（包括里程碑）是否仍然有效？是否因为风险的改变而不得不重新考虑迭代计划？正在构建的是真正需要的产品吗？要交付产品的团队的工作是否未脱离正轨？
利用这些讨论结果，就风险列表、项目计划或迭代计划拟定变更请求。
检验评估标准
目的
|
有时，由于目标定得过高，迭代达不到期望值。设定高层次目标固然重要，但是在鼓励进取与不切实际之间存在一条微妙的分界线。设定得当的目标可激励项目团队为早日实现目标全力以赴；但若目标迟迟难以实现，则成员的士气很容易受挫。有时候，为了给予项目团队一定的挑战，同时又不致让成员产生挫折感，制定目标本身就需要几次迭代，这样可使成员学会如何合作，并了解团队自身的局限性。
请检验评估标准，确定是否可行。 迭代的优点有时在于：它能够揭示最初认为极其重要，而实际却并非如此重要的特殊需求。项目往往受到复杂但价值较低的需求的重压，这些需求是迷恋新技术、心情急切的用户所强加的。一两次迭代可让用户重新考虑他们的期望，使他们的注意力集中到带来真正价值的功能上。
迭代有时会揭示出某个特性的实施代价极高，或建立的构架无法维护。那么，应重新检查这个特性的商业理由，查看是否应保留该特性，或可能需要进行修改，以成本合算的方式实现需求。
拟定变更请求
目的
|
依据评估结果，就风险列表、项目计划、迭代计划与需求提出变更方案。
