速度/容量图

Question

速度是一个常见的指标，这一点很清楚。

令我困惑的是，速度本身并不是什么，因为速度直接随着团队的能力而变化，人们休息几天，生病，团队成长和收缩……为了获得有用的指示器，您应该测量速度与容量，以获得如下内容：

你可以从一个容量中得到10个故事点

这样你就可以：

1. 计算下一个sprint的交付。你有X的能力，你可能会交付Y。
2. 随着时间的推移监控价值，因为它的波动意味着团队中正在发生的事情。

这是一个共同的指标，如果不是，人们只是监测速度，为什么它不是一个问题？

Answer 1

这里有一个有效的点:速度取决于团队上下文。更准确地说，速度是基于已完成的故事计算的，而故事要点是根据其提供可比故事的能力来估算由团队的，因此受到共享经验的影响。

如果你增加了团队的能力，你可以在最好的情况下立即提高速度。但是由于它是关于团队合作的，而且至少有一些事情必须一起做，所以增长永远不会成比例。嘿!这是软件，不是工厂的工作:-)

无论何时添加或移除团队中的人员，都会发生什么，即团队动态:团队将适应其新的配置，通过某种形成、风暴、规范和表演并动态地进行调整。也许，由于摩擦或学习新团队同事的时间，速度最初甚至会降低。也许团队会从它的新表现中吸取教训，并对其进行稍微不同的估计。

在几次迭代中，速度会发生变化，它将围绕一个新的速度稳定下来，这是团队的新常态。

Edit__：即使你保持同一个团队，而且有些成员不在，你也不能轻易地推断出你的能力。当然，如果团队中的大多数人都得到了几天的休假，你可以按比例近似预期的速度。但是，如果有几个人生病了，那么速度将在很大程度上取决于团队结构和剩下的技能(例如，如果您只有一个专用于UI前端开发的开发人员，而这个人生病了，则由于瓶颈，您的速度会按比例下降，除非您有许多不需要这些特定技能的待办项目。

Answer 2

速度是衡量一个团队在一段时间内完成了多少工作。它相当于一辆车的速度，它告诉你车辆每单位时间的距离。车辆的速度不能告诉你车辆的载量或载量，团队的速度不会告诉你团队能做的最大工作量是什么，或者负荷是否随着时间的变化而变化。

速度的变化不仅仅是团队的能力。过程和工具也会改变速度。敏捷软件开发的原则之一是定期反思团队的有效性和调整，以最大限度地提高效率。这些调整会影响速度。通过这些变化，团队可能会随着时间的推移而增加其最大容量。如果发生这种情况，即使能力降低，团队也有可能保持稳定的速度。

将工作时间有效地分解为多少，并不能完全解决团队完成工作的能力。除了敏捷团队应该定期进行的过程更改之外，您还需要考虑团队的动态、工具和基础设施，以及在团队面前完成工作所需的技能。对其中任何一项的更改都可能影响团队执行其工作的能力。

然而，对于了解速度的团队来说，这些问题并不常见。速度，不管它是如何测量的，确实给了你一个很好的数值，可以随着时间的推移绘制出来。这只是故事的开始。另一层将是昨天天气，或查看滚动平均迭代的平均速度。昨天的天气可以缓和一些关于假期或病假的一次性变化。然而，下一层并不是定量的，而是定性地理解了为什么速度发生了变化--查看团队组成的变化、更改过程、对上下文的更改或其他什么。有效使用速度的团队确实使用了这些定性的特性。

Answer 3

所以速比(由scrum定义)是一个sprint中完成点数的总数。

所以让我们拆开它。通过估算所需的努力(如:总时间)，这些要点是逐个故事分配的。因此，这些点本身就是一个前瞻性方向上的time单元。

冲刺本身就是一段时间。它所涵盖的工作日总数。因此，再次time单位。

所以它有time/time的维数--它只是一个无单位的比率。当然，它只是一个大分子单独显示，但它是每冲刺，这是分母。

所以我们能说的是:这不是速度。

速度是distance/time单位中的一个矢量。它甚至不是速度，它只是一个单位价值的distance/time。

您正在使用的这个无单位比率没有什么价值。它可以：

• 给人们留下这样的印象:我们在以最快的速度移动，因为你知道速度，看看这个数字有多大。当分母被隐藏时，它看起来更大。
• 揭示出你的团队对他们能做的工作量是多么的悲观。记住，更高的价值观意味着他们认为自己能完成的事情比他们的履历要少。

充其量，这是一个时间值，用于粗略地将对一组工作项的时间估计转换为该组的预算时间。

它是粗糙的，因为它是一个点梯度。对于复杂性、不确定性、能力和协调的每一个变化表面上的任何其他点，它都没有提到时间prediction of time/time taken。

这大概是因为平均定律和大数定律。你实际上是在做费米估计。问题是费米估计的质量越高，其中的术语越多，而且通常精确到一个数量级。你受工作项目数量的限制，你拥有的工作项目越多越好。但是，即使你真的能把这些项目推到高的数字，你仍然有一个准确性，高兴地接受1冲刺和99冲刺之间的差别，因为它是一个数量级的，有利于黄金。哦，还有很多时间花在估计上，而不是工作上。

如果这个值能够在多个sprint中保持相似，并且这些sprint大体上是相似的，那么您已经找到了一个局部一致的表面。如果你是在同一个邻里，并且假设它的局部一致，那么你可以非常准确地使用这个数字。

看看Joel on Software:基于证据的调度，了解一些关于估计交付的更好的想法。