速率究竟有何用？

雅虎的 ScrumDevelopment 讨论组近日有个话题讨论速率的各种应用和误用。Kurt Häusler 描述了他对速率及其价值的理解:

嗨，速率是以上个迭代完成的故事点数来计算的。我不确定它是否适合做生产率指标。对我而言，它是一个中性的度量，作为一个工具，用来计算下个迭代该尝试多少故事点数。速率高低之于我，与好坏不一定相关。

但是速率是个很重要的工具，不过你得理解它的含义和作用；在我看来它就是用来计划下个迭代的，而非衡量生产率。

Kurt 也承认这并非关于速率的唯一观点，如在 Joe Little 的博客 中写道：

…不超过 6 个月内，我们将使团队的速率翻倍。

倍增速率（每轮冲刺完成的故事点数）通常意味着我们必须做如下改善： - 更清晰地定义完成（或者你更喜欢用“完成之完成”（“done-done”））。我们对“完成”的定义经常很模糊。对某些故事通融是必须的，但对大多数软件的用户故事来说，“完成”必须得到清晰、一致的定义。而我的观点是，完成就意味着“没有（已知的）缺陷溜出该轮冲刺”，而且测试必须至少包含功能测试。

• 必须测量速率。我发现好多团队都没有对速率的某种度量，这令人难以置信。以后我再展开讲，目前简而言之：“速率：走遍天下不可或缺。”
• 必须对障碍分优先级，并持续消除或减弱优先级最高的障碍，直到速率得到翻倍。提示：我们也许可以通过消除 / 减弱障碍所能获得的速率提升大小对他们进行分级。这里 25%，那里 30%；很快你就会发现速率的实际提升了。 提示：提升质量和减少技术债，这两点几乎总是重大速率提升的关键。不是唯一关键，但是极为重要。

Adam Sokra 同意 Kurt，也认为速率用来度量团队表现不太合适， 但是他认为速率应主要用于长远规划而非迭代计划。

用速率来度量表现是糟糕至极的做法，除非你的目的仅仅是要看到生产率如何随时间逐步稳定下来。人们习惯用速率来表达“上个迭代我们完成了 X 个点，所以这个迭代我们该尝试不多于 X 的点数”。但是我们中很多人已经开始相信，如此做出承诺的方法值得商榷。已经有人建议，我们只需承诺自认为每个迭代能够完成的工作量，这就够了。

速率用于长远规划最为合适。我可以看看我几个迭代的速率，提出一个平均值（区间值更好）。然后我就能用这一信息说出诸如：1) 考虑目前的待完成清单（backlog），还需要多少轮迭代才可能完成给定数量的故事？ 2）到日期 X 为止（比如要及时赶上贸易展），我能交付多少故事点数、以及哪些高优先级故事？

当然，还有不断增长的一个思想流派把计划看作是浪费行为 。

速率该被用作生产率指标吗？该被用于迭代计划吗？用于更长远发布的规划又怎样呢？它该被切实使用，还是只是浪费功夫呢？

查看英文原文： What is Velocity Good For?

译者简介：顾全，历史学科班出身，澳洲计算机硕士，工作于数据仓库行业多年。08 年 CSM 认证后成为 Agile 的坚决拥护者和热心传播者。

志愿参与 InfoQ 中文站内容建设，请邮件至 editors@cn.infoq.com 。也欢迎大家到 InfoQ 中文站用户讨论组参与我们的线上讨论。