项目管理之时间估算

时间估算是一件头痛的事情，估少了成本控制不住，估多了效率低下。一直没有找到一个相对科学的方法，直到看到《硝烟中的 Scrum 和 XP - 我们如何实施 Scrum》这本书，里面提到的计划扑克提供了一种很好的思路

估算时间需要项目组全员参与

• 分工不同，一个需求可能需要多个人参与。例如，设计、实现、测试
  
• 每个人的效率不一。管理者假设每个人完成同一个任务所需时间是相同的，这样非常不理智
  
• 如果对同一个任务，两个人评估的时间差异很大，就需要进行讨论
  

使用计划扑克做时间估算

计划扑克只有 13 张牌，分别是

• 0 代表这个故事已经完成了，或者分分钟搞定的事情
  
• ¹⁄₂
  
• 1
  
• 2
  
• 3
  
• 5
  
• 8
  
• 13
  
• 20
  
• 40
  
• 100
  
• ？ 代表完全没有头绪，无法评估
  
• coffee　代表我需要休息，这个太无厘头了。。。
  

其中，数字代表 story point / ideal days / other unit。我的体会

• 以小时为单位能提高效率, 而以人天为单位更为准确。我们目前是以天为单位进行评估，主要是方便给客户报价。但是从开发效率上，还是以小时为单位更合适，这也是用户故事推荐的策略。但是，一个需求通常很难以小时为单位准确的评估出来，例如，出了 bug 调试个一天也很正常。
  
• 当估算时间超过5天之后，就很难精确评估了。例如，40小时与45小时，很难说哪个更准
  
• 需要更精确的估算时间，就必须将用户故事进行细化、拆解，变成更小的用户故事
  

额外的时间成本

无论是团队项目，还是客户的项目。都不能忽视一个需求在沟通上的成本，特别是远程办公，且一方逻辑/表达能力欠佳。这种情况，通常我会额外加上 ¹⁄₂ 天作为沟通的时间成本。

参考

• 使用计划扑克做时间估算 － 硝烟中的Scrum和XP——我们如何实施Scrum
  
• Planning Poker: Avoiding Fallacies in Effort Estimates | Effective Software Design

关于作者 🌱

我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊，或者关注我的个人公众号“大象工具”， 查看更多联系方式