开发人员使用什么方法来评估任务？

大家好！开始开发所需的理论非常广泛。一些专家（Java 和其他语言的后端开发人员）拥有更多的知识，而其他人（例如 JavaScript - React Native 的前端开发人员）拥有的知识则少一些。然而，他们两人不仅必须拥有大量的技术知识，而且还必须拥有大量的“组织”知识。这种“组织”知识是前端和后端开发人员的交叉点之一。 今天我想谈谈这种非技术性、组织性知识的一个方面——关于任务评估（估计）。由于我只在敏捷方法论（实际上被认为是最流行的）中工作，因此在其子部分Scrum中，我将考虑Scrum背景下的任务评估。我马上就会说，评估（也称为估计）是很困难的。对于我个人来说，作为一名开发人员，这是工作中最困难/最不受欢迎的方面之一。有许多不同的因素需要考虑，这些因素会影响任务的评估。同时，进一步的发展计划将基于您的预测。

如果您没有获得正确的评级怎么办？

如果开发人员在一项任务上花费的时间比最终花费的时间多，那么他可能看起来不是最好的专家，因为估计非常不准确。可以说，一根手指伸向天空。同时，如果开发人员没有在预计的时间内进行投资，他就会危及客户发布产品/新功能的计划。这是一门生意，而生意就意味着金钱，很少有顾客会喜欢这样的穿刺。 这实际上就是我不喜欢估算的原因，因为有时很难确定完成任务的确切时间。

时间是如何评估的？

通常，估算以小时或故事点为单位进行。就我个人而言，我更接近于故事点的评估过程。如果手表是有形的东西，那么可能会被误解，故事点则与其他更抽象的东西有关。通常，软件开发团队会以时间格式给出估算：小时、天、周、月。这种时间估计主要基于个人经验、猜测或直觉。在这种情况下，开发人员只需查看任务并估计需要多长时间即可。因此，它们很少是准确的，因为有太多因素会影响完成工作的最后期限。因此，许多按照敏捷方法工作的团队都使用故事点。让我们弄清楚一下。

什么是故事点

故事点是一种衡量单位，表示对完全实现某个工作领域（功能）所需的总工作量的评估。也就是这么一个相对的复杂度。团队根据工作的复杂性、工作范围以及风险或不确定性来分配故事点。通常，分配这些值是为了更有效地将工作分解为更小的部分，从而消除不确定性。随着时间的推移，这可以帮助团队了解他们在给定时间内可以实现的目标，并帮助他们更准确地规划下一个工作领域。这对你来说似乎完全违反直觉，但这种抽象实际上非常有用：它促使团队对工作的复杂性做出更艰难的决定。让我们看看在规划中使用故事点的一些原因：

• 可以避免时间间隔的估计不准确；
• 与随时间估算不同，间接成本可以更好地考虑到：团队成员和客户之间的沟通、各种团队讨论和计划以及不可预见的情况；
• 每个团队都会以不同的标准对工作进行评分，这意味着他们的速度（以分数衡量）会有所不同；
• 通过定义分配每个故事点的比例，您可以快速分配点，而不会产生太多争议。

如何不使用故事点

不幸的是，故事点经常被用于其他目的。当故事点被用来评估人员、定义详细的截止日期和资源时，以及当它们被错误地视为绩效衡量标准时，它们可能会存在缺陷。相反，团队需要使用它们来了解每项任务的工作量/复杂性并确定优先级。可能应该先完成被评为较困难的部分，以便它们可以在冲刺结束之前完成，但较容易的部分可以推迟到以后。让我提醒您Scrum方法论中的 sprint 是什么： 这个时间段有多长是在开发之初由团队和客户协议确定的。这可以是两周或一个月的时间段，或任何其他时间段。通常，任务估计是在冲刺开始时进行的，以便计划冲刺结束时可能完成的工作量，此时已完成的工作交付给客户。 它可以帮助您查看产品开发的进度，接收客户的反馈并根据客户的愿景调整项目的开发。但我们仍然有点离题：让我们回到估计。仅由一名开发人员评估任务过于主观。因此，通常来说，这是团队合作。团队评估有很多技巧。今天我们就来看看其中最常用的——Scrum 扑克。这项技术需要一位经理，他将是像这个Scrum 扑克游戏的领导者那样的人。这可能是专门从事Scrum Master或PM的人。

什么是 Scrum 扑克

