敏捷估算︱一文深度剖析故事点估算

我在辅导团队对用户故事进行故事点估算的时候，经常会遇到如下问题：
用户故事的工作量估算为什么要用故事点，而不是时间？
故事点估算为什么要用斐波那契数列？
斐波那契数列的数字为什么被改了？
为什么要用估算扑克？
为什么要有基准故事？
怎样确定基准故事？
其他故事怎样与基准故事做相对估算？
……
我在翻阅了大量零散的资料以后，终于把这些问题搞清楚了。如果你也遇到过类似上述的问题，可以花点时间阅读下这篇文章，相信不会让你失望的。
 
1. 为什么用故事点而不是时间
 
在回答这个问题之前，我们先看个例子：韩梅梅和李雷一起去北京奥林匹克森林公园跑步，李雷对韩梅梅说：我们跑南园这条路吧，这大概要花30分钟。这条路韩梅梅很熟，但是作为一个跑步很慢的人，韩梅梅心里清楚这要花60分钟。所以，韩梅梅告诉李雷，她跑过这条路的，需要花60分钟。然后他们就争执起来了：30-60-30-60……他们争执半天没有结果，作为一个热心的旁观者，你可能会劝他们互相妥协一下，就算45分钟吧？但是这样也许是最坏的结果，因为他们虽然有了一个折中的方案，但是这个结果对双方都不太实际：李雷觉得太慢了，而韩梅梅觉得太快了。所以，他们继续争论：30-60-30-60……最终，李雷跟韩梅梅说：南园这条路大概5km，我能在30分钟内跑完它。韩梅梅说：我同意这段路程是5km，但它要花我60分钟。他们两个都是对的：李雷真的能在30分钟内跑完，韩梅梅也真的需要60分钟。但当他们想为这段路程统一时间估算时，他们发现做不到，因为大家跑步的速率不同。但是，当他们使用了一个抽象的长度度量单位（km），他们很快就达成了一致。李雷和韩梅梅都同意这段路程是5公里，但是由于他们的速度（相对度量单位）不同，导致他们花费的时间（绝对度量单位）也不同。例子说完了，很多人这时候可能已经想到了一个公式：距离（km）=速度（km/h）*时间（h），那我为什么要举这个例子呢？难道只是带大家回忆一下小学数学？其实软件开发中任务的工作量跟跑步的“距离”是非常类似的概念：同一个任务，不管谁来做，它的工作量都是一样的，只不过能力强的人就做得快一点（耗时少）；能力弱的人就做得慢一点（耗时多）。与跑步类似，如果我们让多个人就同一个开发任务的耗时达成一致，那是很难的，但是如果我们能有一个描述软件开发工作量的单位（类似表示举例的km），我们可能就能很快达成一致。而“故事点”就是敏捷开发创造出来的用来表示开发任务工作量的单位，它跟例子中用来表示距离单位的“km”的作用差不多：它能使不同技术水平和工作速率的人在工作量的估算上快速达成一致。当然，敏捷开发的主角是具有不同工作效率的开发人员，而不是例子中不同跑步速度的跑者。


就像这两个跑步的人，两个程序员也许同意一个用户故事是5个故事点（类比例子中的5公里，都是一种抽象度量单位）。高级开发人员可能觉得这很容易，1天（时间）就能完成。初级开发人员可能觉得需要2天才能搞定。但是他们能在5个故事点上快速达成一致，因为把第一个用户故事定成5个故事点是不需要什么依据的（就像不同国家或地区对长度单位的定义可能不同，比如米、寸、英寸等，每个团队对故事点的大小也都可以有自己的标准，只要团队成员都认可即可）。

不过，最重要的是，一旦他们同意第一个故事的工作量是5个点，这两个开发人员就可以对后续估算达成共识。如果高级开发人员认为一个新的用户故事将需要两天（两倍于他估计为5个点的故事），他将评估新的故事为10个点。而初级开发人员也会这样做，当他估算需要4个工作日时（两倍于他估计为5个点的故事），他将评估新的故事为10个点。所以，使用故事点而不使用时间的原因是，故事点可以使能力不同的开发人员在估算同一任务时快速达成一致。
 
2. 为什么要用斐波那契数列估算故事点
 
2.1. 人们无法分辨太小的差异
德国生理学家E.H.韦伯通过对重量差别感觉的研究发现一条定律，即感觉的差别阈限随原来刺激量的变化而变化，而且表现为一定的规律性，刺激的增量(△I)和原来刺激值(I)的比是一个常数(K)，用公式表达即K=△I/I，这个常数叫韦伯常数、韦伯分数或韦伯比率。上面的定义是从百度百科拷贝下来的，简单来说就是：我们只能分辨出两个物体间一定百分比外的差异。