可能是主观的和/或讨论的......但这里有。
我被要求为工作中的下一件大事估计一个功能。我把它分解..使用故事点来估计。然而，除了各种其他公司计划之外，该功能还需要与第三方图表组件 GoDiagrams 进行交互。（一整套 2008_Limited_Edition 框架/服务：）。我一直在使用燃尽图跟踪自己，我发现我无法维持我的步伐主要是由于“尖峰”..定义
我估计每周工作 2 点，然后我发现自己在周末工作（很好地尝试......最终既不在这里也不在那里），因为我不知道在哪里挂钩，以便我可以预览用户操作，显示上下文菜单等。最后，我花时间制作尖峰，使我的日程表偏离轨道……并降低其价值……没有给出正确的画面。
钉子需要钉子穿过无知的木板。但是它们是如何被纳入估计方程的呢？在功能看起来错误之前执行所有必需的尖峰..（可能会变成 YAGNI）在两者之间执行它会破坏我的流程。现在它是在预迭代计划期间..但这每周都会将接触线推开。
我猜你一直在低估
1. 更好地估计这两件事。
所以，这一切都与经验有关。无论您使用哪种方法，它们都会帮助您更好地使用您的体验，而不是取代它。
2. 在处理这些尖峰时尽量不要迷失方向。
它们应该是简短的、有时间限制的会议。他们并不是要玩弄营销幻灯片上列出的所有可能的功能。给他们专注，两到三个选项去探索。期望他们提供一个具体的结果。
更新（Gishu）：总结
如果您的时间盒峰值时间用完了，您仍然应该停止并完成其他已提交的工作。然后，您应该在下一次迭代中添加另一个尖峰，以完成您需要完成的必要工作，以便准确估计尖峰产生的任务。
如果有人担心让事情变得太长并且这成为一个问题 - 这就是我喜欢 1 周迭代的原因之一。:-)
@pointernil .. 再加上 Indy-Jones Head-First 方法来处理故事，这更像是没有估计。我根据故事的内容来估计故事。目前我没有考虑找到正确的咒语以使控制库发挥出色所需的时间。这有时比我的应用程序逻辑花费更多的时间。所以重新表述原始问题，尖峰是否应该是迭代计划中的单独任务，在您开始处理特定故事之前在 JIT 基础上添加？
我的 Spikes 非常专注……我迫不及待地想回到“真正的”问题。例如“我如何显示这个控件的上下文菜单？” 我可能会因为没有阅读整个 150 多页的手册或代码示例而感到内疚……但是时间很紧。解决问题的第一个解决方案得到了点头，我继续前进。但是，当您无法找到组件使用的难以捉摸的事件或 NIH 通知模式时，峰值可能会很耗时。我如何对未知的事物进行时间限制？例如，我的时间盒已经过去，我仍然不知道插入我的自定义上下文菜单。我该如何进行？继续黑客攻击？
也许这出现在“缓冲不确定性”方案中。如果我在 Mike Cohn 的书中找到有用的东西，我会看看。
我同意指针。唯一的问题是您的估计不正确。这没什么大不了的，当然除非你刚刚完成了一个 300 万美元的项目 :-)
如果它发生一次，它的学习经验。如果它再次发生并且结果更好，那么您将获得另一种学习经验。如果你经常低估并且你的百分比越来越差，你需要明智一点。没有任何方法可以让你摆脱困境。
尖峰只需要给予他们需要的时间。根据我的经验，我经常看到的一件事是人们希望能够在几个小时或一天内确定一项技术。这只是在现实生活中不会发生。最简单的问题，即使是由拼写错误引起的错误，也可能让开发人员花费大量时间。诚实地说明自己或您的员工的能力，并将其纳入预算。