题记：
在一个Sprint开始的时候经常会对一个Story进行时间评估，这是件很让人头痛的事情， “他说的让我都不知道怎么说了，他每次都说几分钟搞定”，看着他一脸的无奈， “这么简单的问题，你给我搞20小时”，某人又在情绪化了，相信每个团队里面都有自己团队的故事。评估本身意义：关于评估时间是一个慢慢积累的过程，我们不可能一次把时间估的很对，但是我们期望我们估到时间与我们之间的生产力是相互接近的。下面是自己总结的评估时间方法与感触。
纸牌评估
1.具体到小时：团队里面可以具体到小时，操作流程
（1）需求人讲需求，参加会议的人员进行提问，需求人员进行回答
需求人在讲需求的时候这是个最关键的时候，如果要修改一个旧的业务，一定要问句“新的需求的意义”，原来为什么满足不了，新需求的改动量有多大？这样个新的需求会波动其他模块吗？改的话是否会对历史数据有影响？历史数据如何处理？这个需求要做到话，我的改那些数据库表结构？数据从那边来（或者要从另个系统读取数据）？不懂尽可能要提出来，否则的话你是没法评估时间的。如果需求问题不多，会直接现场跟客户沟通，如果很多没法解决，最好的办法是停掉需求，换新需求，这个时候通过大家的讨论，基本上能定义出来要做个什么东西，我们需要做什么，来完成用户的需求
（2）参与迭代开发的人员进行评估，并且自己的方案
你应该已经明白需求的意义了，这时候要估出自己工作时间，也许是1小时，或者20小时，你需要在自己纸条上写上自己预估的时间（每个人跟每个人是不一样的），这时候也许会出现很大区别，你也许是3小时，而别人有可能是20小时，这时候每个人需要说出自己的方案，（或者你之前做过，或者直接调用第三方插件），给他们更好的指导
（3）如果时间相差太大，再次（2）
循化（2），如果还是出现很大的分歧，还是需要做（2）这一步，一般4轮基本就解决问题
（4）去掉最高的，最低的，求平均值
如果4个人在参加时间评估，1，3，5，11，那么4个小时基本上就是合适的时间了。
（5）把自测时间，交叉测试时间,集成测试时间，以及BUg修改时间加进去
一个需求的定义基本上完成交付就算完成这个故事了，所以应该在每个故事后面加上自测时间0.5h，交叉测试时间0.5h,集成测试时间1h，以及BUg修改时间0.5h
（6）拼估其他Story
在一个Sprint里面我们肯定不会做一个Story，很可能是几个甚至几十个Story，所以们循环上面步骤（1）（2）（3）（4）（5）评估出其他需要的时间，根据人数与时间定义出这个迭代到底做多少个Story。2X5(2周)X4(参加迭代开发人数)X4.5(每个人的有效工作时间)=需要完成的工作量
关于时间定义：自己有效工作时间（除去喝水，吃饭，等等）定义的每个开发人员一天开发时间，开发人员一般是4h那样，
估时间的时候也是按有效时间去估
2.1，3，5.。。。。纸牌游戏（基本上与1相同，只是按复杂度进行评估）
这种是通过复杂度在评估时间，一般会定义个复杂度为1的功能，然后其他功能跟这个东西进行比较，游戏纸牌有1，3，5.。。。。，通过这种方式，来
标识不同模块的复杂度
操作流程
（1）需求人员讲解需求，参加会议的人员进行提问
（2）参与迭代开发的人员进行评估，并且自己的方案
（3）如果时间相差太大，再次（2）
（4）去掉最高的，最低的，求平均值
总结：
1.这两种方法基本大同小异，第一种方法可以很细致的预估出了需要时间，而第二种大概定义了需要的时间
2.同时自己可以尝试去记着自己估时间是多少，其实在具体操作的时候时间是多少，不断总结，可以提高自己评估时间的能力。
关于团队的情绪总结：
1.团队比你想象的要强大的多
老是感觉时间不够用，那是自己把问题看大了，尤其是一些已经存在的事情，所以要试着去想下，这个问题很简单，因为有团队存在，大家都在呢！！
2.要实事求
“他说的让我都不知道怎么说了，他每次都说几分钟搞定”，不管别人估时间多少，自己一定要实事求是就好了，自己在团队里面做自己最擅长的，提高团队生产力即可。