如果你觉得软件开发估时难，快看看我的估时技巧！

上次我解释了，虽然估算软件项目的时间线很难，但你应该无论如何都要去做。有了这个背景，我想详细介绍一下我在需要制定项目时间线时所使用的技巧。

关键特性：捕获时间和不确定性

我认为在这个领域并没有所谓的“正确”技巧；这里是我使用的一个技巧，我已经成功地教会了其他人使用它。还有许多其他可能同样有效的技巧，我在下面分享了一些。

然而，我的方法有一个我认为任何有效的估算技巧都应该具备的关键特征：它同时捕捉时间和不确定性。只包含时间的估算暗示了高度确定性：如果你告诉我“那将需要10天”，而我们的最后期限是14天后，我会认为我们情况很好。另一方面，如果我们有同样的最后期限，但你说“那将需要10-15天”，现在我了解到我们的最后期限有风险。

我的技巧

我的技巧是这样的：

1. 将工作分解为更简单的任务
2. 估算不确定性
3. 做数学计算，得到预期和最坏情况的估算
4. 如有必要，进行细化
5. 跟踪你的准确性，以便随着时间的推移改进

以下我们将进行详细介绍。

1、将工作分解为更简单的任务

几乎所有估算技巧的第一步都是根据复杂性将工作分解为更小的任务。我使用以下估算：

复杂性	时间
小的	1天
中等的	3 天
大的	1 周（5 天）
特大	2 周（10 天）

这些名称和数字在某种程度上是任意的（不过，你应该选择一个尺度并长期坚持使用，这样你可以随着时间的推移变得更好）。它们很好地映射了我对工作的思考方式，但不同的时间尺度也可以。故事点数代替标签也可以；名称并不重要。关键是要使用真实的挂钟时间，这意味着：

• 你必须将复杂性映射到实际的时间单位上。这里的整个目的是最终得到一个日历时间的估算（例如“4 - 6周”），你应该尽可能细致地进行这种映射。
• 使用真实的挂钟小时和天，而不是假设工程师每天编写代码8小时的理想化“程序员天”。也就是说，在上面系统中，一个小任务真的是需要大约4小时，考虑到工程师在正常工作日必须处理的所有其他事情。
• 尽量捕捉现实的预期时间。不要过于乐观地选择“最佳情况”：如果某件事可能需要3天，但如果你运气好可能只需要1天，那就称之为中型。另一方面，不要过于悲观：不要仅仅为了保险而将那个中型“升级”为大型。目标是预期时间，我们将接下来捕捉不确定性。

你做得越细致，你的最终估算就越准确。如果你做得好，大多数分解的任务应该是小型或中型。你应该有很少的大型任务，可能没有超大型任务。然而，你不必一次完成所有工作。通常我会先做一个初步的粗略估算，其中可能包含任意数量过大的任务，然后稍后细化估算。

2、估计不确定性

如果你现在停止，简单地将所有任务时间相加，你将得到一个合理的估算——但它不会捕捉到你的确定性程度。正如我上面所提到的，这是关键的：“20-30天”与“5-45天”的估算非常不同，尽管两者的中间估算（25天）是相同的。

因此，下一步是捕捉那种不确定性。最初，你可能会想到捕捉最佳情况和最坏情况，但我发现这并不太有用。相反，我更喜欢捕捉预期情况和最坏情况。提前完成从来不是问题，根据我的经验，最佳情况很少发生。但重要的是捕捉如果事情进展不顺利，某件事可能需要多长时间。因此，我的不确定性系统从预期的时长（上面捕获的）开始，然后应用一个“如果事情出错”的乘数：

不确定性水平	乘数
低	1.1
中等	1.5
高	2.0
极端	5.0

这里的“乘数”是我用来得到悲观估算的比例因子。也就是说，如果我有一个中型长度的任务，不确定性很高，这意味着“我认为这将需要3天，但可能会延长到6天”（3 × 2.0）。或者，一个大型任务，不确定性很低，意味着“我预计这将需要5天，但可能会拖到第六天。”

