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