-1

我想了解敏捷冲刺中团队成员的速度计划计算以及 QA 工作。让我通过例子来解释它：

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

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

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

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

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

4

2 回答 2

1

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

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

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

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

于 2020-12-30T13:20:17.953 回答
0

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

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

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