软件项目估算：

软件估算确实很困难，但我们仍然要去尝试。

估算软件项目的难度已得到广泛认可。哈佛商业评论的一项研究显示，六分之一的 IT 项目成本超支超过 200%，且几乎有 70%的项目延迟。麦肯锡的另一项研究发现，IT 项目平均超出预算 45%，进度超出 7%。他们还发现，大型软件项目尤其严重：预算超过 1500 万美元的软件项目超支 66%，进度延迟平均为 33%。

当然，任何在软件行业工作过一段时间的人都会亲身体验到这一点。你可能曾经说过“哦，没问题，这只需要几天”……但一个月后你却发现自己仍然没有完成。估算软件项目似乎总是会遇到霍夫施塔特定律：“它总是比你预期的要花更长的时间，即使你已经考虑到了这一点。”

不幸的是，很多人看到这种模式，意识到估算软件项目的时间线很困难，便选择放弃。现在有一种“无估算”的观点，认为我们应该完全停止对软件项目进行估算。许多敏捷方法论采用了任意评分系统——如故事点、T 恤尺码等——这些系统的设计旨在帮助我们避免使用时间单位进行估算。

There’s nuance here: these ideas do have some value. I don’t mean to dunk on story points
这里有些细微的差别：这些观点确实有其价值。我并不是想否定故事点。¹. In particular, “no estimates”-style project management can lead to better conversations about timelines: these systems encourage questions like “what can we get done in the next two weeks?” instead of “how long will Feature X take?” This can often be a much better way of thinking about software projects, especially long-lived ones.
特别是，“无估算”风格的项目管理能够促进关于时间线的更有效对话：这种系统鼓励提出“我们在接下来的两周内能完成什么？”而不是“功能 X 需要多长时间？”这通常是思考软件项目，尤其是长期项目的更佳方式。

然而，迟早会有人问“功能 X 什么时候发布？”在某些情况下，得到一个准确的答案是至关重要的。也许销售团队可以通过承诺某个新功能的时间表来达成一笔重要交易。也许这个功能是其他团队的一个关键依赖，他们需要知道如何安排自己的工作。也许你的功能是多个功能中的一个，这些功能将共同推出一个新产品，而整个产品发布流程需要启动并进行推广，这就需要一个时间表。我可以继续举例：总之，有很多情况下需要一个估计。

在技术职业中取得进展的一个重要“秘诀”是学会如何给出准确的估算。对我而言，这确实是如此：我不怕提供时间表，并且我已经学会了如何做到足够准确，以至于人们信任我的估算。

如果你总是避免进行估算，并且在需要时不学会给出时间表，这可能会限制你的职业发展。能够告诉你的上司和同事何时可以期待什么，并且能够实现这些目标，会在很大程度上建立信任。这对个人贡献者和工程经理都是如此：你可以相对轻松地成为高级工程师或工程经理，而不需要擅长估算，但要想更进一步，你可能需要掌握这项技能。

这是一项技能：估算是可以学习的。你可以掌握一些技巧，但在某种程度上，这些技巧并不重要：无论你使用什么方法，实践才能使完美。如果你养成将项目分解并进行时间估算的习惯，你就可以将这些估算与实际情况进行对比并进行调整。反复进行这个过程，你会变得更加熟练：你会了解到团队在哪些地方容易遇到困难，在哪些地方能迅速完成工作；你会发现代码库中哪些部分修改起来简单快捷，哪些则需要更多时间；你会学会识别自己的偏见，以及在哪些方面最容易高估或低估。

本系列的下一篇文章将介绍我使用的估算技巧，这对我来说一直很有效。但比起技巧，更重要的是一个更广泛的观点：估算很难，但我们仍然要去做。