scrum - 估计任务时间

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

3年前关闭。




Improve this question




我们刚刚开始在我的公司做 Scrum。我们花一些时间使用计划扑克来估算 Effort，然后在制定出详细的任务时，对每个任务进行时间估算。

我们遇到的问题是时间估计总是错误的(通常是估计过高)。尽管我们都可以就一项努力达成一致，但让团队按时完成一项任务要困难得多 - 一个人每小时可能需要 3 小时。我们最终会去中间的某个地方。

谁应该提出任务的时间估计，什么时候发生？

这只是我们需要更多练习的东西，还是我们做错了？

Answer 1

实际从事这项工作的人估计了所涉及的成本。如果您使用原始时间作为估算指标，那么敏捷方法会不屑一顾。您的团队应该使用抽象来估计成本，例如“点数”。您可以从每点 1 小时的粗略基线开始，最少 1 点。然后开发人员可以对某件事需要多长时间进行原始估计。如果他们以小时或任何其他时间单位说话，请拍打他们或其他任何人的手腕。

关键是随着开发在多个冲刺中进行，项目经理可以调整团队提供的“点”时间估计以匹配现实——这甚至可以由每个开发人员完成。随着项目的进展，参与者将越来越擅长估算。因此，由于 Sprint 是一个迭代过程，时间估计会随着迭代次数的增加而改进。

这就引出了另一个问题:你为什么担心时间？在瀑布模型中，时间基本上是成本。在敏捷中，目标是开发软件的值(value)而不是成本。之所以使用points，是因为它是一个抽象的比较基础，企业主、项目经理和创造者(开发者)都可以抽象地看待。 (不受不同参与者对时间的文化、社会或心理看法的偏见。)企业主可以查看给定 sprint 中的可用点——并了解可用点——他们可以选择最重要的功能。这总是一个艰难的决定，但同样，目标是朝着值(value)发展，远离时间限制或功能填充。