深入浅出软件开发----（三）Playing Poker Game

      通过无限制头脑风暴、角色扮演、实地观察等需求获取手段得到了一系列定义良好的User Story之后，我们就要根据需求来评估整个开发过程需要的工作量了。

 

     在这里我们用到了一个有意思的方法----Playing Poker Game，游戏是这样进行的 ：

 

1. 将一个定义良好、描述清晰的User Story放到桌子中间
2. 参与估算的每一个成员给出一个完成User Story开发的估算时间，具体的可选时间可以预先定义一些常用的时间写到卡片 上，每一个人从自己的一套定义好的卡片中选择一张自己估算时间的卡片
3. 将估算卡片面朝下的放到桌子上
4. 翻开看片
5. 将估算值标注到一维坐标

      游戏本身没有什么特别，主要是同这种方式使团队对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估算开发时间相加就得到一个相对合理的项目开发评估时间。

 

     认真对待我们估算时所做的每一个假设，在进行估算时没有一个假设是一个好的假设，理论上每一个假设都要从客户那里得到澄清并消除掉。 这是因为每一个假设都有可能是我们进行开发时的变数，在项目的进行中给我们致命的一击（假设错误或假设不存在）。当然我们不可能完全消除掉所有的假设，但是至少我们知道那些假设已经得到客户的澄清，那些假设需要我们时刻保持警惕。那些没有消除的假设就是我们项目所面临的风险。

 

    最后，关于估算值集中成都如何选择，这完全取决于项目成员。同时也和项目成员对自己估算的信心如何有关。