故事点的主要好处

本文转自：Scrum 中文网

如果说故事点是对正在做的事情的时间（工作量）进行估计，那为什么不直接估算出要多少个小时或多少天呢？为什么要使用故事点呢？

使用故事点来估算产品 backlog 条目的原因有很多，我在敏捷估算和计划课程的视频中已经很充分地探讨过，但是，我今天想说的是，故事点本身就自带一个令人信服的理由。

这里得先说说国王亨利一世（公元 1100 年到 1135 年在位）。在他继位之前，“一码”这个计量单位是从一个人的鼻子到他伸出的大拇指间的距离。想象一下，每个人的这个距离都是不同的，这该有多混乱啊？

亨利一世最终确定“一码”就等于国王的鼻子到伸出的拇指之间的距离。这样，就有了一个标准的计量单位，即方便了国王自己，也方便了所有人。

你可能知道，一码比自己自己的胳膊要长点或短点。我也是。但还好，我们有一个共同的计量单位。

故事点数可以用这个故事进行类比。就像英国的度量单位“码”一样，它允许不同技术水准的团队成员能在沟通后得到一个估算值。比如你和我决定出去跑步。我喜欢跑步，但是我跑得很慢。而你，相反跑得很快。你指着一条跑步路线说：我们跑这条路吧，这大概要花 30 分钟。

这条路我很熟，但是作为一个比你跑的慢的人，我心里清楚这要花我 60 分钟。所以，我告诉你，我和你一起跑这条路，但是需要 60 分钟。

所以我们争执起来 30,60,30,60.

我们争执半天没有结果。也许我们可以妥协一下，需要 45 分钟?但是这也许是最坏的结果。因为我们虽然有了一个估算结果，但是，这个结果对大家都没什么好处。

所以，我们继续争论。30,60,30,60.

最终，你跟我说：Mike，这段路大概 5 英里，我能在 30 分钟内跑完它。

我说：我同意这段路程是 5 英里。但它要花我 60 分钟。

问题是我们两个都是对的。你真的能在 30 分钟内跑完，我也真的需要 60 分钟。当我们为这段路程加上时间估算，我们发现不能这样做，因为大家工作（跑步）的速率不同。

但是，当我们使用了一个抽象的度量衡–这个例子里是英里–我们就能达成一致。你和我都同意这段路程是 5 英里。我们仅仅在它要花费我们多长时间上意见不同。

故事点跟这差不多。它能使不同技术水平和工作速度的人在估算结果上保持一致。当然，这里的主角是具有不同产出率的程序员，而不是本例中跑得快的人和跑得慢的人。

就像这两个跑步的人，两个程序员也许同意一个用户故事是 5 个点（而不是 5 英里）。快一点的程序员可能觉得这很容易，1 天就能完成。那个慢点的程序员可能觉得需要 2 天才能搞定。但是他们能在 5 个故事点这一点上达成一致。因为把第一个用户故事定成 5 个故事点是不需要什么依据的。

不过，最重要的是，一旦他们同意第一个故事是 5 点，这两个程序员就可以达成后续的估计。如果快速程序员认为一个新的用户故事将需要两天（两倍于他估计为 5 点的故事），他将评估新的故事为 10 点。而另一个程序员也会这样做，当她需要四个工作日（两倍于她估计为 5 点的故事），她将评估新的故事为 10 点。

综上，就像定义了国王亨利的鼻子到他的拇指的距离，故事点的定义就能使不同速度的程序员在估算时能达成一致。