project-management - 冲刺速度计算

<分区>

需要一些关于计算冲刺团队速度的建议。

我们的团队通常由大约 4 名开发人员和 2 名测试人员组成。 scrum master 坚持认为每个团队成员都应该对速度计算做出同样的贡献，即在计算我们在冲刺中能做多少时，我们不应该区分开发人员和测试人员。根据 Scrum，这是正确的，但这就是问题所在。

尽管有相反的建议，但测试人员从不帮助完成非测试任务，而开发人员从不帮助完成非开发任务，因此我们根本不是跨职能团队成员。此外，尽管有各种建议，测试人员通常会在每个冲刺的前几天等待要测试的东西。

最终的结果是，通常我们承担的开发工作远远超过我们在冲刺中的实际能力。例如，开发人员可能会花 20 天时间进行速度计算，而测试人员可能会花 10 天时间。但是，如果您在 sprint 计划之后添加任务，则开发任务加起来为 25 天，测试任务加起来为 5 天。

你们是怎么处理这种情况的？

最佳答案

我们也在为这个问题而苦苦挣扎。

这就是我们所做的。当我们将容量和任务相加时，我们会将它们加在一起和分开。这样我们就知道我们没有超过每个组的总时间。 (我知道这不是真正的 Scrum，但我们有 QA 人员不编程，因此，为了最大限度地利用我们的资源，他们最终进行测试，而我们(开发人员)最终进行开发。)

我们做的第二个想法是我们真正专注于切片工作。我们尝试选择最先完成的任务，这些任务可以快速交给 QA 人员。这样做的诀窍是您必须专注于完成最少的可测试量并将其移交给测试人员。如果您试图完成整个“功能”，那么您就错过了重点。在他们等我们的时候，他们通常会制定测试计划。

这对我们来说仍在进行中，但这就是我们尝试做的方式。

关于project-management - 冲刺速度计算，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48386/

相关文章：

agile - Scrum 燃尽模式