满足您的最后期限：开发人员用来估算工作量的方法

大家好！要开始软件开发，您需要了解大量理论。一些专家（例如，使用 Java 和其他语言的后端开发人员）了解更多，而其他人（例如，使用 JavaScript 和 React Native 的前端开发人员）可能了解得更少。也就是说，这两个群体都必须拥有大量的技术知识和“组织”知识。这种“组织”知识是前端和后端开发人员重叠的一个领域。 今天我想谈谈这种非技术性的、组织性的知识的一个方面。今天我们将讨论工作量估算。因为我只有使用敏捷方法的经验（这被认为是最受欢迎的），更具体地说是 Scrum 框架，我将在Scrum的背景下考虑工作量估算。一开始，我必须说工作量估算很困难。对我来说，这是我作为开发人员工作中最具挑战性/最不愉快的方面之一。有许多不同的因素需要考虑，这些因素会影响您对任务所需工作量的估计。此外，未来的发展计划将基于您的估计。

如果你提供了一个错误的估计怎么办？

如果开发人员估计完成一项任务的时间远远多于最终花费在该任务上的时间，那么他们的专业知识可能会受到质疑，因为估计非常不准确。换句话说，这是一个疯狂的猜测。同时，如果开发人员没有在预计的时间内完成工作，她就会危及客户发布产品或新功能的计划。这就是生意，生意就是钱。很少有顾客会对这样的失误感到满意。事实上，这就是我不喜欢估算的原因——因为有时准确确定完成一项任务所需的时间非常棘手。

如何进行时间估算

通常，估算是以小时或故事点为单位的。我个人的偏好是使用故事点来进行估算。很难将具体的物理对象弄错，但故事点更抽象一些。软件开发团队通常提供时间量的估计：小时、天、周、月。这些时间估计主要基于个人经验、猜测和/或直觉。在这种情况下，开发人员只需查看任务并表达他们对需要多少时间的假设。因此，这些估计很少是准确的，因为影响工作持续时间的因素太多了。这就是为什么许多使用敏捷方法的团队也使用故事点的原因。让我们开始吧！

什么是故事点？

故事点是一种度量单位，用于表达对完全实现某项功能所需的总工作量的估计。也就是说，我们谈论的是相对的复杂。团队根据工作的复杂性、工作量以及风险或不确定性分配故事点的估计值。通常分配这些值是为了更有效地将工作分成更小的部分，从而消除歧义。随着时间的推移，这有助于团队了解他们在给定时间段内可以完成的工作，并帮助他们更准确地计划后续工作。这听起来可能完全违反直觉，但这种抽象确实很方便：它促使团队就工作的复杂性做出艰难的决定。让我们来看看在计划时使用故事点的一些原因：

• 您可以避免不准确的时间估计。
• 与以时间为单位的估算不同，故事点可以让您计算管理费用：团队成员与客户之间的沟通、各种团队讨论和计划活动，以及不可预见的情况。
• 每个团队将使用不同的尺度来估计他们的工作，这意味着他们的能力（以点为单位）会有所不同。
• 通过定义分配每个故事点的比例，您可以快速分配点而不会引起太多争议。

如何不使用故事点

不幸的是，故事点经常被滥用。当故事点被用来评估人员、定义详细的截止日期和资源时，以及当它们被误认为是绩效衡量标准时，它们可能会产生误导。相反，团队应该使用它们来了解每项任务的范围/复杂性并设置优先级。也许被认为更困难的部分应该首先解决，这样它们就可以在冲刺结束前完成，可能会将更容易的任务转移到后面。让我提醒您在Scrum方法论的背景下什么是冲刺： 此时间段的长度在开发开始时确定，并由团队和客户商定。这可以是两周或一个月的时间段，或任何其他时间段。通常，工作量估算是在每个冲刺开始时进行的，以便计划可以在冲刺结束时完成的工作，届时已完成的工作将交付给客户。 该演示可帮助您查看产品开发进度、接收客户反馈并根据客户的愿景调整项目的轨迹。但我们离题了一点。让我们回到估计。如果只让一个开发人员对所有任务进行估算，那就太主观了。所以这个过程通常是一个团队的努力。团队可以使用多种技术来生成估算值。今天我们来看看最流行的技巧：scrum poker。此技术需要一名经理担任scrum 扑克的主持人。这可以是scrum master或可能是PM的人。

什么是 Scrum 扑克？

