前两篇文章介绍的是 搜集故事和编写估算，本篇文章接着前面的文章往下说，有了story（故事）之后如果对故事进行估算

     下面主要是进行估算的大体checkLists

      对与一个故事的估算方法应该具有如下特点

       1、运行改变估算结果

       2、适用于所有的故事

       3、很容易很简单的进行估算，不需要花费太多时间

       4、提供进度和剩余工作的主要信息

       5、计算不准确也不会有大问题

       6、估算的结果可以用来指定发布计划

一、以故事点的形式进行估算

       故事点估算可以很好的满足上面的特点的估算方法。团队可以自定义合适的故事点，我们组内偏好把一个完美工作日作为一个故事点进行故事估算。

       完美工作日就是理想工作日，一天8个小时内一直在编码没有任何其他的情况。当然现实情况可能不太相同.所以一个完美工作日！=一天

二、以团队估算

      故事点应该是由整个团队进行估算，团队中的大部分成员都要参与故事的故事点估算，每个人都把自己的估算结果说出来，最后大家再定一个所有人都认可的故事点

三、如何进行估算

     1、所有参与的客户和开发人员聚在一起

     2、从第一个故事开始，详细讲解故事直到所有的人都清楚了解这个故事

     3、每个开发人员都先写下自己估算的值，一故事点为单位 ，例如 2完美工作日(2天)

     4、大家都展现自己的估算，然后每个人都说一下为什么估算出这个值

     5、最后经过论证团队估算出一个所有人都认可的值

     6、继续下一个故事的估算

      有了解SCRUM的朋友应该可以感受到上面的流程基本上和SCRUM估算故事的流程是一样的.

四、对评估的结果做三角测量

     在做了几个估算以后，对估算结果做三角测量，具体做法如下

     在估算一个故事时，根据这个故事与其他一个或多个故事的关系来估算，假定一个故事估算为4个故事点，第二个故事为2个故事点，把这2个故事放在一起考虑的时候，程序员都应该认可 4个故事点的故事是2个故事点的故事的2倍

     其他3个故事点的故事的大小应该介于4个故事点的故事和2个故事点的故事之间。

     如果上面的三角测量的结果不对，团队就应该重新估算。

五、结对编程对故事点的影响

      如果使用结对编程，故事点的估算应该是结对后进行的估算

小结

     用故事点估算故事，故事点是故事复杂度，工作量或工期的相对估算

     应由团队进行估算故事，估算属于团队而不是个人

     听过其他估算进行比较做三角测量

     团队是否使用结对编程对故事点估算没有影响，结对编程影响的是团队的速率，不是他们的估算

开发人员的职责

     负责用一个方式定义故事点，并且对团队可用和相关的，努力保证这个定义是一致性

     负责给出诚实的估算，不屈服于诱惑活压力而给出低的估算

     负责以团队估算

     负责估算应与其他估算一致，即所有相同故事点的故事的大小都是差不多的

客户职责

      参与估算会议，回答问题和澄清故事细节。