在敏捷团队中，我对速度存在很多困惑。 太多的人把速度当作加速度的量度。 也就是说，他们希望速度稳定地增加到一定数量。 速度是变化率与方向的结合。 当经理们认为他们可以用速度来衡量团队时，他们会将速度与加速度相混淆。
当我进入高速公路时，我的加速度更高。 当我继续驾驶时，我会达到稳定的状态：进入车道并保持恒定的速度。 （嗯，很幸运。）我对道路保持稳定（我的方向）。 我的速度保持不变-特别是当我使用巡航控制系统时。 以合理的速度（可能会随流量的变化而有所变化），我可以到达目的地。
关于方向的说明：我住在道路弯曲的波士顿地区。 北，南，东和西对其他人有用。 我们有从字面上指向南方的高速公路，其名称为“北方”。 他们弯曲。 我觉得这些指示没有用。 我更可能谈论高速公路上的出口号或小路上的加油站。 方向和速度一样，都取决于环境。
项目的方向更多地是关于完成功能。 您离“完成”有多近？ 下面的更多内容。 当管理人员尝试使用速度作为加速度时，他们会创建计划游戏。 请参阅速度加倍 。 这通常导致人们走捷径并招致技术债务。 您可以使用什么代替速度？ 功能燃尽/燃尽图和产品积压燃尽图。
此图表是功能部件燃尽图的示例。
您可以绘制特征总数（在顶部摆动的绿色线），特征完成（燃烧的红色线继续增加）和剩余特征（燃烧的蓝色，向下的线）的总数。 我喜欢这张图表，因为您可以查看项目期间情况是否有些“怪异”。
如果添加太多功能的速度超过了团队完成功能的速度，则绿线和红线之间将有很大的差距。 蓝线将上升。 这张图向您显示。 您可以看到该项目的完成情况。 我也喜欢产品积压的燃尽图。 这显示一个团队（或多个团队）在所有功能集上取得了多少进展。 （这有助于人们意识到应该定义功能集。功能集可帮助团队了解产品的发展方向。）
在此图表中，团队使用功能集1（FS 1）和功能集2（FS 2）。 这些故事比功能集3中的任何内容都更有价值。
产品积压燃尽图（多次迭代/里程碑）
您可以看到功能集2在第5个里程碑/迭代的故事数量上有所增加。 这也有助于人们理解何时可以期望该项目完成。
测量速度可以帮助团队了解正在发生的事情。 请参见燃尽图和燃尽图的值 。 但是，速度是一支团队的力量。 速度可以帮助团队在一段时间内了解其背景。 他们可以决定如何显示它以及如何处理它。 如果管理层希望看到进度，则团队可以衡量功能的完整，剩余，总图表和产品积压消耗图表。 （我还将测量累积流量以查看团队正在进行的工作量。）不要测量速度以查看进度。 那不是您想要或需要的度量。
翻译自: https://www.javacodegeeks.com/2016/05/velocity-not-acceleration.html