（书摘：用户故事与敏捷方法）第八章 估算用户故事

小结：

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

    故事点有很好的特性是团队可以定义自己认为合适的故事点。一个团队可能决定定义一个故事点为一个理想日的工作。另一个团队可能定义一个故事点为一个理想周的工作。还有一个团队可能把故事点作为故事复杂度得测量。因为故事点有很多的意义，所以Joshua Kerievsky认为故事点代表事件的模糊单位，或叫NUT（Nebulous Units of Time）.

 

2.应由团队估算故事，估算属于团队而不是个人。

   故事估算属于团队集体有两个原因，第一，还不确定团队中谁负责完成这个故事，所以应该把故事分配给整个团队而不是个人。第二，团队决定的估算可能比个人估算更有用。

   估算步骤如下：

•    参与估算的客户和开发人员聚集在一起。客户抽取故事，读给开发人员听。客户尽可能给开发人员解释疑点。

•    对故事没有疑问后，每个开发人员在卡片上写下一个估算值。

•    大家都写好值后，所有人展示自己的卡片，给别人看。这时，估算值可能差别很大，估算值高的和低的再解释一下估算依据。

•    大家讨论

•    重新估算

   我们的目的是要为故事得到一个统一的估算值。这个过程很少会超过三轮，但是只要是估算值不断地接近一致，那我们就继续这个过程。没有必要让所有人到在卡片上写下完全一样的估算值。点数要合理，而不是绝对精确。

 

3.通过和其他估算进行比较来进行三角测量

   具体的做法就是在估算一个故事时，根据这个故事与其他一个活多个故事的关系来估算。假定一个故事的估算为4个故事点，一个为3个故事点，另外一个是2个故事点。把这三个故事放在一起考虑，程序员应该都同意4个点的故事大概是2个点故事的两倍。3个点的故事大概比两个点的故事大，比4个点的故事小。

   使用故事点，在一轮迭代结束后，可以作为下一个迭代认领故事点多少的依据。

 

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

 

一些提醒：

要正确使用故事点，请记住下面几点：

• 你的团队的故事点和我的团队的故事点是不一样的。你的团队估算的故事有3个故事点，可能我的团队估算有5个故事点。
• 一个故事（可能是一个史诗故事）分解成一些小故事后，这些小故事的总和不需要与开始那个故事或史诗故事的估算相等。
• 类似地，一个故事分解成一些任务。这些任务估算的总和不需要与故事的估算相等。

开发人员职责：

• 负责用一个方式定义故事点，并且对团队可用和相关的。努力保证这个定义的一致性。
• 负责给出诚实的估算。不屈服与诱惑或压力而给出低的估算。
• 负责以团队估算。
• 负责估算应与其他估算一致。即所有2点的故事都应差不多。

客户职责：

• 负责参与估算会议，但是你的任务是回答问题并澄清故事细节。你不必参与故事估算。