如何通过敏捷中的 QA 工作来确定团队成员的速度

问题描述

我想了解敏捷冲刺中团队成员的速度计划计算以及 QA 工作。我举个例子来解释一下：

假设，我的速度是每次冲刺 5。这意味着，我可以在每个 sprint 中选择最多 5 个故事点。

现在，我们整理了一个用户故事，它需要从 DEV 方面做很少的工作（1 分），但对于 QA 预期，这是 5 分，因为由于这一小变化，他们需要测试完整的应用程序。因为我们的故事点是基于团队决定的，所以我们决定采用 5 个故事点。

这个用户故事是分配给我的，所以这意味着，我已经为这个 sprint 计算了 5 个故事点，根据我的速度（5），我已经完成了这个 sprint。

但正如我上面提到的，这个故事需要 DEV 方面的很少努力（1 分）所以它是一种错误的信息或对我实际工作的错误解释。

所以我的问题是，在我们需要在多个团队成员之间为同一个用户故事分配工作的情况下，特别是在 QA 的情况下，我们如何正确定义或计算特定团队成员的速度。

解决方法

我不认为速度会在这里帮助你。这是我用于速度的定义：

“一个团队在一个 Sprint 中完成的工作量”

Velocity 帮助我们进行计划，在这方面使用时它很有用。当一项措施成为目标时，它就不再是一个好的措施。 （古德哈特定律）

在考虑您的问题时，我担心需要确定个人的表现。我怀疑，检查这样做的动机可能会提出可能更有用的不同问题。

,

速度是为团队计算的，而不是为单个团队成员或职能计算的。

这样做有几个原因，包括：

• 所有团队成员都为最终产品的质量做出贡献，因此将 QA 工作分开是没有意义的。例如，专家 QA 可能会与开发人员和产品负责人讨论可疑的缺陷，开发人员可能需要进行返工以修复它。质量检查是一项团队工作。
• 只有完全完成的工作项才具有任何价值，因此在开发过程中跟踪步骤的完成情况几乎没有价值。事实上，跟踪这些步骤可能会适得其反，给人一种进步的错误印象。