程序员其实根本不需要项目预估！

项目预估一直就是软件开发周期中最困难的阶段。事实上它的难度相当大，最近很多人都提议我不必去烦恼项目评估的事情。

David Anderson，支持Kanban（译者注：貌似是某可视化项目管理系统，附上维基百科）。他认为我们应该停止项目评估，它只会浪费时间。他在微软推广Kanban方法的案例研究中，改进团队效率的第一步就是让他们停止项目评估，把注意力集中在工作的优先级并先进行重要的工作。

某位大牛Ron Jeffries说过

我认为大部分的预估就是在浪费时间，预估本来应该是用在发布计划上估算有效需求的的，而现在则是以不合规范的方式折磨着程序员，它更像是在“决定是否做这个项目”，而不是在“根据开发人员是否有头绪来估算这样做所需要的时间”。

还有

项目预估绝对是在“浪费时间”。它不是软件……如果你觉得评估对你有好处的话，那么你该反思它是不是垃圾，然后离它远点。

还有一些人在“如果你讨厌项目评估的话，就没有必要再为它投入精力了”的帖子中说到：

把精力都用在证明评估报告是“正确无误”的根本就是在浪费时间。把精力花在估算现实与想法差别的也是在浪费时间。把精力都放在怎样训练员工去达到“正确无误”的评估效果完全就是在浪费时间，并且还会影响团队的效率。

在“软件评估被认为是有害的？”这篇文章中，Peter Seibel谈到某位朋友发现保持员工注意力和积极性在尽快发布软件上尤为重要。他还说到

如果目的仅仅是在单位时间内开发尽量多的软件，那么评估恐怕不是什么好主意。

他在1985年关于人件的学习中发现了程序员基于自己预估的效率比其他人的都要高，但是压根没有评估的话，项目开发的效率是最高的。

Seibel承认也许“项目评估对于协调人们的工作是有用的”——因此他把项目评估视作“交流的工具”。不过从这一点上来看，通过项目评估来传递信息根本是昂贵且无效的低质量行为——因为所有的评估都包含了误差和可变性（参考这篇文章）。

这背后预示着什么？

所有这些想法揭示了当前开发的潮流风向，把所有找到的潜在性垃圾都清除掉。它就像是：评估消耗时间并拖慢速度。你无法做出完全的评估，那为什么还要去试呢？

这些言论和事例主要来自创业公司和其他小型团队环境，对于他们发布产品比做出可预测性更为重要。他们更在乎项目有没有完成而不是何时完成或要多少成本。

你需要项目评估吗？

我认为项目评估在创业公司（需要说服一些人赞助你的工作）里并不是非常重要的。

如果你正焦头烂额，或是处于某种紧急事件，就根本没有时间让你停下去评估了，成本什么的都无所谓，你唯一关心的就是尽快完成工作。

评估对于维护并不怎么重要——Kanban的很多维护团队的例子都是没有评估的。这是因为维护本身做的更改很小——通常维护是为了解决bug并要在5天之内完成的。如果想知道要花多少时间用来修改，你必须审阅一遍代码才能知道哪里需要怎么改。这会占用整个修改过程的一半时间，而且假如你已经修改了一些了，这时停下来评估剩余的任务还不如一鼓作气改完算了。很多时候一个缩略图或占位符的规则就是很好的评估了。

我在一个经验丰富的开发团队里工作，几年时间都在负责某个系统。团队里几乎所有的人都由内而外地参与过原始设计和系统编程。

开发的高管负责分配任务。他们对那些大得吓人的系统有着很好的理解感，在我们要开始决定做什么的时候就能规划出未来大致的概念了。

很多时候程序员可以看出一段时间内什么东西要做，什么不需要做。这是因为他们很熟悉这个系统和相关领域了，而且他们清楚现在需要做什么——即使现在不清楚，很快也会清楚的。这点对于测试员同样有效——大多数时候他们都知道测试修改时有哪些工作要做，和能不能做到。

有时人们会犯错，导致无法按照想法完成工作，因此会拖慢进度或要重头开始。但是花一些时间用来分析和预估可能也不会有多大帮助。只有在完全陷入某个错误或认识到问题比想象中严重的事后才有用。

我们并不需要项目评估。我们需要在没有相关文件的时候尽量利用团队的经验和知识来做出快速有效的决定。

对于有些含有大量内置模块或界面的大型项目，很多人都不知道准备做什么。还有因为员工不熟悉系统、平台、领域或其他东西而无法快速下决定的团队。或是有些东西要绝对服从截止时间等等这些情况下，你不得不花些时间来预估要做什么，随着对问题的了解可能还要再做评估。你可以不预估就开始做，但并不推荐。