软件项目的时间估算 • Jacob Kaplan-Moss
本文是 Django 的共同创建者,同时担任工程主管的 Jacob Kaplan-Moss 所写。软件项目的估算是一个众所周知的难题,许多项目经常出现成本超支和进度延误的情况。然而,尽管估算困难,作者强调了估算的重要性,并认为放弃估算可能会限制职业发展。准确的估算是可以学习和掌握的技能,它能够帮助建立信任并促进职业的进一步发展。Jacob Kaplan-Moss 分享了一种软件项目时间估算的技术。他的方法的核心特点是同时捕捉时间和不确定性,以便为项目制定更准确的时间表。他的技术包括将工作分解为较小的任务、估算不确定性、计算预期和最坏情况的时间、必要时进行精细化,以及跟踪估算的准确性以便不断改进。 估算的挑战: 软件项目估算普遍困难,研究表明许多 IT 项目成本超支超过 200%,并且平均延误近 70%。 大型软件项目尤其容易超支,预算超过 1500 万美元的项目平均超支 66%,进度延误 33%。 “无估算”方法的局限性: 尽管有“无估算”方法和 Agile 方法试图避免时间单位的估算,但在某些情况下,准确的时间估算是不可避免的。例如,销售团队可能需要一个具体的时间表来完成交易,或者其他团队可能依赖于特定功能的交付时间。 估算的重要性: 估算是职业发展的关键技能,能够准确地给出时间表并按时交付任务有助于建立信任。对于希望在技术职业中更进一步的人来说,掌握估算技能至关重要。 估算是可以学习的技能: 估算是一项可以通过实践和反复校准来学习的技能。通过反复的项目分解和时间估算,工程师可以逐渐提高估算的准确性,并了解团队的工作节奏和代码库的复杂性。 我的估算技术: 任务分解:Kaplan-Moss 建议将工作分解为不同复杂度的小任务,并使用实际的日历时间(而非理想化的“程序员时间”)来估算每个任务的完成时间。任务复杂度分为小(1天)、中(3天)、大(5天)和超大(10天)四种。 估算不确定性:在初步估算的基础上,他建议通过应用一个“如果事情出错”的乘数来捕捉不确定性。这个乘数根据不确定性水平(低、中、高、极高)从 1.1 到 5.0 不等。这样可以得到预期时间和最坏情况的时间。 计算时间:通过任务复杂度和不确定性乘数,计算出每个任务的预期时间和最坏情况时间。例如,一个中等复杂度且高不确定性的任务预期需要 3 天,但最坏情况下可能需要 6 天。 精细化估算:如果估算范围过大,他建议通过进一步分解大任务或减少不确定性来精细化估算。可以通过研究、短期试验(spikes)或直接动手完成部分任务来减少不确定性。 跟踪准确性:最后,他强调在项目进行过程中跟踪实际用时,并与估算时间进行比较。这种反馈循环有助于不断改进未来的估算精度。 其他估算技术:Kaplan-Moss 还提到了其他几种估算技术,如 PERT(程序评估与审查技术)、基于证据的调度(Evidence-based scheduling)和水果沙拉 Scrum(Fruit-salad scrum),并指出这些技术也捕捉了时间和不确定性,但采用了不同的方法。 软件项目估算 众所周知,估算软件项目的难度非常大。哈佛商业评论 (HBR) 的一项研究发现,每六个 IT 项目中就有一个成本超支超过 200%,且延迟几乎 70%。麦肯锡 (McKinsey) 的另一项研究发现,IT 项目的平均预算超支 45%,时间超出计划 7%。研究还指出,大型软件项目的问题尤为严重:预算超过 1500 万美元的软件项目,平均预算超支 66%,时间延迟 33%。 实际上,任何在软件行业工作过一段时间的人都经历过类似的情形。你可能曾自信地说“这应该只需要几天时间”,但一个月后却发现自己仍未完成。软件项目估算总是难免遇到霍夫施塔特定律 (Hofstadter’s Law):“事情总是比你预期的时间更长,即使你考虑了霍夫施塔特定律。” 遗憾的是,许多人看到这种模式后,觉得估算软件项目太困难,干脆选择放弃。有一种被称为“无估算” (No Estimates) 的立场认为我们应该完全停止对软件项目进行时间估算。很多敏捷方法采用了任意的评分系统——如故事点 (Story Points)、T 恤尺码等——这些系统的设计目的就是为了避免给出具体的时间估算。...