时间估算是一件头痛的事情，估少了成本控制不住，估多了效率低下。一直没有找到一个相对科学的方法，直到看到《硝烟中的 Scrum 和 XP - 我们如何实施 Scrum》这本书，里面提到的计划扑克提供了一种很好的思路
估算时间需要项目组全员参与
- 分工不同，一个需求可能需要多个人参与。例如，设计、实现、测试
- 每个人的效率不一。管理者假设每个人完成同一个任务所需时间是相同的，这样非常不理智
- 如果对同一个任务，两个人评估的时间差异很大，就需要进行讨论
使用计划扑克做时间估算
计划扑克只有 13 张牌，分别是
- 0 代表这个故事已经完成了，或者分分钟搞定的事情
- 1/2
- 1
- 2
- 3
- 5
- 8
- 13
- 20
- 40
- 100
- ？ 代表完全没有头绪，无法评估
- coffee 代表我需要休息，这个太无厘头了。。。
其中，数字代表 story point / ideal days / other unit。我的体会
- 以小时为单位能提高效率, 而以人天为单位更为准确。我们目前是以天为单位进行评估，主要是方便给客户报价。但是从开发效率上，还是以小时为单位更合适，这也是用户故事推荐的策略。但是，一个需求通常很难以小时为单位准确的评估出来，例如，出了 bug 调试个一天也很正常。
- 当估算时间超过5天之后，就很难精确评估了。例如，40小时与45小时，很难说哪个更准
- 需要更精确的估算时间，就必须将用户故事进行细化、拆解，变成更小的用户故事
额外的时间成本
无论是团队项目，还是客户的项目。都不能忽视一个需求在沟通上的成本，特别是远程办公，且一方逻辑/表达能力欠佳。这种情况，通常我会额外加上 1/2 天作为沟通的时间成本。