Scrum和Project估计时间

Ant*_*ney 3 agile project-management scrum methodology

如果客户要求我完成整个项目的预计完成时间,可以使用Scrum吗?

使用例如(可怕的)瀑布方法我将使用技术规范来进行半估计.

Pas*_*ent 5

对于给定的预算,您知道可以完成多少次迭代.然后,产品负责人应优先考虑工作,以获得产品积压的最大价值.这就是敏捷如何工作,固定时间和团队规模与可变范围(敏捷是关于范围管理).一旦团队速度已知,您就可以预测可以完成多少工作(以点为单位)(冲刺的数量x速度=可以实现的工作的大小).

通常,客户不会得到它并且想要"在给定时间他们认为他们需要的一切"(即固定范围).在这种情况下,您最终会进行某种前期分析,将所有物品制成足够小的物品来估算它们.完成这项工作后,您可以通过猜测速度(短跑的数量=总大小/速度)来预测您需要多少冲刺.这对于具有瀑布背景的人来说是一种非常常见的情况,并且通常会导致不准确的结束日期(固定范围和团队规模随时间变化),因为您无法真正猜测速度和项目的开始是最糟糕的时刻.估计.

在这两种情况下,你都需要速度.问题是,速度实际上是1)未知前球队开始工作,2)随时间变化.

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

为了解决2),I跟踪随时间测得的速度,并使用最高最低速度和平均最后3个冲刺作为工作假设的速度.这使我能够分别做出乐观,悲观和现实的预测.