标准故事点

我最近听到了一些关于为使用极限编程规划方法的多个团队制定标准故事点机制的问题。希望多个团队都使用等效的故事点，这样在一个团队上的三个故事点的工作量就等于另一个团队上的三个故事点。

我认为尝试制定这种标准最多是价值有限，最坏的情况是危险的。

极限编程的估算系统基于XpVelocity和YesterdaysWeather。其中固有的理念是，当你进行估算时，你所估算的实际单位并不重要——重要的是你通过粗略的比较价值进行估算，并使用YesterdaysWeather进行校准。

在这种情况下，故事点充当昨天天气提供的反馈循环的锚点——仅此而已。它们包含了关于团队任务的性质、团队的能力以及团队是乐观还是悲观的估计者的各种假设。一旦你试图在团队之间制定一个标准，你就是在试图将所有这些因素标准化。在我看来，尝试这样做非常困难，而且我不知道有人能有效地做到这一点。这并不意味着它不可能，只是意味着它很难。

危险的一面来自于，一旦你有了跨团队的标准测量单位，就不可避免地会有人用它来比较团队的绩效。即使每个人都发誓说他们不会用它来进行跨团队的测量，但总会有人怀疑最终会发生这种情况。这会导致团队扭曲他们的测量结果，以使他们看起来完成了更多的故事点。我担心这会破坏昨天天气的反馈循环，并使规划过程偏离轨道。我总是对这些事情持怀疑态度，因为虽然能够衡量生产力将非常有价值，但我认为软件的本质是，我们无法衡量生产力.

因此，为了值得尝试，这必须产生一些有价值的益处——但我没有看到任何益处。我听到的一个原因是帮助人们更快地加入团队并进行估算。但是，你不能在加入一个新团队之前就进行估算，除非你对问题和当前代码库有相当程度的了解。当你这样做的时候，你也会对该团队故事点的相对大小有一个感觉。我们在Thoughtworks之间调动人员，我从未听说过有人抱怨由于故事点的差异而导致在新团队中估算困难。

2012年5月10日重新发布