迭代活动

项目
02/21/2013

在MSF for CMMI process improvement v6.0，则项目计划为一系列迭代。每次迭代通常长达 4-6 个星期，在此期间，开发团队将实现一组指定的要求。

迭代开始

迭代计划在各迭代开始之时或之前执行。它包括下列任务：

评审指派给迭代的要求，并且更详细地定义这些要求。
为实现和测试各个要求而必须执行的工作创建任务工作项。使用父链接类型将任务链接到要求工作项。
为各项任务设置“初始估计”字段。对估计值超过数天的任务进行划分。
比较估计值和迭代的可用时间。如果总估计时间太长，请简化部分要求，或者将这些要求推迟到后续迭代。

有关更多信息，请参见计划迭代 (CMMI)。

迭代期间

执行任务

团队成员启动和完成任务，并在工作项中记录这些事件。完成任务可能包括签入程序代码及其他项目。每项任务的持续时间不得超过数天；应在迭代计划期间拆分较大任务。有关更多信息，请参见创建、复制和更新工作项和Completing Development Tasks。

如果团队成员在工作中遇到任何无法立即解决的障碍，则应记录一个相应的问题工作项。有关更多信息，请参见问题 (CMMI)。

测试

应开发手动测试或自动测试，并且应将测试用例链接到产品要求。在将工作项链接到已通过且表明行之有效的测试用例之前，产品要求不能视为已完成。

测试的开发工作应包含在链接到产品要求的任务中。

滚动和夜间生成

生成系统根据近期签入的更新生成产品并运行自动测试。可将主体测试设置为持续运行，并且可将整个套件设置为在每个夜晚运行。此做法有助于确保多次递增不会累积 Bug。有关更多信息，请参见配置和管理生成系统。

站立会议

整个团队对迭代任务进度进行简要的每日评审。团队成员可以将“进度”面板投影在墙上，或者使用 Office Live Meeting 共享此面板，也可以同时采用两种方式。有关更多信息，请参见“进度”面板 (CMMI)。

各团队成员简要报告近期进度、正在开展的日常工作以及任何阻滞问题。
项目经理或团队主管报告解决问题的进度。有关更多信息，请参见管理问题 (CMMI)。
评审 Bug 计数。 Bug 的优先级应高于新的开发工作。其目的在于在整个项目中保持较低的 Bug 计数。如果 Bug 数目有所增加，请讨论其原因以及可能对开发工作产生的影响。
评审燃尽速度。

调整范围

“燃尽图”可以指示任务在迭代结束之前将不会完成。此种情况下，项目经理或团队主管可以围绕如何简化要求以削减任务展开讨论。有关更多信息，请参见“燃尽和燃速”报表 (CMMI)。

调整要求和相应测试。针对所缺少的功能在项目计划中添加新的要求功能。在迭代接近尾声时展开的项目计划评审中，此功能可能会指派给未来的迭代或被去除。

迭代期间，不会考虑更改请求和风险。

会审

某些团队成员（通常并非是整个团队）会定期召开会议以评审 Bug。各团队成员必须在发现缺陷时记录 Bug。记录的 Bug 的起始状态为“已建议”，会审会议的目的在于确定是修复 Bug、将其推迟到后续迭代还是拒绝此 Bug。

有关更多信息，请参见处理 Bug。

结束迭代

确认

只有关联测试已通过时，才会将要求视为已完成。有关更多信息，请参见验证要求。

追溯

过程改进是至关重要的 CMMI 目标。

迭代追溯反映迭代中正常运行或错误运行的内容，并考虑对团队所用过程和工具进行改进。可以从 Web 上获取大量有关追溯的材料。

团队成员不得给予任何谴责，而应尝试改进过程，使个人造成的失误不大可能会产生任何影响。

当对过程进行更改时，确保团队就以下决策达成一致：

改进的确定方式。
此评估的开展时间。
更改会带来哪些影响。

集成

如果该项目是较大程序的一部分，每个团队可以在版本控制系统的分支执行其工作。将保留主分支，以便集成多个团队的工作。迭代结束时，团队可能会与主分支集成。有关更多信息，请参见使用分支规避风险。

集成包含两个步骤：

正向集成，用于将主分支中的较新代码合并到本地项目分支。合并之后，将运行自动测试和手动测试。这将导致某些缺陷。将优先修复这些缺陷。
反向集成。将本地分支代码合并到主分支，并运行主分支上的生成和完整测试套件。如果出现任何错误，则会反转更改。不赞成向主分支引入错误。如果未发生错误，则会将集成声明为已完成。

建议您在每次迭代结束时执行集成。如果延迟集成，要在正向集成后修复的 Bug 列表将变长。如果修复 Bug 所需的时间较长，主分支将包含新材料，并且您必须再次执行正向集成。

准备下一个迭代

在迭代接近尾声或结束时，将执行若干项目管理活动。这些活动包括评审风险，以及评审与更改请求和更改后的开发估计值相关的计划。

有关更多信息，请参见项目活动。

通过