可能是主观的和/或者讨论的。

我被要求为工作中的下一件大事估计一个功能。我将其分解..使用故事点来估算。但是，该功能要求与GoDiagrams进行接口，除了其他各种公司计划外，还需要第三方绘图组件。(整套2008_Limited_Edition框架/服务：)。我一直在使用消耗图表来跟踪自己，但我发现主要由于"尖峰"而无法保持自己的步伐。

我估计每周要获得2分，然后我发现自己在周末工作(因此试图..既不在这里也不在那里)，因为我不知道要挂在哪里，以便可以预览用户操作，显示上下文菜单等。最后，我花时间制作尖峰，使我的时间表偏离轨道……并降低了它的价值。.没有给出正确的图片。

需要钉来钉钉子穿过无知的木板。但是，如何将它们纳入估算公式呢？在功能似乎出现错误之前执行所有必需的峰值操作。(可能是YAGNI)在两次执行之间执行会干扰我的流程。目前，这是在进行迭代前的计划中。但是，这每周都会淘汰接触线。

解决方案

我想你一直在低估

• 我们对第三方组件已经了解的内容
• 我们需要多长时间为未知区域创建可用/有用的峰值

1.更好地估计这两件事。

因此，一切都与经验有关。无论我们使用哪种方法，它们都将更好地利用体验，而不是取代体验。

2.在处理这些尖峰时，尽量不要迷路。

他们应该是简短的，有时间限制的会议。他们并不是要尝试使用营销幻灯片中列出的所有可能的功能。
给他们重点，探索两个或者三个选项。期望他们提供一个具体的结果。

更新(Gishu)：总结

• 尖峰需要是在迭代计划步骤中定义的显式任务。
• 如果峰值超过了时间范围，请停止处理。搁置相关任务。完成当前迭代存储桶中的其他任务。返回已搁置的任务，或者将更详细/细化的尖峰添加到下一个迭代以及相关联的任务。下次将更保守的估计值标记为第1代峰值。

@pointernil ..
几乎没有任何估计，再加上印地琼斯的"先入为主"的方法来处理故事。我通过故事的内容来估计故事。.目前，我没有考虑为控件库播放合适的咒语所需的时间。有时这比我的应用程序逻辑要花费更多的时间。.因此，重新表述原始问题，是否应该将尖峰作为迭代计划中的单独任务，并在开始处理特定故事之前基于JIT添加？

我的钉极专注。.我迫不及待地想回到"真正的"问题上。例如"如何显示该控件的上下文菜单？"我可能没有读完整的150多页的手册或者代码示例，这是有罪的，但是时间很紧。解决问题的第一个解决方案得到了点头，然后我继续。但是，当我们找不到组件使用的难以捉摸的事件或者NIH通知模式时，尖峰可能会很耗时。如何设定未知的时间？例如我的时间已过去，我仍然不知道插入自定义上下文菜单的任何线索。我该如何进行？继续骇客吗？

也许这是事物的"缓冲不确定性"方案。.我看一下我是否在迈克·科恩(Mike Cohn)的书中找到了有用的东西。

我同意pointernil。唯一的问题是估计不正确。当然，这不是什么大戏，除非我们刚刚完成了一个耗资300万美元的项目：-)

如果发生一次，则是一种学习体验。如果再次发生并且结果更好，那么我们将获得另一种学习经验。如果我们一直在低估并且百分比越来越差，则需要提高一些智慧。没有任何方法可以使我们摆脱困境。

只需给尖峰所需的时间即可。我所见到的一件事在我的经历中屡屡发生，是人们期望能够在几个小时或者一天之内完成一项技术。在现实生活中这根本不会发生。最简单的问题，甚至是由错字引起的错误，都可以使开发人员花费大量时间来拔头发。诚实地说自己或者员工的实际能力如何，并将其放入预算中。

如果我们在时间限制的峰值时间内用尽了时间，则仍应停止并完成其他已提交的工作。然后，我们应该在下一个迭代中添加另一个尖峰，以完成我们需要完成的必要工作，以便准确估算由尖峰导致的任务。

如果担心尖峰时间太长而成为问题，这就是我喜欢1周迭代的原因之一。 :-)