提示：本文共有 1141 个字，阅读大概需要 3 分钟。
前两篇文章介绍的是 搜集故事和编写估算，本篇文章接着前面的文章往下说，有了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个故事点的故事之间。 如果上面的三角测量的结果不对，团队就应该重新估算。五、结对编程对故事点的影响
如果使用结对编程，故事点的估算应该是结对后进行的估算小结
用故事点估算故事，故事点是故事复杂度，工作量或工期的相对估算 应由团队进行估算故事，估算属于团队而不是个人 听过其他估算进行比较做三角测量 团队是否使用结对编程对故事点估算没有影响，结对编程影响的是团队的速率，不是他们的估算开发人员的职责
负责用一个方式定义故事点，并且对团队可用和相关的，努力保证这个定义是一致性 负责给出诚实的估算，不屈服于诱惑活压力而给出低的估算 负责以团队估算 负责估算应与其他估算一致，即所有相同故事点的故事的大小都是差不多的客户职责
参与估算会议，回答问题和澄清故事细节。
看到此处说明本文对你还是有帮助的，关于“敏捷开发三”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
