管理更改

Azure DevOps Services |Azure DevOps Server 2022 - Azure DevOps Server 2019

Azure DevOps 提供了各种工具和功能,可帮助你有效地管理更改,这是任何项目的关键部分。 本文概述了如何管理变更并将敏捷更改管理任务映射到 Azure DevOps 支持的工具。

确定更改需求

多个来源可以促成在软件开发项目中进行的必需更改:

  • 更改业务和客户需求
  • 新优先级
  • 由于新信息或发现依赖项,功能要求不断演变
  • 资源和组织的更改
  • 开发或测试延迟
  • 部署后和正在进行的作期间出现的问题

最大程度地减少不必要的更改

若要最大程度地减少不必要的更改,请确保满足以下条件:

  • 明确要求和验收标准
  • 明确项目范围和优先级
  • 同意的变更管理流程
  • 准确估算计划工作
  • 新工作的经过协商的请求
  • 发生更改时团队内的有效沟通
  • 利益相关者和客户关于更改请求的反馈
  • 团队成员在问题出现时放心地提出问题

实现用于变更管理的敏捷最佳做法

敏捷是一种项目管理方法,它通过将项目分解成称为“冲刺”的简短迭代周期来工作。 敏捷的核心是基于以下假设:随着项目的发展,环境发生变化。 因此,在敏捷项目中,永远不会完成规划、设计、开发和测试周期。 随着项目逐渐成型,它们会继续变化。

为了缓解发生变更的问题,敏捷项目经理采用许多最佳做法。 这些做法分为以下类别:控制流程、管理产品计划级别的更改、管理冲刺和考虑更改条件。

类别 最佳做法
控制进程 - 满足团队和业务目标
- 最大程度地减少解决更改所需的审批次数
- 协助团队持续改进流程
提示: 持续改进是确保流程、方法和做法尽可能高效且有效的方法。
管理产品计划层的变更 - 持续优化和确定产品计划和产品积压工作优先级
- 确保了解并正确确定和传达客户需求
- 分析产品待办事项清单中的依赖项和风险
- 制定应变计划
- 分析和会审更改请求
- 确定更改请求对当前和计划工时的影响范围
- 评估接受或拒绝更改的风险
- 根据需要使用简单的变更控制表格
管理你的迭代周期 - 确保在冲刺开始时彻底了解验收标准和要求
- 尽量减少在迭代开始后接受更改,同时仍遵循敏捷原则
- 随着变化出现,保持所有利益相关者和团队的参与
- 控制范围更改并尽量减少范围蔓延
- 防止团队做出超出原始商定范围的项目更改
提示:什么是范围爬行?当项目的可交付结果或功能从最初定义的范围扩展时发生范围爬行,而不会对额外时间或预算进行相适应的更改。
考虑更改条件 考虑进行更改时,请提出以下问题:
- 它是否有助于实现冲刺目标?
- 更改是否有明确的业务价值?
- 发布后,是否打算使用范围更改的结果?
- 更改请求的紧迫性是什么?
- 如果将新范围添加到冲刺积压工作,是否有可删除的内容?

跟踪更改

从多种方法中进行选择以跟踪更改,范围从轻量级到可靠:

  • 通过讨论、对验收条件或附件的更改,跟踪对要求工作项内要求的更改。
  • 更改标签添加到工作项,以支持跟踪工作范围更改。
  • 设置通知以自动传达团队或组织中的更改。
  • 添加跟踪范围变化或其他工作的 bug。
  • 添加更改请求工作项类型,以正式跟踪更改请求并将其记录到产品积压工作。

使用上述任一方法,可以生成查询来列出更改涉及的工作项,然后与团队一起查看和会审更改。 选择一种跟踪方法,使之与你和团队监控和报告变更范围的方式一致。

方法 详细信息
使用更改请求表单 定义更改请求工作项类型,例如功能成熟度模型集成(CMMI)过程的下图中的更改请求工作项类型。
更改请求工作项窗体的屏幕截图。
可以采用此窗体或自定义自己的表单。 还可以让更改请求与其他用户情景或要求一起显示在积压工作上。
定义验收条件 请清楚地描述“完成”的含义,以接受标准来验证是否完全实施要求或 bug 修复。 请在工作项中记录这些标准。 明确的验收标准可帮助团队估算工作并开发测试,以确保满足这些条件。
指定各个要求和冲刺的验收条件,以确保所有团队成员都了解工作范围。

监视和报告更改

Teams 可以通过工作项查询、团队速率图表和冲刺燃尽图和发布燃尽图来监视更改。

方法 详细信息
工作项查询 利用 查询,您可以查找并分类变更管理请求列表或带有变更管理标签的工作项。
团队的速度和计划外的工作 团队 速度图 提供了几条信息。 此图表显示计划工时和完成的工作量。 从视觉上看,你可以确定在冲刺开始后向冲刺添加工作的频率。
冲刺燃尽图和范围蔓延 另一个用来检查范围蔓延的图表是冲刺燃尽图。 使用 Azure Boards,你可以查看每个冲刺和每个团队的冲刺燃尽图,以确定每个冲刺中引入的范围蔓延程度。

获取更改通知

Azure DevOps 提供可靠的警报系统,项目成员可以 自行、团队或项目设置警报。 当工作项、代码评审、源代码管理文件和内部版本发生更改时,可以接收电子邮件通知。