project-management - Scrum 和项目预估时间

Question

<分区>

Answer 1

对于给定的预算，您知道可以完成多少次迭代。然后，产品负责人应该对工作进行优先排序，以获得产品待办列表的最大值(value)。这就是敏捷的工作方式，固定时间和团队规模，范围可变(敏捷是关于范围管理)。一旦团队速度已知，您就可以预测可以完成多少工作(以点为单位)(冲刺次数 x 速度 = 可以完成的工作量)。

通常，客户不明白，想要“他们认为在给定时间需要的一切”(即固定范围)。在这种情况下，您最终需要进行某种前期分析，将所有内容分解为足够小的项目以进行估算。完成这项工作后，您可以通过猜测速度(# of sprints = total size/velocity)来预测需要多少 sprint。对于具有瀑布背景的人来说，这是一种非常常见的情况，并且通常会导致不准确的结束日期(固定范围和团队规模，时间可变)，因为您无法真正猜测速度，而项目的开始是最糟糕的时刻做估算。

在这两种情况下，您都需要速度。问题是速度实际上是 1) 在团队开始工作之前未知 和 2) 将随时间变化。

要解决 1)，您可以估计 猜测第二种情况中讨论的速度，但这不是很“敏捷”。理想情况下，您应该让团队开始测量实际速度(这在早期迭代中可能不准确)。中间场景是先给出一个非常粗略的估计，并在您收集了更多关于项目的知识并减少了不确定性后，在几次迭代后用更精确的估计返回给客户。

为了解决 2)，我随时间跟踪测得的速度，并使用最近 3 次的最高和最低速度以及平均速度冲刺作为工作假设。这使我能够(分别)做出乐观、悲观和现实的预测。