敏捷项目管理中的Scrum速度是什么？| 敏捷项目管理详解

速度是一种非常简单但强大的方法，可以准确衡量敏捷开发团队随时间交付业务价值的速度。它提供了团队在每个迭代中平均完成工作量的参考。产品待办事项列表在每个冲刺由一个敏捷团队，开发团队使用跟踪。因此，要计算敏捷团队的速度，只需将迭代中成功交付的功能、用户故事、需求或待办事项的估算值相加即可。团队应：

敏捷速度示例

在完成几个迭代之前，有一些简单的指导原则可用于估算敏捷团队的初始速度，但之后，团队可以使用经过验证的历史速度估算方法来进行冲刺计划。基于一系列过去的冲刺，速度估算通常趋于稳定，为提高敏捷项目的短期和长期规划准确性提供了更可靠的依据。

注意：

速度衡量的是团队在一个冲刺中能够完成的工作量，是敏捷中的关键指标。它通过在冲刺结束时将所有完全完成的用户故事的点数相加来计算。部分完成或未完成的故事的点数不应计入计算。

步骤1 – 计算第一个迭代（冲刺）的速度

在每个迭代结束时，团队将该迭代中完成的用户故事所关联的努力估算值相加。这个总和被称为速度。

一个敏捷团队已开始一个迭代，计划完成故事A（估算为2点）和故事B（估算为2点），以及故事C（估算为3点）。在迭代结束时，故事A和故事B已完成100%，但故事C仅完成80%。敏捷团队通常只认可两种完成状态：0%或100%。因此，故事C不计入速度，本次迭代的速度为4点。

步骤2 – 使用速度来估算所需迭代次数

在理解步骤1中的速度后，团队可以根据剩余用户故事的估算值，计算（或修订）完成项目所需的时间，前提是未来迭代中的速度大致保持不变。这通常是一个准确的预测，尽管很少能完全精确。

假设剩余的用户故事总共代表40点，团队对剩余工作的预测是10个迭代。

用户故事点数用于衡量规模和复杂性——本质上是完成一项任务所需的时间。用户故事点数是完成一个用户故事所需时间的相对度量。这一概念源自极限编程（XP）。它们用于评估故事的难度，而不是承诺完成所需的时间。这使得你可以根据团队规模或任务类型灵活使用用户故事点数。

如何将速度与故事点联系起来？

故事点是一种相对度量单位。团队应采取的第一步是确定一个故事作为基准，以便根据这个参考来估算其他故事。根据文献建议，团队应识别待办事项列表中最简单的故事，并将其分配为1个故事点，然后以此故事作为基准来估算其他故事。

用于创建故事点估算的有两种量表：

最好先估算团队熟悉且知道完成所需时间的第一个用户故事。然后估算下一个用户故事。如果团队认为它所需时间少于基准故事，就将其放在基准的左侧。再估算另一个用户故事。如果团队认为它所需时间少于基准但多于第二个故事，就将其放在基准和第二个故事之间。在这个例子中，我们使用斐波那契数列来进行故事估算：

用户故事故事点

在Scrum中，速度有助于你了解团队完成产品待办事项列表所需的时间。然而，通常需要经过几个冲刺后，团队才能找到更稳定的速度。为了更准确地估算团队的速度，我们可以参考团队过去的跟踪记录。这将更准确地预测团队在一个冲刺中能完成多少个故事。在进行预测时，应使用最近三到四个冲刺速度的平均值。

假设一个新Scrum团队计划在第一个冲刺中完成41个故事点，但最终只完成了38个故事点，并将6个故事点结转到下一个冲刺。因此他们的速度是38，如下所示：

Scrum速度

如前所述，团队不应将任何部分完成的工作计入速度。只有标记为“已完成”的用户故事才被计入，即使任务仅剩一小部分。

基于单个冲刺的速度并不是一个非常可靠的预测指标。（但它确实有助于团队了解在一个冲刺中能承诺多少工作。）让我们继续跟踪他们在后续冲刺中的进展。

现在，新团队从冲刺1持续开发到冲刺4。每个冲刺完成的故事点数分别为：38、29、38和39。四个冲刺后的平均速度为36，如下所示：

冲刺中的Scrum速度

基于四个冲刺的这个平均值，远比仅一个冲刺的快照更有用。可以很容易想象，如果待办事项列表中已有用户故事被估算过，我们就可以用这个速度进行预测。我们可以预测团队完成所有工作的速度，并对下一次发布能交付哪些功能做出有根据的猜测。

如果Scrum团队已完成多个冲刺，团队可以使用速度报告来预测发布和产品完成日期，并更好地规划未来项目。根据报告中显示的以往冲刺的速度，你可以实现以下目标：

根据上述示例，速度图显示了Scrum团队在四个冲刺中每个冲刺完成的工作量：

Scrum速度图