第8章 估算用户故事

第8章 估算用户故事
故事点
可以用户理想日作为故事点的单位：相较于用连续时间估算，它更简单；相较于用完全模糊单位，它可使我们的估算拥有更好的依据。
以团队估算
客户和产品经理可以参加，但他不能提出他个人的估算或者在听到自己不赞成的估算时发表意见。
估算
Wideband Delphi方法，与采用迭代方式进行开发软件的极限编程类似。
目的是要为故事得到一个统一的估算值。这个迭代过程很少超过3轮。
三角测量
帮助团队验证他们没有逐渐改变一个故事点含义的有效方法，不过可以不是特别精确。
使用故事点
我们用“速率”（velocity）来代表一个团队在一轮迭代中完成（或期望完成）的故事点数。因此，务必保证每次迭代的故事点的度量是一致的。
如果用结对编程呢？
团队用不用结对编程，对故事点估算并没有影响。团队可以采用理想结对日或理想个人日来估算故事点，区别会表现在速率值上。
一些提醒
一个故事（可能是一个史诗故事）分解成一些小故事后，这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等。
类似地，一个故事分解成一些任务。这些任务估算的总和不需要与故事的估算相等。
开发人员职责
1.负责用一个方式定义故事点，并且对团队可用和相关的。努力保证这个定义的一致性。
2.负责给出诚实的估算。不屈服于诱惑或压力而给出低的估算。
3.负责以团队估算。
4.负责估算应与其他估算一致。即所有2点的故事都应该差不多。
客户职责
负责参加估算会议，但是你的任务是回答问题并澄清故事细节。你不必参与故事估算。