不要估计峰值
你是否应该估计一个峰值?
什么是尖峰?
在敏捷软件开发中，峰值是在开发团队运行定时调查之前无法估计的故事。峰值的输出是对原始故事的估计。
在Sprint Zero中选择完成所有冲刺
如果你在每个版本中执行所有峰值“Sprint 0”,你可以估计他们。如果你这样做了，那么你的速度是可靠的。
如果你不估计峰值，你的Sprint 0臀部冲刺可能没有意义。没问题。当计算你的平均速度和发布计划时，你可以排除Sprint 0或HIP Sprint——当计算你的平均速度时，不要把它们算在除数中;发布计划时不要给他们分配点数。
即使你在Sprint 0中完成了所有峰值，在发布期间也会出现额外的峰值。对于那些，不要出于同样的原因去估计它们我不评估缺陷。
在Sprint Zero中选择不做所有的冲刺
积压的工作数量激增代表着风险。它们通常对应的是未估计的用户故事和模棱两可的故事——在我们估计之前，我们需要对这些故事进行研究。由于这些原因，我们希望在每次发布之前消除峰值。(我假设是定期发布——面对持续规划和持续部署时的优先级峰值是另一回事。)
然而，峰值确实会在我们稍后的发行版中作为计划外的工作出现。那样的话，我还是想尽快处决他们。我还是不想估计它们。
因此，对我来说，峰值不会在积压中停留很长时间。我很少认为它们是有计划的工作，和故事的顺序是一样的。我可能已经计划好了接下来4个月的故事，但我不希望出现大量无法在接下来2个sprint中执行的峰值。这不是关于阻止峰值。它是关于快速解决它们就像我想要做的缺陷。这是关于没有大量未解决的峰值积压，就像缺陷一样。
我们从估算用户故事中获得的一个巨大好处是，估算可以使工作更加清晰。评估可以帮助我们澄清我们的接受标准。清楚工作、目标和验收标准对于峰值和用户故事一样重要。但估计并不总是能达到这样的清晰度。有时候我们会变得懒惰，尤其是在刺钉的时候。所以，给他们设定一个小的时间限制是另一种鼓励清晰的方式。我喜欢为他们制定明确的政策。例如，一个团队的政策是，所有峰值必须在12个小时或更少时间内完成，每个峰值必须有一个明确的问题需要回答，我们必须知道答案是给谁的，并且必须有一个“演示”。没有模糊的峰值和模糊的结果。
结论:不要估计峰值
因此，无论您是在Sprint 0中完成所有的峰值，还是将它们分散到发布过程中，我都不希望它们停留很长时间，至于缺陷，我也不进行评估。我选择了不包括速度峰值的毒药。我不想让速度膨胀。对缺陷和峰值的估计与我们对故事的估计是不同的(相对于彼此)。我们很难准确地将其与以小时或天为单位的1点故事进行比较。缺陷也是一样——这是一种与普通故事开发非常不同的工作类型。
评论(11)
资本化附录:一般情况下，峰值应资本化。如果有些事情在技术上不可行，比如用基于二锂晶体的曲速驱动系统把人送上太空，或者把蓝牙的有效范围扩大一倍，那就只能是研究，必须花钱。但是大多数软件开发公司所做的一切在技术上都是可能的。我们可能不知道该如何着手，但我们知道我们能找到技术上的解决方案。我们可以资本化。
如果你一次性处理了所有峰值，例如在“sprint 0”或发行之间的sprint中，即在一个明确的时间范围内，即大约100%的资本化工作，那么你便不需要进行任何估算。把这一周、冲刺或一段时间资本化。
如果您在整个发布过程中出现峰值，并且它们很少出现，那么您可以认为它们在GAAP下不是Material并忽略它们。
如果在整个发布过程中出现峰值，并且在GAAP下它们是Material，那么你必须在你的sprint中进行非资本化的工作(例如修复功能的回归，这些功能曾经起作用，并在之前的纳税期间资本化)。在这种情况下，你要么追踪它们的时间(呃)，要么估算它们。但是如果您估计了它们，那么您要么将它们从您的开发速度中排除，要么将它们作为添加到发布计划中的范围中。在任何一种情况下，您都需要很好地了解您的ALM工具，特别是在面对变更的评估时它是如何计算速度的，以及它是如何报告范围变更的。
咪咪
缺陷来自于用户场景。你为什么不估计一下呢?当然，他们正在努力修复这些问题?另外，如果一个故事点是以同样的方式产生的，那么为什么要根据一个故事点来估算它们呢?
莱昂纳多Kasperavicius
@Mimi:如果你说的是Bug票据(游戏邦注:与Spikes不同)，能否估算它们取决于很多因素。例如，如果约定总是创建相同大小的用户故事，你可以说你可以估算它们，是的。但如果你已经不知道最初的故事了呢?
在我目前的团队中，我们根据之前的历史为Spike设定了一个默认的故事点数量，并决定不去评估漏洞，因为我们通常不知道它们来自哪里。在结束之前，开发者需要设置或更新这两种类型的故事点，以便更好地了解我们的开发速度。
我的想法是，这没有什么神奇的规则或公式。最终，这一切都是关于团队能够理解一个Sprint将是什么样子，并对它感到舒服与否。
拉吉
虽然我完全同意峰值是什么，但我不认为我可以同意“不要估计峰值”的说法。在企业中扩展敏捷时更是如此。没有预估的冲刺阶段的峰值意味着团队可能会为冲刺超载。虽然估计这一点确实很困难，但我相信，团队应该与产品负责人达成共识，并分配一个故事点值。这可能不会反映完成冲刺所需的工作量，但这个数字决定了团队在当前冲刺中愿意在这方面花费多少。这将有助于进行速度和容量规划。
安德鲁·福
请记住，我的背景是提前3到8个冲刺阶段做出承诺(和发布计划)。在这种情况下，点和速度最适合用于发布/承诺计划，而不是sprint计划。
团队不应该为了避免在sprint中过度投入而需要积分。他们的团队应该在sprint计划中做足够详细的计划，这样点就无关紧要了。
我想说的是，峰值不应该出现在待办事项中太长时间，应该在第一两个冲刺阶段就完成。因此，它们不能帮助你提高速度。对于保守的发布计划，您希望在速度中包含更少的内容，而不是更多。你不需要知道冲刺计划的速度或要点，因为这个计划是(应该)在较低的水平上完成的。
亚伦
是的，这对我来说是有道理的。谢谢!
杰弗里·巴恩斯
嗨,安德鲁,
感谢你把这篇文章放在一起，告诉我们不要估计峰值。这是一本好书。我特别觉得你关于选择不做冲刺0所有冲刺的想法很有趣。
保持这些有见地的帖子。
干杯!
苏米特
如果你不评估和工作在高峰，那么无论如何你使用你的能力。
计划外的pOC也很重要。那么如何考虑速度和容量呢?
亚历克斯Elentukh
关于峰值的定义，“在敏捷软件开发中，峰值是一个故事，在开发团队运行一个定时调查之前无法估计。峰值的输出是对原始故事的估计。”我们说的是两个截然不同的故事，第一个是原始故事，第二个是斯派克。Spike是一个敏捷故事，由于敏捷故事的优点，它确实是时间有限的。我喜欢这种说法，“Spike的输出是对原始故事的估计”。然而，定义的第一部分比它应有的强得多。假设，有人坚持估计峰值。有人想确定他的调查范围。你可以试着说服他。但说这是不可能的，说他做不到这一点，显然有些言过其实了。 In fact it undermines the whole definition of a Spike given here.
卡洛斯·J。
同意了。通过估计Spike，我们估计了了解未知事物的任务。我们没有评估最初的任务，因为这就是为什么我们要做一个Spike。虽然我们都同意这很难估计，但也不是不可能。它确实有助于识别、定义和界定我们的未知事物，以避免“模糊的峰值和模糊的结果”。通过这种方式，我们开始知道什么是我们不知道的。我们开始知道周围是否有人真的知道，或者知道一些。您确定资源、资源(书籍、论坛、中小型企业、制亚傅体育app造商文档等)和接近它们的方法，以便获得或收集您的答案(面对面的会议、购买那本书和阅读那部分内容、询问这个中小型企业或这个中小型企业论坛)、创建和运行这个测试，等等。我认为这是可估计的，尽管我想说它总是伴随着大量的风险威胁着这一估计(如资源可用性)。亚傅体育app
当你对自己的问题没有答案时，时间限制而不是估算可能会让你停下来。虽然峰值估计可能有很大的误差范围，但它增加了我们找到问题答案的可能性，并真正解决了问题，而问题不会因为你的时间限制结束而消失。
因此，我不会说“峰值是一个在开发团队进行定时调查之前无法估计的故事”。我想说的是，这个峰值是限时调查本身，或者更确切地说，是限定和估计的调查本身。它的输出，远远超出了对原始故事的估计，可能是一堆有价值的信息(对团队有价值，而不是对用户)，例如:概念验证，如何做，可能的障碍和风险，“这实际上是可行的”。
我同意它们应该简短，因为它们占用了对客户有价值的工作的时间。所以也许我们可以估计，也可以为找不到答案的最坏情况设定时间，这样也许我们可以把这项任务委派给专门的研究团队。
如果你们在时限内找不到答案，你们会怎么做?