在非正式谈论它时，我将「速度」定义为衡量团队进展速度的一个指标。在大多数情况下，这个定义非常有效。然而，它会对计算scrum团队速度时应该考虑的一些细节产生混淆。这种混乱的出现是因为确实有两种更精确的速度定义方法。让我们看看它们是什么。
1）速度衡量团队在sprint中提供的功能。
2）速度衡量团队在sprint中将想法转化为新功能的能力。
听起来可能一样，然而它们略有不同。假设你跳进河里开始游泳。一小时后，你可以测量你游泳的距离——在距您开始的地方2公里。在敏捷方面，如果游泳冲刺是一小时，我们可能想要称之为你的速度，并说你每小时或每次冲刺游泳2公里。
但是，如果你游泳时，河流以每小时一公里的速度向你流动怎么办呢？在那种情况下，你真实游了3公里。根据河岸测量，你只移动了两公里的物理距离。但是在向前走两公里的路上，你克服了在河边一公里处被推倒的情况。
那么，你的速度是哪个？如果我们使用我们的第一个定义 - 速度是一个团队在冲刺中交付多少 - 那么速度就是2KM。这名游泳运动员取得了2公里的进步。
如果我们使用我们的第二个定义 - 速度是将想法转化为新功能的能力 - 那么速度就是3。这位游泳运动员有能力在每个冲刺中提供3公里的进度，我们会看到他在没有电流而不是河流的湖中游泳。
要了解这在敏捷项目是如何应用的，考虑一个问题，一个团队是否应该因为在冲刺期间因为「修复错误」而获得速度信用。使用速度来衡量sprint中提供的功能的团队不会因错误修复而获得奖励。没有提供新功能。所以没有积分。
另一方面，一个团队使用定义速度作为将想法转化为功能的能力，将声称错误修复是值得的。他们的逻辑是，花在修复bug上的时间可能是用来添加新功能的，除了产品所有者为他们优先安排不同的工作。
对于许多团队而言，这两个定义将产生相同的值。对于那些没有获得速度信用的团队来说，价值观差异最大 - 通常团队会做很多错误修复或进行大量重构。
在速度的定义上，这些细微的差异并不总是比另一个更好。你所使用的方法在很大程度上取决于你希望通过测量它来学习什么，以及你对未来的期望。
如果你期望未来和今天一样，也就是说，团队将花费与现在一样多的时间进行错误修复、重构等工作，那么使用速度作为衡量前进进度的指标将是你正确的答案。
但是，如果您期望未来会有所不同，那么大型重构和修复bug的时间将很快结束，那么您可能希望将Velocity定义为团队将想法转化为功能的能力，然后将这些活动的要点添加到Velocity中。
最重要的是与团队中的每个人（包括产品所有者和ScrumMaster）澄清，当他们使用“速度”这个术语时，您的团队想表达的什么意思。有了一个精确的定义，很容易回答在测量速度时应该算什么的问题。
