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

Question

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

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

现在，我们整理了一个用户故事，这需要 DEV 方面的非常小的努力（1 分），但对于 QA 预期，这是 5 分，因为由于这个微小的变化，他们需要测试完整的应用程序。由于我们的故事点基于团队决策，因此我们决定使用 5 个故事点。

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

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

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

Answer 1

我认为速度在这里不会对您有所帮助。这是我对速度的定义：

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

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

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

Answer 2

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

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

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