迭代活动
在 MSF for CMMI Process Improvement v5.0 中，您应将项目计划为一系列迭代。 每次迭代通常长达 4-6 个星期，在此期间，开发团队将实现一组指定的要求。
迭代开始
迭代计划在各迭代开始之时或之前执行。 它包括下列任务：
评审指派给迭代的要求，并且更详细地定义这些要求。
为实现和测试各个要求而必须执行的工作创建任务工作项。 使用父链接类型将任务链接到要求工作项。
为各项任务设置“初始估计”字段。 对估计值超过数天的任务进行划分。
比较估计值和迭代的可用时间。 如果总估计时间太长，请简化部分要求，或者将这些要求推迟到后续迭代。
有关更多信息，请参见计划迭代 (CMMI)。
迭代期间
执行任务
团队成员启动和完成任务，并在工作项中记录这些事件。 完成任务可能包括签入程序代码及其他项目。 每项任务的持续时间不得超过数天；应在迭代计划期间拆分较大任务。 有关更多信息，请参见创建、复制和更新工作项和完成开发任务。
如果团队成员在工作中遇到任何无法立即解决的障碍，则应记录一个相应的问题工作项。 有关更多信息，请参见问题 (CMMI)。
测试
应开发手动测试或自动测试，并且应将测试用例链接到产品要求。 在将工作项链接到已通过且表明行之有效的测试用例之前，产品要求不能视为已完成。
测试的开发工作应包含在链接到产品要求的任务中。
滚动和夜间生成
生成系统根据近期签入的更新生成产品并运行自动测试。 可将主体测试设置为持续运行，并且可将整个套件设置为在每个夜晚运行。 此做法有助于确保多次递增不会累积 Bug。 有关更多信息，请参见管理 Team Foundation Build。
站立会议
整个团队对迭代任务进度进行简要的每日评审。 团队成员可以将“进度”面板投影在墙上，或者使用 Office Live Meeting 共享此面板，也可以同时采用两种方式。 有关更多信息，请参见“进度”面板 (CMMI)。
各团队成员简要报告近期进度、正在开展的日常工作以及任何阻滞问题。
项目经理或团队主管报告解决问题的进度。 有关更多信息，请参见管理问题 (CMMI)。
评审 Bug 计数。 Bug 的优先级应高于新的开发工作。 其目的在于在整个项目中保持较低的 Bug 计数。 如果 Bug 数目有所增加，请讨论其原因以及可能对开发工作产生的影响。
评审燃尽速度。
调整范围
“燃尽图”可以指示任务在迭代结束之前将不会完成。 此种情况下，项目经理或团队主管可以围绕如何简化要求以削减任务展开讨论。 有关更多信息，请参见“燃尽和燃速”报表 (CMMI)。
调整要求和相应测试。 针对所缺少的功能在项目计划中添加新的要求功能。 在迭代接近尾声时展开的项目计划评审中，此功能可能会指派给未来的迭代或被去除。
迭代期间，不会考虑更改请求和风险。
会审
某些团队成员（通常并非是整个团队）会定期召开会议以评审 Bug。 各团队成员必须在发现缺陷时记录 Bug。 记录的 Bug 的起始状态为“已建议”，会审会议的目的在于确定是修复 Bug、将其推迟到后续迭代还是拒绝此 Bug。
有关更多信息，请参见处理 Bug。
结束迭代
确认
只有关联测试已通过时，才会将要求视为已完成。 有关更多信息，请参见验证要求。
追溯
过程改进是至关重要的 CMMI 目标。
迭代追溯反映迭代中正常运行或错误运行的内容，并考虑对团队所用过程和工具进行改进。 可以从 Web 上获取大量有关追溯的材料。
团队成员不得给予任何谴责， 而应尝试改进过程，使个人造成的失误不大可能会产生任何影响。
当对过程进行更改时，确保团队就以下决策达成一致：
改进的确定方式。
此评估的开展时间。
更改会带来哪些影响。
集成
如果此项目是较大程序的一部分，各个团队应在版本控制系统的分支中开展其工作。 将保留主分支，以便集成多个团队的工作。 迭代结束时，团队可能会与主分支集成。 有关更多信息，请参见分支和合并。
集成包含两个步骤：
正向集成，用于将主分支中的较新代码合并到本地项目分支。 合并之后，将运行自动测试和手动测试。 这将导致某些缺陷。 将优先修复这些缺陷。
反向集成。 将本地分支代码合并到主分支，并运行主分支上的生成和完整测试套件。 如果出现任何错误，则会反转更改。 不赞成向主分支引入错误。 如果未发生错误，则会将集成声明为已完成。
建议您在每次迭代结束时执行集成。 如果延迟集成，要在正向集成后修复的 Bug 列表将变长。 如果修复 Bug 所需的时间较长，主分支将包含新材料，并且您必须再次执行正向集成。
准备下一个迭代
在迭代接近尾声或结束时，将执行若干项目管理活动。 这些活动包括评审风险，以及评审与更改请求和更改后的开发估计值相关的计划。
有关更多信息，请参见项目活动。