相信吗?打个牌就能确定工期！

一、本文背景

原本定的工期已满期，产品没有正常上线，项目leader把大家召集在一起，开会讨论解决为什么延期的问题。共同抛出的问题就是不能根据现有的情况确定相近的完成日期。
用的是敏捷开发中的扑克牌估算

二、扑克牌估算是什么

估算扑克是几个潜在的任务承担者(如项目组成员)共同估算的方法，他们一起听产品负责人讲解需求，一起估算完成工期，以达到利用集体智慧解决问题的目的

三、怎么玩

• 1.每人各自估算后独立出暗牌，听口令一起开牌。(参加成员暗地估算当前需求天数，听口令一起发出各自的估算时长)
• 2.数值最大者和最小者PK，其他人旁听。(估算天数最大者和最小者上台进行阐述为什么要这么多时长，其他人可以提出问题)
• 3.讨论结束后重新出牌和开牌
• 4.重复上述过程，直到结果比较接近

注意事项:

• 1.负责该模块的童鞋不能参与估算，因为他可能不知道原迭代上一版本代码是否可复用，不知道某软件不行，而选择错误实现方法
• 2.不能一个人说了算，比如直接用一个很有项目经验的大佬估算工期，共同估算的过程就是让大家在思考中对照自己的实现方法和大佬差异的过程

四、具体实践

下面我会用我们一下午的成果给大家举个例子，也给自己做一个记录

讲完该模块UE图(需求)后，开始估算工期，一天按8h算
第一轮
估算2min后

从图中可以看出来，别人都是按天算的，而我只有4h，是估算时长最短的，我和4天的一个代表进行pk。好吧，我是太明白这个模块的责任。估算工期4天的大佬将这个前端页面怎么来以及调用后端的几个接口都说出来了，当然也不代表就是全面的。
注意，这个时候不知道如何实现的童鞋是可以提问题的，为什么这么实现，这个时候也是吸取经验的重要时刻

现在开始第二轮
这次加上了估算时长以及估算时长都用于干了什么

正在我思路满篇时，2min时间已经到了，于是就提上了前端后端各6个小时。
此轮最少时长3h，最长时长24h，经过pk，3h的童鞋也是忽略了整体模块的业务，改成了12h，也就是相差12h

于是再来第三轮

这次时间控制在了14h左右，14h大约就是这个模块工期，为以后的开发做个参考，当然你说要是完不成怎么办，正好做一个偏差分析，为什么完不成。
那么要是，对这个模块没有太多的思路怎么办，这个时候一定要问问题，请教为什么这么做。

五、总结

这次活动的收获

• 1.确定工期，充分发挥集体的智慧，将整个模块怎么做什么时候做完提出来，相互交流
• 2.每个人对每个模块有了更全面理解，避免出现模块孤立现象，毕竟业务间多少都有一些耦合
• 3.取长补短，正是相互学习如何设计，如何思考的过程

更多做项目的经历会在后续补充