出色的速度

Buddha Buck 最近向 Extreme Programming 讨论组 提出 这样一个问题 ：对于由 7 个人构成、迭代持续两周的团队来说，是否存在一个“出色”的速度范围？在他看来，少于或等于 8 点的速度就表示团队的故事可能太大了。由此引发的讨论提供了一些答案，还揭示出问题背后的问题。

速度是用来预测团队未来工作效率的工具。如果团队在工作中涉及到的用户故事都是同样大小，也就是说要完成这些故事的工作量大致相同，我们就可以简单地计算团队每个迭代完成的故事数目。稳定的团队会倾向于在每个迭代中完成同样数目的这些大小相等的故事，并且管理层也会根据团队已知的能力来制定计划。

在很多情况下，故事的大小是不一样的。因此，故事都是估计出相对大小，经常称为“估算”。大小为 2 的故事就是大小为 1 的故事的两倍。大小为 3 的故事就是三倍，诸如此类。一般来说，如果估计大小为 2 的故事要花的时间是大小为 1 的故事的两倍，这也很正常。为了让这些估算更易于讨论，人们将故事大小的单位定为“点”，或称为“故事点”。因为，我们可以说完成 5 点的故事所需的时间是完成 1 点的故事的 5 倍。一般来看，稳定的团队会在每个迭代中完成固定点数的故事；这个点数就是团队的速度。因此，团队的能力决定了速度。速度可以衡量团队每个迭代中完成的工作量。

Steven E. Newton 这样描述“出色的”速度：“出色的速度可以用来准确预测在未来迭代中能够完成的工作量。”

Kent Beck 发现了另外一个了解团队速度的好处：

衡量能力的另外一个目的是要改善产出。如果你计划要完成的工作比实际能够完成的少，最后真正完成的也就少于实际可以做到的事情。如果你计划要完成的工作比实际能够完成的多，最后真正能够完成的同样也少于实际可以做到的事情。

Charlie Poole 提醒读者，开发人员喜欢思考实现故事需要多少工作量，而管理层和客户喜欢琢磨完成故事能够交付多少实际价值。大家都应该注意到：针对故事的估算和速度都与工作量大小、以及完成故事所用的时间有关。

Buddha 的问题表面上得到了答案，但是讨论组继续探讨问题背后的潜在议题。特别之处在于，Buddha 非常担心团队要完成的故事也许过大了。大家讨论认为小故事要比大故事更加值得采纳。

Tim Ottinger 指出小故事能够提供更频繁的里程碑，从而帮助团队与干系人总是可以了解到项目的实际进展情况。

很明显，没有哪个故事能够延续超过一个迭代的时间。想一想迭代中的故事，更大的故事总是更加不容易完成。没人希望自己处于要么完成 N 个点数，要么一个都不完成的境地。每个人都希望在迭代进行到一半的时候，有 40% 的故事点数已经完成了（我是指真正意义上的完成）。

Steven Gordon 分享了一些相关的指导方针：

• 如果不确定故事是否足够小，那几乎可以确定它们确实太大了。
• 如果故事太小了，团队会发现跟踪过小的故事会浪费很多管理成本。
• 故事太小所造成的问题，远没有故事太大造成的问题严重。所以如果要犯错，也建议倾向于让故事变得过小。
• 如果过小的故事是团队前进的最大障碍，那就应该恭喜团队：你们已经掌握了极限编程的要义。

Ron Jeffries 觉得，他希望看到一对程序员能够在一周内完成两到三个故事，这样的故事大小才是合适的。他对于故事点数的概念并不是特别在意：

我觉得整个的关注点有点过于偏移了，我也很后悔自己有些事情做得用力过度了。大家偏离了真正的重点，就是要将故事拆分得足够小，直到能够以大概相同的步调来完成它们。

您的团队是如何决定故事大小的？您是否认为团队的速度可以用来判断故事的大小是否没有问题？请在评论中提供您的想法。

查看英文原文： A Good Velocity