估算工作时间的 3 条规则（在软件开发项目中）

故事点还是时间来估计软件开发的工作量？这是一个持续不断的讨论。事实是，没有一个答案适合所有情况。这取决于各种因素。

此外，尽管故事点数已经非常流行，但为什么使用 SP 而不是时间的问题仍然存在。原因解释如下：为什么是故事点数而不是时间？

本文重点介绍如何有效地估算工作时间，因为实践表明，在大多数情况下，这是团队的（正确）选择。让我们来解释一下如何正确估算软件开发项目中的时间，因为这不仅仅是实施需要多少小时或多少天。

不使用 Story Points 的原因

在估算软件开发项目的工作量时，有两种选择——以故事点 (SP) 或时间估算。虽然时间是任何项目的通用估算单位，无论行业如何，但故事点与软件开发密切相关。即使它并不适合所有软件开发团队。

成功实施 SP 取决于几个因素。以下是其中几个：

• 适当的环境，即培养敏捷思维的组织文化。如果管理层不理解 SP 估算，并且仍然要求严格的时间估算，那么团队在 SP 中进行估算的积极性就会降低。
• 在 SP 中进行估算需要团队成员的成熟度和共识。如果团队成员不熟悉 SP 是什么或持怀疑态度，他们就不会充分参与，因此整个团队的努力都会失败。
• 这样的敏捷实践需要非常有知识和技能的 Scrum Master/敏捷教练来促进正确实施。

团队将时间作为评估工作量的单位的原因有很多。说实话，在我指导的团队的实践中，大多数情况下我都使用时间。然而，这种方法有自己的规则，以确保结果准确且有用。

1.估计理想时间

（对于熟悉术语的人来说：实时就像前置时间，但出于本文的目的，我将其称为实时，因为使用和衡量前置时间的原因不同，并且本文中介绍的实践表明团队采用了不同的工作方法。）

我们首先需要解释的是理想时间背后的含义，然后是特定项目给出的数字。

所有团队成员都必须明白，当他们提供估算时，他们被要求在理想时间内提供估算。这是在开发人员专心工作而不受干扰的情况下实现项目所需的时间。分心意味着查看电子邮件、参加培训、与同事交谈、开会等。

理想时间与实际时间不同。

• 理想时间是指在不被打断的情况下完成一项任务所需的时间，例如参加会议或查看电子邮件（或短暂休息）。
• 实时考虑实际持续时间（日历天），包括所有干扰、停止和中断。

举个例子：一个项目预计在很短的时间内（2 天）完成，但实际上需要更长的时间（例如 5 天），但团队成员并没有把所有的时间都花在这个项目上。下图显示了这种情况。这是一种非常常见的情况。一名开发人员周一开始处理一个预计有 2 个 ID 的项目，周五完成。由于许多中断和干扰，需要 5 天才能完成。

实时的问题是什么？由于多种因素，很难预测实时。下面我将列举其中的一些因素：

• 分散注意力的活动分布不均匀
• 你无法预测所有的干扰。
  当我们估算时间时，我们会估算理想时间，想象我们将在不受任何干扰的情况下工作。

最后，我们需要明确给出的某个特定项目的估计数字到底是多少。这实际上是理想天数，这引出了下一条规则，该规则与指出理想天数的可能选项有关。

2.使用斐波那契数列进行估算

第二条规则与团队成员提供估算的数字选项有关。通常，团队使用斐波那契数列或其变体来估算他们的工作，如下所示：

坚持这个序列的数字有很大的原因。正如你所看到的，序列开始时可能选项之间的差距很小，随着序列的进展，差距变得越来越大。差距大意味着估计值波动很大。这是正常的，因为当团队成员估计一个小项目时，他/她能够更准确地评估它。反之亦然——当估计一个大项目时，一个人无法想到任何小细节，也无法预见可能发生的所有潜在问题。这导致估计不太准确。

为了更加清晰，我要提到，这就是为什么“就绪定义”通常包含一项要求，即如果任务大于 3 或 5 个故事点（分别是 3 或 5 个理想日），则不能将其添加到冲刺中。如果它更大，则意味着关于这个元素有很多未知数。在这种情况下，必须将项目分解为更小的部分，所有新的较小元素都将重新估计，然后实施。

3. 创建安全环境并使用规划扑克

由于团队成员会及时提供他们的评估，因此初级开发人员完成相同任务所需的时间比高级开发人员更多是正常的。当然，他们的评估会有所不同。创建一个安全的环境非常重要，让人们不害怕给出他们的真实评估。这里的目标不是获得准确的分数，而是引发讨论并了解团队中每个人的顾虑。（资历不同是使用故事点而不是时间的主要原因，我在这里详细解释了这一点。）

下一个合乎逻辑的问题是——如果提供的等级存在差异，我们如何确定将标记为产品待办事项中某个项目的估计值的等级？

• 首先，你需要了解差异背后的原因——是因为经验水平不同，还是因为对任务的理解不同？很多时候，人们对任务的理解和假设范围不同。他们认为某些东西比实际要求更大，反之亦然——他们还没有理解要求背后的确切内容，并低估了它。最重要的是，利用这个机会在团队成员之间建立共识。
• 如果差异是由于经验水平不同造成的 — — 只需就平均合理的水平达成一致即可。没有人会因为一项任务花费的时间比预估的要长而被评判。即使团队按时估算，速度也是为整个团队计算的，而不是为单个团队成员计算的。

使用规划扑克

至于对给定任务建立共同理解，我们应该提到规划扑克技术。

首先，作为 Scrum Master/Agile Coach，您必须确保每个人都对 Planning Poker 的目的有相同的看法。Poker Planning 是一个促进讨论和建立对任务的共同理解的机会，而不是获得准确的估计或争论差异。

因此，在及时估算工作量时，您需要使用 Planning Poker 来获取所有团队成员的意见，并确保一个安全的环境，让团队成员可以放心地分享他们的观点。实际上，这是在任何情况下建立健康团队环境的基本规则。

最后，总结一下如何有效地估算 Time 中的待办事项：

• 理想天数：团队成员根据理想天数给出他们的估计，这意味着他们想象他们在完成任务时不会受到任何干扰或分心。
• 斐波那契数列：在提供估计时，团队成员仅使用属于斐波那契数列（或其变体）的数字。
• 安全环境：建立一个安全的环境至关重要，让所有团队成员都可以轻松地表达他们的估计及其背后的原因。