管理更改 (CMMI)

可以使用更改请求工作项来跟踪和控制对产品和支持系统所做的所有更改。 所有更改请求都是因为偏离基线而发起的，基线包含为项目标识的原始要求。 例如，如果用户会议发现新的要求，则应创建更改请求以提出更新要求基线的建议。 有关 CMMI 的更多信息，请参见 CMMI 背景信息。

主题内容

• 创建更改请求

• 分析更改请求

• 监视更改请求

创建更改请求

当您意识到必须更改某个原始要求时，可以创建更改请求工作项并使用“影响”链接类型将其链接到旧的要求工作项。 此外，应创建一个包含有关新内容或已更改内容的详细信息的要求工作项，并将其链接到更改请求。 广泛分析所有更改请求，了解对用户、产品和团队产生的影响。 在进行此分析的过程中，可能会中断任务以进行评估。 这些新的任务工作项应链接到新的要求工作项以实现可跟踪性。 通过在该工作项窗体的“实现”选项卡上添加这些任务来完成此操作。

更改请求和所得到的新工作项必须包含有关所需的所有新工作和要移除、修改或排除的所有现有工作的详细信息。 如下图所示，可以指定在“标题”字段中请求的更改、拥有此更改的团队成员和有关此请求的其他信息：

有关如何完成该工作项的更多信息，请参见更改请求 (CMMI)。

分析更改请求

在分析某个更改请求前，应通过配置控制委员会对它进行会审。 配置控制委员会是一组人员，他们负责批准和拒绝更改请求并确保能够正确实现更改。 可以通过将工作项中的“会审”字段设置为“挂起”，来指示必须对请求进行会审。 有关更多信息，请参见更改请求 (CMMI)。 对更改请求进行分析可能会耗尽资源，并且更改请求队列一定不能对团队提出过度的要求并影响项目时间线。

应分析更改请求以确定它对现有工作和计划工作产生的影响的范围。 必须了解产生的影响，以通过它来估计实现更改所需的成本（以人/小时为单位）。

分析接受更改所带来的风险。 外部团队是否依赖要更改的代码或功能，以及其计划是否会带来不利的影响？ 为此更改指派资源是否会对其他重要功能区域或产品要求产生负面影响？

作为分析的一部分，请求利益干系人进行输入，并将该输入添加到更改请求工作项。 如果该更改要求对其他计划文档进行更改，则请注意，在更改请求中，根据需要更改这些文档。 这将保留修订历史记录，并使每个人能够查看详细信息。 这可缓解通信不畅的风险，并为过程改进 CMMI 标准评估方法 (SCAMPI) 评估提供重要证据。

如果接受更改请求，则将状态从“已建议”（新的更改请求的默认选项）更改为“活动”。

监视更改请求

当更改请求处于活动状态时，可通过使用 Visual Studio Team Foundation Server 中的更改请求查询对其进行监视。 应在合理的时间内处理更改请求。

如果更改请求未得到所需关注，则通过创建问题工作项将事情升级。 将新问题链接到更改请求，并逐步升级此问题，以跟踪更改请求影响评估。