使用 Azure Boards 中的 CMMI 过程管理更改

  • 项目

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

你可以利用更改请求工作项来跟踪和控制对产品及支持系统进行的所有更改。 所有更改请求都是由于与基线偏差而启动的，该基线由为项目标识的原始要求组成。 例如，如果与用户进行会议时发现新的要求，则应创建更改请求以建议更新要求基线。 有关 CMMI 的详细信息，请参阅 CMMI 的背景。

创建更改请求

当意识到必须更改原始要求时，请创建一个更改请求工作项并使用 Affects 链接类型将其链接到旧要求工作项。 还应创建一个包含新增要求或更改内容详细信息的要求工作项，并将其链接到更改请求。 所有更改请求都将进行广泛的分析，以确定其对用户、产品和团队的影响。 在此分析期间，可能会中断任务以进行估算。 这些新任务工作项应链接至新需求工作项以实现可跟踪性。 通过在工作项窗体的“实现”选项卡上添加任务来完成此结果。

更改请求及其产生的新工作项必须包含所需全部新工作以及要删除、修改或排除的全部现有工作的详细信息。 可以从 Web 门户的主页或团队资源管理器中的“工作”页创建更改请求，如 开始使用工作项中所述。 可以在“标题”字段中指定要请求的更改、拥有更改的团队成员以及有关请求的其他信息。

Change Request Work Item Form

有关如何完成工作项的详细信息，请参阅 CMMI 工作项和工作流。

分析更改请求

在对更改请求进行分析之前，应由配置控制委员会进行会审。 配置控制委员会是一个群体，负责批准和拒绝更改请求并确保正确实施更改。 你可以通过将工作项中的“会审”字段设置为“挂起”指明必须对请求进行会审。 有关详细信息，请参阅 更改请求字段 (CMMI) 。 对更改请求的分析可能会耗尽资源，并且更改请求队列不会对团队施加不必要的需求并影响项目日程表非常重要。

应分析更改请求以确定其对现有工作和计划工作的影响范围。 必须知道影响范围，以确保可以利用它来估算实施更改的工时成本。

分析接受更改的风险。 外部团队的参与是否取决于要更改的代码或功能，他们的日程安排是否会受到不利影响？ 此更改的资源分配是否会对其他重要功能区域或产品要求产生不利影响？

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

如果接受更改请求，请将“状态”从“已提议”（新更改请求的默认状态）更改为“活跃”。

监视更改请求

当更改请求处于活跃状态时，你可以通过查看“打开的有需求的更改请求”查询进行监视。 此外，还可以 创建更改请求时的电子邮件警报 。 应在合理的时间内处理更改请求。

如果更改请求未收到它所需的关注，请通过创建问题工作项来升级此事。 将新问题链接到更改请求，并升级问题使更改请求影响评估回到正轨。