估计任务时间[关闭]答案

【问题标题】：Estimating Time on Tasks [closed]估计任务时间[关闭]
【发布时间】：2012-03-13 13:21:47
【问题描述】：

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

我们遇到的问题是时间估计总是错误的（通常是高估的）。尽管我们都可以就一项工作达成一致，但让一个团队就一项任务的时间达成一致要困难得多——一个人一个小时的工作可能需要其他人 3 个小时。我们最终会走到中间的某个地方。

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

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

【问题讨论】：

许多开发人员对敏捷的理解不够充分，以至于他们认为这是一个“意见”问题并关闭了它。实际上，这是一个清晰简洁的过程，具有明确的计划和执行工作机制。如果你认为敏捷是一种观点，那你就没有在实践它。

标签： scrum estimation

【解决方案1】：

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

关键是，随着开发通过多个 sprint 进行，项目经理可以调整团队提供的“点”时间估计以匹配现实——这甚至可以针对每个开发人员进行。随着项目的进展，参与者的估计会越来越好。因此，由于 Sprint 是一个迭代过程，时间估计会随着迭代次数的增加而提高。

这引出了另一个问题：您为什么担心时间？在瀑布模型中，时间基本上是成本。在敏捷中，目标是开发价值而不是成本的软件。之所以使用积分，是因为它是一个抽象的比较基础，业务所有者、项目经理和创建者（开发人员）都可以抽象地看待它。（不受不同参与者对时间的文化、社会或心理认知的影响。）企业主可以查看给定 sprint 中的可用点——并了解可用点——他们可以选择最重要的功能。这总是有点艰难的决定，但同样，目标是朝着价值发展，远离时间装箱或功能填充。

【讨论】：

感谢您的回答。我们使用的是 TFS 敏捷模板，它在 PBI/Bug 上付出了努力，但个别任务有时间。所有的烧毁都发生在那个时候。这只是微软模式的一个短板吗？如果我们不设定时间，我们就不会燃尽全力告诉我们进展如何
正如ingyhere 所说，您不应该使用原始时间进行估算——或者更好：您不能在Scrum 中将时间用作成本值。问题的解决方案：坚持故事的要点，但不要估计单个故事任务。如果您想创建燃尽图，请计算任务并将故事点除以任务计数 - 例如，故事是 8 点，您有 4 个任务，因此每个任务的值为 2 点。如果您在白天完成 2 项任务，您的燃尽点将下降 4 分。
正如您所指出的，用于一项任务的时间取决于从事该任务的人。但是故事点的想法是不依赖于人。团队是焦点。所以这些点反映了团队需要付出多少努力来完成这个故事。只需对任务执行相同操作即可。如果您想单独估计每个任务的工作量，只需使用故事点。然后总和应该四舍五入到相应故事的故事点。

【解决方案2】：

“谁应该提出一项任务的时间估算，什么时候发生？”取决于你如何管理你的团队。您是否让团队成员真正地自我管理，以便在 sprint 期间有人抓住它时分配任务？根据团队中普通开发人员的能力，您可能必须继续使用时间来完成。您是否有团队负责人将任务分配给在 Sprint 计划会议期间创建的人员？让被分配的人估计完成任务的时间。

我同意从工作量估算中去除时间有点令人困惑。最大的问题是：你高估了任务时间有什么关系？团队是否在 sprint 结束时无所事事地坐了 4-5 天？如果是这样，请联系产品负责人，让她知道团队想要在 Sprint 中添加一两个小项目。你通常不会在正在进行的 sprint 中添加东西，但 Scrum 是一个管理工作的框架，只要团队同意添加新项目，就没有必要让 Scrum 为你的团队工作…… .不要强迫你的团队为 Scrum 工作。

此外，您的问题似乎表明您的团队比计划的速度更快。如果您的 2 周 sprint（10 个工作日）的速度为 10，但您的团队在第 7 天完成了所有工作，则只需将下一个 sprint 的故事点提高到 11 或 12。

【讨论】：

想知道为什么我的回答被否决了。
我的想法是，当敏捷尝试将时间抽象化时，答案是明确地谈论时间作为具体估计。（每个人都有自己的时钟，这就是为什么要使用积分来避免错过估计。）此外，敏捷不是团队领导进行繁重任务的框架。这表明该方法没有得到很好的应用。