在我们的迭代计划中，我们经常发现自己处于与这个人相同的位置 - How to estimate a programming task if you have no experience in it
我绝对同意原型设计，然后才能给出合理的估算。但这同样适用于任何需要一些架构和设计的东西 - 但是我不太习惯在sprint的范围内完成所有这些。
基本的想法是，您可以确定尽可能多的任务，并将其估计为正常。对于那些你不确定的领域，应该确定两种“类型”的任务：调查＆amp;实施
调查任务是您不确定的工作的简要描述，例如“调查如何将Control X绑定到数据”。为这些提供估计。
实施任务是传统的粗略猜测，可能基于所分配的故事点，您认为实施该功能需要多长时间。
在冲刺期间，当调查任务完成后，开发人员应该处于一个可以更好地了解正在发生的事情的阶段。然后可以识别“正确的”任务，这取代了实施占位符。此外，可以在此阶段确定进一步的调查任务，并继续循环。
在上面的例子中，我们从7小时开始调查任务，估计14开始执行任务。第一次调查完成后，将确定任务1,2和3，并在一定程度上确定，任务3是另一个调查任务，任务4和5将在稍后阶段确定。正如您所看到的，第一个实施估算在14小时内交付了该功能 - 但实际情况是它至少需要4 + 7 + 3 + 4 + 2 = 20.比初始估算多三分之一。
alt text http://www.duncangunn.me.uk/myweb/images/estimate.png
欢迎所有的想法 - 我的直觉是这会飞 - 我是对的还是错误的兄弟？
干杯！
答案 0 :(得分：3)
我们做什么。
某些功能涉及新技术。我们无法准确估计它们。期。
我们编号。基于一些事情。它有多难“感觉”？我们可以通过某种“部分”或“恰到好处”的实施来实现吗？
如果这很难，那就很难了。这将是昂贵的。
如果有很多部分，内核的优点和一些奖励的东西分层，我们有可能只将内核放入一个版本，并将其他东西放在一边稍后。很少有东西是“全有或全无”，部分释放是不可能的。在这种情况下，我们必须为“所有”提供足够的时间，并且这会花费很多。
我们的标准方法是获取有效的东西，如果由于意外的复杂性而耗尽时间，可能会将事情推迟到以后的冲刺阶段。
你称之为“调查”，我们称之为技术尖峰冲刺。对于新的东西，我们编制估算数字来安抚那些觉得有必要过度计划事情的经理。然后我们加入了这项技术。一旦飙升，我们可以根据我们现在所知道的情况修改估算值。
答案 1 :(得分：2)
实际上，该功能的实施花了27个小时 - 你忘记了7个小时的第一次调查，所以实际上实际执行的时间几乎是估计的两倍。
有两种方法可以解决这个问题：
第一个选择意味着您的冲刺和项目估算有点武断。第二种选择为你的短跑提供了更多的可预测性。
在您的示例中，可能会为Sprint 1安排初步调查，但不知道任务需要多长时间，产品负责人无法决定如何安排它。如果您回来估计200小时，产品负责人可能会决定不再执行该功能，或将产品所有者延迟到产品版本2。估计进入并且产品负责人安排任务1，任务2和Sprint 2的任务3的调查。在估计任务3之后，可以在Sprint 3或更高版本中安排任务4和5。
答案 2 :(得分：0)
估算功能通常是一项复杂的任务。一段时间后，您的估计会变得更好。但好的方法可能是你用故事点估计特征。故事点是表达问题复杂性的抽象价值（意味着团队之间的意见）。 您应该为相似复杂度的特征分配相同的复杂性（相同数量的故事点）。然后稍后只需估计较小的特征集（或查看历史数据）就足够了，您应该能够估计需要多长时间。
具有类似复杂性的功能需要类似的实施时间。
