估算任务的时间

Gre*_*reg 6 scrum estimation

我们刚开始在公司做scrum.我们花了一些时间来估算使用计划扑克的努力,然后在详细任务完成后,对每项任务进行时间估算.

我们遇到的问题是时间估计总是错误的(通常估计过高).虽然我们都同意一项努力,让一个团队就任务的时间达成一致意见要困难得多 - 每小时需要1个人可能会花费3个小时.我们最终走到了中间的某个地方.

谁应该提出任务的时间估计以及何时发生?

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

ing*_*ere 10

实际工作的人估计所涉及的成本.如果您使用原始时间作为估算的度量标准,那么敏捷方法就会对此不以为然.您的团队应该使用抽象来估算成本,例如"积分".您可以从每点1小时的粗略基线开始,最少1点.然后开发人员可以对事情应该花多长时间进行原始估计.如果他们在几个小时或任何其他时间单位讲话,请将他们或其他任何人摔在手腕上.

关键在于,随着开发进行多次冲刺,项目经理可以调整团队提供的"点"时间估计以匹配现实 - 甚至可以按照每个开发人员进行.随着项目的进展,参与者将在评估中变得越来越好.因此,由于Sprint是一个迭代过程,时间估计会随着迭代次数的增加而改善.

这引出了另一个问题:你为什么担心时间?时间基本上是瀑布模型的成本.在Agile中,目标是将软件开发为VALUE而不是成本.使用的原因是,它是一个抽象的比较基础,企业所有者,项目经理和创造者(开发者)都可以在抽象的视野中查看.(不偏不同参与者对时间的文化,社会或心理认知.)企业主可以查看给定冲刺中的可用点 - 并了解可用点 - 他们可以选择最重要的功能.这总是一个艰难的决定,但同样,目标是发展价值,远离时间拳击或功能填充.

  • 正如ingyhere所说,你不应该使用原始时间进行估算 - 或者更好:你不能将时间用作Scrum的成本价值.你的问题的解决方案:坚持到故事的点,但不要估计单一的故事情节.如果你想创建你的燃尽,计算任务并将故事点与任务计数分开 - 例如,故事是8分,你有4个任务,所以每个任务的值为2分.如果你在白天解决2项任务,你的燃尽会下降4点. (2认同)