结束冲刺 (sprint) 活动

  • 项目

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

在结束冲刺 (sprint) 时，团队可能需要处理几个任务，以维护积压工作安全机制。 一般情况下，绝不应将未完成的工作分配给过去的冲刺 (sprint)。 团队需要确定他们想要如何处理冲刺 (sprint) 中未完成的工作，并采取适当的措施。

注意

无法自动将分配到一个冲刺 (sprint) 的未完成工作项移动到另一个冲刺 (sprint)。 也没有自动执行的方式来清零剩余工时。

在每个冲刺 (sprint) 结束时，每个团队应确定并采取措施来解决以下问题：

  • 我们应如何处理在结束冲刺 (sprint) 时仅部分完成的用户情景及其任务？
  • 在最后管理部分完成的工作以正确计算冲刺 (sprint) 指标和速度的正确方法是什么？
  • 我们的评审对象是什么，按什么顺序评审？

通常，结束冲刺 (sprint) 活动应在冲刺 (sprint) 评审会议之前或之后，以及冲刺 (sprint) 追溯会议之前完成。 要考虑的主要项是维护视图和指标，以支持团队的冲刺 (sprint) 评审、追溯会议和冲刺 (sprint) 计划。

结束冲刺 (sprint) 活动的目标

每个冲刺 (sprint) 都表示一个分配了工作的固定开发时间段。 请查看以下清单，了解在执行结束冲刺 (sprint) 活动时要记住的目标。

  • 维护积压工作安全机制，确保不会将未完成的工作分配到结束日期已过的冲刺 (sprint)
  • 管理工作项状态和冲刺 (sprint) 分配，以支持监视团队进度和速度
  • 支持团队的持续改进活动
  • 支持团队专注于交付软件和实现冲刺 (sprint) 目标
  • 最大程度地减少无价值的工作跟踪工作

提示

团队速度不是衡量团队工作效率的指标，只应用作规划未来冲刺 (sprint) 的指标。 工作要么在结束冲刺 (sprint) 时完成，要么没有完成。 如果工作完成了，就纳入计数。 如果没有完成，它会在未来的冲刺 (sprint)，而不是当前的冲刺 (sprint) 中予以重新考虑。 无论做何选择，速度均会趋于平稳。 但是，如果只考虑已完成的工作，你会朝着一个更现实的价值和一个更好的历史数据来源努力，做出未来的预测。

确定团队首选项

下面的建议介绍了团队应考虑执行的主要结束冲刺冲刺 (sprint) 活动。 通常，这些活动应在冲刺 (sprint) 的最后一天或冲刺 (sprint) 评审会议之后完成。

  • 查看冲刺 (sprint) 积压工作，了解未完成的用户情景、积压工作项和任务。 可以通过查看冲刺 (sprint) 积压工作或冲刺 (sprint) 任务板来执行评审。

  • 将用户情景、积压工作项和未启动的任务重新分配到产品积压工作或下一个冲刺 (sprint)。 使用“规划”窗格，可以重新分配到团队积压工作或未来的冲刺 (sprint)。 可以重新估计重新分配的工作项，并设置其优先级。

  • 确定如何处理未完成的用户情景、积压工作项或任务。 请记住，目标是交付工作软件。 这里有两个选择：

    • 将情景一分为二，分别表示在当前冲刺 (sprint) 中已完成的工作和尚未完成的工作。 有关详细信息，请参阅复制或克隆故事、问题和其他工作项。
    • 将情景重新分配到可以完成工作的下一个冲刺 (sprint)。 当前冲刺 (sprint) 中所有未完成的情景对冲刺 (sprint) 速度的影响为零。

  • 确定如何处理已完成任务的剩余工时。 如果任务已完成，为剩余工时设置一个非零值就没有什么意义。 团队应决定如何处理这些情况，并考虑将已完成任务的剩余工时值设置为零。

查看未完成工作的冲刺 (sprint) 积压工作

若要确定未完成的工作，请查看冲刺 (sprint) 积压工作是否有仍处于“已提交”、“活动”、“正在进行”状态的工作。 结束冲刺 (sprint) 时的冲刺 (sprint) 积压工作的屏幕截图。

将未完成的用户情景和任务重新分配到未来的冲刺 (sprint)

在冲刺 (sprint) 积压工作中，选择 视图选项，然后选择计划。 将未完成的工作项拖放到下一个冲刺 (sprint)，或回到团队积压工作。

如下图所示，Fabrikam 团队积压工作对应于为团队设置的默认迭代路径。 请注意，如果默认值设置为 @CurrentIteration 宏，则在下一个冲刺 (sprint) 开始之前，该选择不会更改迭代路径。

已启用“计划”窗格的冲刺 (sprint) 积压工作的屏幕截图。

存档过去的冲刺 (sprint)

随着时间的推移，为项目定义的或分配给团队的冲刺 (sprint) 数量可能会增加。 若要最小化迭代路径的下拉菜单，项目管理员可以选择将过去的冲刺 (sprint) 移动到存档区域。 通过维护冲刺 (sprint) 分配，但将其移到不同的冲刺 (sprint) 节点下，可以保留所有工作项数据。 所有冲刺 (sprint) 图表和小组件将继续工作。

如下图所示，2012 年和 2013 年的冲刺 (sprint) 已被移动到之前的冲刺节点下。

存档在“之前的冲刺 (sprint)”节点下的迭代路径的屏幕截图。

提示

存储在工作项中的所有数据均由 Azure DevOps 维护，直到工作项被永久删除。

冲刺 (sprint) 安全机制建议

冲刺 (sprint) 积压工作根据开始日期和结束日期自动指向当前冲刺 (sprint) 作为活动冲刺 (sprint)。 如果当前日期在冲刺 (sprint) 期内，则对应的冲刺 (sprint) 是当前冲刺 (sprint)。 无需执行进一步操作即可使下一个冲刺 (sprint) 成为活动的当前冲刺 (sprint)。

项目或团队管理员需要确保遵循以下指南来管理冲刺 (sprint)。

  • 为项目的冲刺 (sprint) 定义的开始日期和结束日期不应重叠。
  • 应为该团队的配置选择团队所有感兴趣的冲刺 (sprint)。
  • 应为项目定义几个未来的冲刺 (sprint)，并为团队做出选择。

有关详细信息，请参阅定义迭代路径（冲刺）和配置团队迭代。