Scrum 扑克- 或计划扑克 - 是一种基于达成协议的评估技术。主要用于评估软件开发过程中未来工作的复杂性或要解决的任务的相对量。我会立即指出，Scrum 扑克是开发中的常见做法，您肯定需要知道它是什么样的野兽。对于此过程，我们通常使用某种应用程序或网站来组织对特定任务的团队评估。这是怎么发生的？团队采用待办事项（新任务、功能），简要讨论可能的陷阱以及与之相关的其他细微差别。然后每个参与者选择一张卡片，上面的数字代表他们的难度等级。哦，对了，估算的时候，用的不是通常的级数，而是斐波那契数列。 斐波那契数列在Scrum 扑克中非常流行，因为它们之间的差距随着时间的推移而增加（让人想起金字塔级别）。有些任务非常复杂，并且少量的故事点无法实现。 异常卡牌说明：

端点数量未知

无限长的任务

需要休息一下

更罕见的估算方法：

• T 恤尺码 - S、M、L、XL
• 或者狗——吉娃娃、哈巴狗、腊肠犬、斗牛犬等（在我看来，这是评估任务的最奇怪的单位=D）

然后，团队会比较不同开发人员对同一问题给出的估计，如果他们同意，那就太好了！如果不是，就有必要讨论评估差异的原因（论据）。之后，我们可以共同得出一个单一的估计，每个人，无论是正数还是负数，都会同意。那么，为什么扑克甚至被用来规划一个严肃的软件项目呢？毕竟，这有些奇怪。事实上，这种游戏化鼓励团队成员独立思考，要求他们与队友同时展示自己的成果。这反过来又避免了依赖其他团队成员的观点。否则，经验不足的开发人员将查看并依赖经验丰富的团队成员的评估，这将否定他们自己的评估的有用性。但随着成绩同时公开，这基本上是不可能的了。Atlassian是 Scrum Poker 调度应用程序的一个示例。

任务评估示例

让我们假设您的团队已经确定了一定的故事点评估尺度： Scrum Poker从一项任务开始，您可以这样评估它：

• 您以前从未使用过类似功能的实现 - +3
• 中型任务的功能 - +2
• 任务的实施具有较高的复杂性 - +3
• 为此功能编写测试的复杂性很高 - +3

结果，您获得了 11 个故事点，但由于没有这样的卡片，您提供了 13 个故事点。您的另一位同事评估了该任务：

• 之前遇到过类似的问题 - +1
• 中型任务的功能 - +2
• 任务的实施具有平均复杂度 - +2
• 为此功能编写测试的平均复杂度 - +2

结果，他得到了 7 个故事点，但斐波那契数中没有这样的东西，他放了一张最接近的数字 - 8 的卡片。其他团队成员相应地根据他们的主观观点给出估计。接下来，您展示结果，发现几乎所有同事都给出了 13 的估计值，除了一名开发人员给出了 8 分。在这种情况下，他获得了发言权并给出了理由。举个例子，他们是这样的：他以前也解决过同样的问题，而且这并不像看起来那么困难，最后他说服了其他团队成员将他们的解决方案从 13 故事改为 8 故事点，说他会帮助任何承担这项任务的人解决这个问题。或者，最终，他会自己做。一般来说，其他人是否听他的论点并不重要，因为无论如何，都会为这项任务分配一个评级，而团队将继续熟悉下一项任务。 第一次，估计将不准确，您计划在下一段时间（冲刺）完成的工作量的估计也是如此。毕竟，这些估计都是根据估计精确做出的。一段时间后，大约三个月，团队将开始更准确地估计任务，并且团队每个冲刺可以完成的平均工作量将变得可见。但这是工作范围的总体规划，更多的是时间问题，在这种情况下可能有很多不同的因素会产生影响。例如，一位开发人员休假了两周。也就是说，您需要划掉一定量的计划工作（计划功能）。或者一个新的开发人员加入了团队，但你不需要完全依赖他，因为…… 你需要考虑适应项目所需的时间，称为入职。这可能是两周，加上或减去一周，具体取决于项目的复杂程度。 今天就到这里了，希望我对问题估计这样的非技术性知识部分的知识有所提高。如果您想更深入地了解这个主题以及 Scrum 的细节，我强烈建议您阅读 Jeff Sutherland 所著的《SCRUM》一书。我不能保证后果，因为也许之后你会产生成为 Scrum Master 的恼人愿望 =D