敏捷度量:速度

敏捷度量旨在服务于特定的目的，如果适当地加以利用，可以非常有用。在这个系列中，我想分享我的经验，关于在组织中如何使用、滥用度量标准，以及如何有效地成为敏捷采用失败的焦点。

速度是Scrum团队在Sprint期间将产品待办事项转化为产品增量的平均数量的指示，由开发团队跟踪以供Scrum团队内部使用。没有所谓的好速度或坏速度。记住，它是基于相对估计的。让我们通过一些例子来理解一个强大的速度指标是如何从好、到坏、到丑。

优点:随着其他输入，如团队能力，先前的承诺，Velocity帮助开发团队决定他们可以为当前Sprint预测多少产品Backlog项。Velocity还帮助产品负责人评估团队完成待办事项的速度，因为报告在几个迭代中跟踪预测和完成的工作。产品负责人可以根据开发团队的速度变化来修改预测的交付时间表。

当Scrum团队自己使用速度来了解他们的进度、他们的优势以及他们如何在一个又一个Sprint中改进时，速度绝对是一个很棒的度量标准。如果Scrum团队之外的人将速度用于任何其他目的，可能会很快导致这个指标被滥用，并使其变得糟糕。

缺点:曾经有领导问过我这样的问题，“如果两个团队拥有相似的技能集，他们的速度不应该相似吗?”，“团队A的速度是团队B的2倍——为了更快地交付，团队A不应该处理剩余的产品待办事项吗?”这促使我向他们解释，每个团队都将使用他们的内部共识来估计手头任务的大小。由于这两个团队的参考点不同，这种努力的规模可能因团队而异。团队A的任务“X”的规模可能比团队B的更大，因为前者可能用于将工作分成更小的规模，从而导致“更大的”估计。这可能会使团队A的速度看起来比团队B的速度高。

利用速度进行这种比较不会产生任何好处。事实上，这样的比较会让团队感到非常不舒服，因为他们很快就会明白，领导者是在用这种衡量标准来衡量整个团队，甚至可能是他们个人的生产力。

丑:当领导决定使用速度的改进作为衡量开发团队表现的一种方法，并且团队开始意识到这一点时，事情就会变得丑陋的．现在开发团队将开始捏造PBI /任务的大小来“膨胀”他们的速度，只是为了确保他们看起来达到(甚至可能超过)他们的目标速度。此时此刻透明度将不再存在于团队中，确保机械的Scrum实施会导致次优的指标和交付。

总之，速度是一个结果，而不是一个愿望。对于Scrum团队来说，速度是一个很好的度量标准，可以利用它来实现持续改进的内部目标。一旦这个指标被用于任何其他目的，团队和组织就会失去Scrum所提供的好处。这将导致整个组织陷入零和游戏，他们将失去对敏捷目标的关注。

参考文献- - - - - -

面向从业者的Scrum洞察——多石仁人

来源://www.aspasp2011.com/Resources/Scrum-Glossary