一、本文背景
原本定的工期已滿期，產品沒有正常上線，項目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.取長補短，正是相互學習如何設計，如何思考的過程
更多做項目的經歷會在後續補充