就像时间估算一样，具体的标签和乘数是任意的。我发现这些乘数效果很好，但不同的乘数也可以（再次强调，选择一个技巧并坚持下去）。

同样像时间估算一样：你应该努力降低不确定性。太多的高和极端不确定性估算可能是一个迹象，表明你可能需要迭代和细化你的估算。

3、做数学计算，得到预期和最坏情况的估算

现在，只需要根据我们的复杂性和不确定性定义进行数学计算。这将给你一个如下所示的分解估算：

任务	复杂性	不确定性	预期	最坏情况
重构小玩具	小型	低	1天	1.1天
交换列	大型	中等	5 天	7.5 天
交织曲线	中型	极端	5 天	25天
反转流量入口	中型	中等	3 天	4.5 天
部署	小型	低	1 天	1.1天
		总计：	15天	39天

因此，关于这个虚构项目，我可能会说：“我预计这将需要大约3周。在最坏的情况下，这可能需要长达8周。”（或者，如果我在与熟悉我的估算的人交流，我可能会简短地说“3-8周”）。

4、如有必要，进行细化

这样的范围是否可以接受？可能是的：如果你只需要时间线来设定基本预期，那可能没问题。但是，如果有外部因素——例如，如果有其他项目在等待这个项目先完成，或者六周后有一个会议，市场营销团队需要知道他们可以安全推广的内容——这个范围可能太宽泛了。

查看任务列表，应该可以立即看出不确定性的来源：“交织曲线”任务，由于其极端不确定性，几乎占据了所有差异。这是常见的：通常情况下，你可以将项目的大部分分解为低不确定性任务，但会剩下几个高度不确定的任务。

同样常见的是，项目时间线很长，由几个高复杂性（超大型）任务主导。如果这些任务也有风险，那么可能会导致范围极广。即使它们不是不确定的，一个包含太多大型任务的项目计划也可能难以产生更细致的时间线（例如，如果你想要了解在六个月项目结束时的每个月的位置）。

在这些情况下，你需要通过将那些超大型任务分解为更小的任务，并找出如何减少那些极端不确定性任务的不确定性，来细化估算。当然，如果这很容易做到，你早就完成了：那些大型任务之所以保持大型，是因为分解它们并不明显；那些风险项目之所以保持风险，是因为存在无法回答的问题。

这里的诀窍是投入一些时间——不是直接完成项目，而是进行范围界定或风险降低。我这里使用的工具是时间盒：选择一个任意的时间段（通常是1-2周），用这段时间来重新界定范围或降低风险。你可以这样利用这段时间：

研究：如果这是一种其他人过去做过的任务，你可能能够通过研究开发一个操作手册或弄清楚不确定性。例如，如果你需要将服务从AWS迁移到Azure，这可能会开始作为一个单独的高复杂性、高风险任务。但是，这是其他人过去做过的事情；通过与一些运行过类似迁移的人交谈，你应该能够进一步分解它。如果你在一个较小的组织中，这可能意味着与公司外部的人联系，但这完全是可行的。

尖峰（Spikes）：这是敏捷软件开发中的一个概念，专门用于这类情况。这个想法是你花一些时间探索一个潜在的解决方案，通常是通过深入研究并编写一些软件。有时尖峰最终会成为你的项目的一部分，但更多时候它是为了证明一个观点而设计的弃用代码。以上面的AWS到Azure的例子来说：另一种降低该项目风险的方法可能是给自己一周时间，尝试迁移一个更小、更简单的服务。在一周结束时，你可以从这个尖峰中推断出更复杂迁移的更好估算。

JFDI：有时，最好的方法是就是去做：给自己或团队一周或两周时间，然后一头扎进去。如果我们花五天时间去交织那些曲线，我们可能会发现最后我们完成了50%，并且非常有信心我们只需要再花一周。砰！不确定性消失了。

