可爱的游戏-用户故事估计小窍门

easthomeRT

用户故事是通过故事点（Story Point）方式来估计其工作量的。每个故事点可以是一个理想日，理想日是说在一天中没有任何干扰（没有会议，没有电子邮件，没有电话），开发人员全身心投入工作的情况。其实，故事点作为工作复杂度的度量单位，还可以有很多种计量方法，比如可以设定一个典型用户故事的工作量为一个故事点，其他用户故事的工作量和这个典型故事的工作量进行比较得出自己可能的故事点。因此，我们可以认为故事点是一个模糊单位(NUT，Nebulous Units of Time),有一种数学形式就叫模糊数学吗，看来是异曲同工的学问。

      用户故事的工作量估算是由团队集体完成的。这有两个原因，第一，在启动估算的时候，还不确定团队中由随负责完成这个用户故事；第二，团队估计更相对科学和准确。

      以下是基本的估算方法：

      

      1、扑克牌游戏估算

      团队应用带有裴波那契数列的扑克牌来进行估算，该数列预设的值为1/2,1,2,3,5,8,13,20,40,80。也就是后边的数是前边2个数之和。数值为1可以认为是一个故事点。在估算时，每个团队成员都有一套这样的扑克牌，在主持人引导下，团队成员可以基于每个用户故事一起出牌亮出自己的估算结果。在所有估算结果中，识别出估算工作量最小的和最大的团队成员，分别请他们讲解各自的估算理由。然后进入下一轮的估算，直到50%以上的人达成基本一直的意见后再开始估算下一个用户故事。

     2、卡片方式估算（宽频Delphi）

      客户参与该估算过程，团队成员每人有一些用来记录估算值的空卡片。客户随机抽取一个用户故事，读给开发人员听。开发人员根据需要尽可能多发问，客户要尽其所能解答。直到没有任何其他疑问，每个开发人员需要在卡上写下一个估算值。大家都写好估算值后，所有人翻开他们的卡片或拿起来展示给所有人看。估算值最高的和最低的需要解释估算依据。再进行下一轮的估算，直到意见基本一致，最好估算的轮数不要超过三轮，不用过于要求精确。

      估算的目的之一是知道整个项目的工作量，所以我们还需要将故事点换算成时间或人天。在每次做冲刺或迭代计划时，会把故事点细化为具体的任务项，任务项会分给某个团队成员。每个任务项就会带有具体的人天，以及计划开始和完成时间的要求。团队成员对具体的任务项的完成时间达成必要的承诺。

本文出自东方瑞通刘通老师，转载请注明！

更多行业干货、技术文章，请关注公众号：东方瑞通IT培训（easthome_1998）