Scrum 扑克或计划扑克是一种基于达成协议的估算技术。它主要用于估计未来工作的复杂程度或软件开发任务的相对规模。我会马上说scrum 扑克是一种常见的软件开发实践，您需要了解它的全部内容。它通常涉及一个应用程序或网站，以促进团队协作创建对特定任务的估计。这是怎么发生的？团队从积压工作中提取一些东西（一项新任务、一些功能）并简要讨论可能存在的陷阱以及与之相关的其他细微差别。然后每个参与者选择一张卡片，卡片上的数字反映了他们的复杂性估计。哦，还有一件事，在进行这些估计时，我们使用斐波那契数列中的数字而不是普通数字。 斐波那契数列在scrum 扑克中很受欢迎，因为它们之间的差距越来越大（类似于金字塔的层次）。有些任务会非常复杂，我们无法通过少量的故事点逃脱惩罚。 有一些不寻常的卡片具有以下含义：

未知数量的端点

无限长的任务

需要休息一下

不太常见的估计方法使用：

• T 恤尺码 — S、M、L、XL
• 犬种——吉娃娃、哈巴狗、腊肠犬、斗牛犬等（我个人认为这是最奇怪的努力估算单位 =D）

然后，该团队比较不同开发人员对同一任务给出的估计。如果他们同意，那就太好了！如果不是，则需要讨论不同估计的原因（论点）。之后，团队一起工作形成一个每个人或多或少都接受的估计。那么为什么还要用扑克来规划严肃的软件项目呢？你不得不承认这很奇怪。事实上，这种游戏化鼓励团队成员独立思考，邀请他们与队友同时透露自己的估计。这反过来又避免了某些团队成员依赖他人意见的情况。如果不这样做，那么经验不足的开发人员会查看并专注于经验丰富的团队成员提供的估计，这将使他们自己的估计变得不那么有用。但同时显示估计值使得这基本上是不可能的。Atlassian 优惠在规划过程中使用的 scrum 扑克应用程序。

工作量估算示例

假设您的团队建立了以下比例来将故事点分配给估算值： 为每个任务玩Scrum 扑克，您提供如下估计：

• 您以前从未实现过类似的功能：+3
• 功能平均大小：+2
• 实施将非常复杂：+3
• 为功能编写测试将非常复杂：+3

将每个组件加起来，你总共得到 11 个故事点，但没有这样的卡片，所以你建议 13。一位同事对任务提出了以下估计：

• 他以前做过类似的任务：+1
• 功能平均大小：+2
• 实现的平均复杂度：+2
• 为功能编写测试的平均复杂度：+2

他的中间结果是 7 个故事点，但这个数字在斐波那契数列中不存在，所以他提交了一张最接近数字的卡片——8。其他团队成员也根据自己的主观看法做出估计。然后每个人都出示卡片，你会发现几乎所有同事都给出了 13 的估计值，除了一位建议 8 的开发人员。在这种情况下，他可以发言说明他估计值较低的原因。假设他提供了这样的理由：他以前做过同样的任务，而且它并不像看起来那么困难。最终，他说服团队的其他成员将他们的想法从 13 个故事点改变为 8 个故事点，并表示他将帮助最终完成这项任务的人。或许他会自己做。无论如何，它不 其他人是否接受他的论点并不重要，因为不管怎样，估计都会分配给任务，然后团队会继续考虑下一个。最初，估计是不准确的，对你计划在下一个时间段（冲刺）完成的工作量的估计也是如此。毕竟，这些估计是使用估计得出的。一段时间后，也许三个月后，团队将开始更准确地估计任务所需的时间，并且团队在冲刺中能够完成的平均工作量将变得显而易见。但这是一个对工作范围进行总体规划的过程。它主要关注时间，但在这种情况下可能有许多不同的相关因素。例如，假设开发人员休假两周。您将需要削减一定数量的计划工作（计划功能）。或者假设一个新的开发人员加入了团队，但还没有完全跟上进度，所以你需要让她有时间通过入职流程。这可能是两周，或多或少一周，具体取决于项目的复杂程度。今天就到这里！我希望我稍微提高了您对工作量估算的了解，这是软件开发的一个必要的非技术方面。如果您想更深入地了解这个主题，并了解 Scrum 的细节，我强烈建议您阅读 Jeff Sutherland 的《SCRUM》一书。我不能对后果做出任何承诺，因为看完之后你会有一种烦人的渴望成为一名 scrum master =D