为什么项目估算偏差如此之大？

　　英文原文：Poor developer estimations AKA Guesstimation

　　在软件开发过程中，估算是一个非常重要的环节，对于项目计划、进度控制等都具有重要的意义。但是估算也是一个比较难的“技术活”，因为是 “估”，所以往往会存在一些偏差，而这些偏差对于一个项目来说，有时可能会导致多花费一些不必要的金钱，还有可能影响公司的声誉和员工的积极性。

　　而哪些因素会导致估算偏差呢？开发者 Alex E. Fish 给出了以下提示。

　　没有充分考虑需求

　　如果你没有充分考虑到所有的需求，那么估算一个任务将花费多长时间是毫无意义的。更多的需求意味着更复杂的实现，这当然也需要更多的时间来完成。

　　估算了测试时间，但没有估算修复时间

　　估算应该考虑到所有的测试时间以及修复 bug 的时间。单元测试、BDD（Behavior Driven Development，行为驱动开发）测试、测试人员进行手工测试，这都是需要花费时间的。并且，开发人员查找和修复 bug 同样也需要时间。更复杂的任务有可能会包含更多的 bug，这意味着需要花费更多的时间来跟踪和修复它们。

　　假定开发者每天 8 小时都在编码

　　就算开发者每天上班 8 个小时（不加班情况下），但是这不代表 8 个小时都在编码，其他一些琐事往往会令生产率大大降低，比如会议、电子邮件、同事之间的 IM 消息、询问问题等。开发者从工作中断恢复到工作状态，往往也需要 15 分钟时间。有些时候，开发者一天只有 2 个小时的时间用于编码。

　　按天估算，没有按小时估算

　　所有的任务都应该被分解成2~16 小时的块任务。这是一个很好的规则，可以让你独立地看待每个任务，并能够把所有因素都考虑在内，减少估算偏差的机会。

　　让非项目人员来估算

　　应该由参与编写软件的开发者们来进行估算。他们可以根据自身经验、开发速度对项目有一个更准确的把握。这也避免了由于A设置的进度过快，而导致B被追究责任。

　　忘记过去

　　George Santayana 曾说：“忘记过去的人注定要重蹈覆辙。”如果这不是你的第一个项目，那么最好回头看看过去的项目。查找你以前曾参与过的同一领域中的类似规模/要求的项目，并将它作为一个参考点。

　　忽略停工期

　　如果项目是一个长期项目，或者开发者在夏季需要有一个假期，那么在估算时也应该考虑在内。必要时，考虑设置一个适当的缓冲期。

　　过于确切

　　将项目估算在一个确切的期限内或小时数内是不现实的，这也是无法实现的，最好的办法是估算一个范围，包括最好的情况下、最有可能的情况下、最坏的情况下的范围。

　　总结：要认真看待估算

　　估算是一个应该认真对待的工作，也是每一个开发者必备的技能。你和你的同事都应该掌握并进行实践。一个好的估算的做法是人人参与。

　　估计没有人喜欢估算，我个人认为这是软件开发工作中最糟糕的部分。而估算也从来都不会真正可靠或者完全准确，但还是希望上文这些内容可以为你带来一些帮助。