开发管理 CheckLists(8) -敏捷开发-估算故事

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

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

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

1、运行改变估算结果

2、适用于所有的故事

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

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

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

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

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

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

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

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

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

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

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

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

          有了解SCRUM的朋友应该可以感受到上面的流程基本上和SCRUM估算故事的流程是一样的.四、对评估的结果做三角测量

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

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

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

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

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

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

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

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

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

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

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

负责以团队估算

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

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