2.6 故事点估算方法

故事点是用来表述一个用户故事、一项功能或一件工作整体大小的一种度量单位。当使用故事点进行估算时，我们为待估算的每一项设定一个数值。这个值本身的数字并不重要，重要的是这些故事点之间通过各自数值对比体现的相对大小。例如，一个被赋予2的用户故事，其大小应当是一个被赋予1的用户故事的两倍。

故事点具备以下两个关键特性：

（1）故事点是一个相对单位。例如，不同团队对于同一个用户故事的故事点估算的大小是不一致的。

（2）故事点估算不是简单地等同于工作量估算，它包含工作量、技术含量等多方面价值因素。有时，其他因素在故事点估算中占的比重会超过工作量的。

在敏捷开发中，使用故事点进行估算的典型的方法是计划扑克（Planning Poker）估算方法。另一种更新的估算方法——敏捷估算2.0（Agile Estimating 2.0），也正被越来越多的敏捷开发团队采用。

计划扑克估算方法由James Grenning在2002年首次提出，该方法集合了专家意见（Expert Opinion）、类比（Analogy）及分解（Disaggregation）这3种常用的估算方法，能使团队通过一个愉快的过程快速而准确地得出估算结果。

计划扑克的参与者是团队的所有成员。采用计划扑克估算时，每个参与估算的组员都会得到一副计划扑克，每一张牌上写有一个Fibonacci数列的数字（典型的计划扑克由13张牌组成：？，0，，1，2，3，5，8，13，20，40，100，∞。其中，“？”代表信息不够而无法估算，“∞”代表该用户故事信息量太大）。计划扑克估算方法步骤如下：

（1）对一个用户故事进行估算时，首先由产品负责人描述这个用户故事。过程中产品负责人回答组员任何关于该用户故事的问题。展开讨论时主持人应注意控制时间与细节程度，只要团队觉得对用户故事信息已经了解足够可以进行估算了，就应当中止讨论，开始估算。

（2）所有问题都被澄清后，每一个组员从扑克中挑选他/她觉得可以表达这个用户故事大小的一张牌，但是不亮牌，也不让别的组员知道自己的分值。所有人都准备好后，主持人发口令让所有人同时亮牌，并保证每个人的估算值都可以被其他人清楚地看到。

（3）当出现很多不同分值的时候，评分最高的人和评分最低的人需要向整个团队解释评分的依据（主持人需要注意控制会议氛围，避免出现意见不一导致的攻击性言论）。所有的讨论应集中于评分者的想法是否值得团队其他成员进行更深入的思考。

（4）随后全组可以针对这些想法进行几分钟的自由讨论。讨论之后，团队进行下一轮的全组估算。一般来说，很多用户故事在进行第二轮估算的时候就能得到一个全组认可的分值，但是如果不能达到全组意见一致，那就重复地进行下一轮讨论，直到得到统一结论为止。

计划扑克估算是应用最广泛的敏捷估算方法，但是有时候计划扑克玩起来耗费比较多的时间，尤其是在10个人左右的团队中。为了解决这个问题，产生了Agile Estimating 2.0估算技术。这个新的估算技术同样基于专家意见、类比和分解，同样使用Fibonacci数列，但是它可以显著地缩短会议时间。该方法步骤如下：

（1）由产品负责人向团队介绍每一个用户故事，确保所有需求相关的问题都在估算前得到解决。

（2）整个团队一起参与这个游戏。只有一个简单的游戏规则：一次仅由一个人将一个用户故事卡放在白板的合适位置：规模小的故事放在左边，规模大的放在右边，同样大的竖向排成一列。整个团队轮流移动用户故事卡，直到整个团队都认同白板上的用户故事卡的排序为止。

（3）团队将故事点分配给每个用户故事（列）。最简单的做法是使用投票来决定每个用户故事分配到哪一个Fibonacci数字。

（4）使用不同颜色来区分影响估算大小的不同方面，并且重新考虑是否需要修改估算值。例如，使用红色表示那些无法被自动化测试脚本覆盖的用户故事，因此，那些用户故事需要一个更大的数字来容纳手工回归测试的代价。