标签：
（多年前的笔记，从ITEYE迁移过来）
通过无限制头脑风暴、角色扮演、实地观察等需求获取手段得到了一系列定义良好的User Story之后，我们就要根据需求来评估整个开发过程需要的工作量了。
在这里我们用到了一个有意思的方法----Playing Poker Game，游戏是这样进行的 ：
游戏本身没有什么特别，主要是同这种方式使团队对User Story的理解达成一致，同时在游戏的过程中进一步澄清一些不清楚的地方，做出相对准确的估算。
如果所有的估算值都比较集中的话，就说明对于这个User Story的估算是相对精确的；如果估算值比较分散的话，就说明对于这个User Story的估算是不精确的。 要不就是团队成员对User Story的理解上存在偏差，要么就是有些假设没有得到澄清。首先要在对User Story 的理解上所有的成员达成一致。如果还不能进一步的缩小偏差的话，这时候就要回到客户那里，获取更多的关于该User Story的信息，直到获得更精确的估算，让我们对我们的估算有信心。对User Story的估算就是对客户的承诺，承诺在估算的时间内我们能够交付User Story所提供功能。
估算过长的User Story不是一个好的User Story。 如果一个User Story的估算过长，比如30天。那么该User Story就过于庞大，我们需要将其拆分为更小的几个User Story。这样我们的估算会更加精确，不会过大或过小。一般认为估算大于15天的User Story更容易估算失误，所以需要进行拆分。将所有的User Story估算开发时间相加就得到一个相对合理的项目开发评估时间。
认真对待我们估算时所做的每一个假设，在进行估算时没有一个假设是一个好的假设，理论上每一个假设都要从客户那里得到澄清并消除掉。 这是因为每一个假设都有可能是我们进行开发时的变数，在项目的进行中给我们致命的一击（假设错误或假设不存在）。当然我们不可能完全消除掉所有的假设，但是至少我们知道那些假设已经得到客户的澄清，那些假设需要我们时刻保持警惕。那些没有消除的假设就是我们项目所面临的风险。
最后，关于估算值集中成都如何选择，这完全取决于项目成员。同时也和项目成员对自己估算的信心如何有关。
深入浅出软件开发----（三）Playing Poker Game
标签：
原文地址：http://www.cnblogs.com/sunnyshuhai/p/5502226.html