这里没有“正确”的策略。关键观察是，如果你正在处理一个过于不确定的估算，或者一个需要进一步分解的估算，你可以用前期的一些时间来换取更好的估算。花一周或两周时间来产生一个更好的估算，可能比带着交叉手指的不确定性路径出发要好得多。

5、跟踪你的准确性，以便随着时间的推移改进

最后，确保你在项目进行过程中跟踪实际时间。这形成了一个反馈循环：你做出预测，观察它偏离现实多少，然后你可以利用这些知识来随着时间的推移细化和训练你的估算技能。

例如，项目结束时，我可能会有这样一个表格：

任务	复杂性	不确定性	预期	最坏情况	实际的
重构小玩具	小型	低	1天	1.1天	2 天
交换列	大型	中等	5 天	7.5 天	3 天
交织曲线	中型	极端	5 天	25天	10 天
反转流量入口	中型	中等	3 天	4.5 天	3 天
部署	小型	低	1 天	1.1天	3 天

从这个表格中，我可能会学到，未来的部署实际上可能是中等复杂性的任务，交换列也是中等复杂性，也许下次我们需要交织曲线时，我可以减少一些不确定性。

这就是为什么，尽管具体的复杂性和不确定性大小相当随意，但选择一个模型并坚持下去是非常重要的。如果你重新定义了“低”意味着什么，你需要重新开始并重新校准所有未来的估算。

其他估算技术 正如我一开始所说的：没有“正确”的估算技巧。我展示的技巧是我使用过的一个，并且取得了合理的成功，但也有其他的技巧。所以，我将总结一些可能值得研究的其他技巧。所有这些技巧都具备我认为最重要的特征——同时捕捉时间和不确定性，但它们以不同的方式实现这一点：

项目评估与审查技术（PERT）：PERT是一个非常接近我上面展示的系统。PERT要求你做出三个估算：悲观（P）、乐观（O）和最可能（M）。然后，你使用公式（O + 4M + P）/ 6 来计算PERT估算。我从未尝试过PERT——正如我上面所写的，我不太看重最佳情况估算——但它看起来不错。

基于证据的调度采取了一种截然不同的估算方法。不是从估算开始，而是从工作开始：一开始不进行估算，直接深入工作，跟踪任务/故事，它们的大小，以及你实际完成它们所需的时间。随着时间的推移，你可以将过去故事的观察时间应用到剩余的待办事项中，估算自然就显现出来了。

当我能够使它发挥作用时，基于证据的调度是非常棒的。它不需要任何前置估算，并且非常准确。然而，我一直在努力使它工作：它需要一个稳定的团队，相对一致的工作，以及足够长的项目来提供足够的数据进行预测。许多我参与过的团队更加临时性，或者项目太过多变或短期，所以我没能经常使用这种技术。

水果沙拉是故事点数一个略显愚蠢的替代方案。但如果你看穿玩笑，它会捕捉到故事点数都无法捕捉到的东西：它还捕捉了不确定性！它通过一个单一的轴来实现这一点：随着水果变大，复杂性和不确定性都会增加（即🍉西瓜是一个大且不确定的任务）。这是一个捷径，但通常有效。要从水果沙拉中得到时间估算，你只需要将每种水果映射到一个复杂性和不确定性对，然后像上面那样进行计算。我这样做过：它相当准确。不要低估在像估算这样枯燥的事情中注入一点幽默的价值。

---

如果你喜欢本文，欢迎点赞，并且关注我们的微信公众号：Python技术极客，我们会持续更新分享 Python 开发编程、数据分析、数据挖掘、AI 人工智能、网络爬虫等技术文章！让大家在Python 技术领域持续精进提升，成为更好的自己！

添加作者微信（coder_0101），拉你进入行业技术交流群，进行技术交流