【发布时间】：2008-10-06 17:40:47
【问题描述】：
您好，我是 Scrum 方法的新手，我正在寻求一些帮助以适应环境，并想知道是否需要一个存储桶来跟踪开发人员和 QA 花费在部署、错误修复和重新测试上的时间。似乎它可能会对图表产生重大影响。
【问题讨论】：
【发布时间】：2008-10-06 17:40:47
【问题描述】：
我的团队正在支持许多旧版应用程序，因此在每个 sprint 期间都会发生相当多的计划外错误修复。我们采用了以下做法：
- 如果错误很容易/快速修复（一个班轮等），那么只需修复它。
- 如果 bug 不是微不足道的，也不是阻碍，则将其添加到 backlog。
- 如果错误是一个障碍，则添加一个任务（到当前 sprint）来捕获修复它所需的工作，然后开始处理它。这需要将其他内容（从当前 sprint）移至积压工作以考虑新的小时数，因为您的可用总小时数没有改变。
当我们添加新的错误任务时，我们会将它们标记为与计划任务不同的标记，以便在 sprint 审查期间轻松查看它们。有时计划外的工作最终占我们 sprint 的 50% 以上，但由于我们将计划中的项目推到积压工作中，我们很早就知道我们没有交付我们计划的这个 sprint。
事实证明，这对于我们的团队在处理遗留应用程序时非常有用，因为我们没有人像我们希望的那样熟悉或对系统充满信心。
【讨论】：
-
感谢您分享知识。这确实是我一直在寻找的东西，以改善我们的实践。这是一个很大的帮助。再次感谢
在冲刺期间发现的属于该冲刺的错误应该自动修复，就好像任务/故事一开始就没有完成一样。以前的 sprint 中出现的错误可以输入到 bug-backlog 中，并像正常的 backlog 一样确定优先级。
编辑：刚刚意识到通过提及“错误积压”，我打开了“多个积压”，这是一个坏主意。更好的方法是用错误标志标记积压中的条目，或者只是接受它作为积压中的任何其他故事。
冲刺中出现的严重错误的数量应该最少，因为在冲刺结束时，所有内容都已经过测试，然后才被接受并交付给项目所有者。
实际上它不应该影响图表，因为您将承诺修复一定数量的错误（通过 PO 的选择 - 一些错误的优先级低于新功能）以及当错误从 sprint 本身出现时，嗯任务确实没有完成，所以可以意识到这一点并花时间修复它。
编辑：意识到其他事情 - 有时在 scrum 团队中工作并不能总是保护您免受必须维护其他应用程序、支持等的现实。虽然这真的很糟糕，并且使整个团队的想法单一的积压工作和重点并没有真正起作用，现实情况通常是您需要每周保留固定的小时数来进行支持/维护。不要鼓励这样做，但如果这是现实，请尝试每周分配一个人（轮换，这样他就不会变得悲伤）固定的小时数专门用于所述支持角色。这样一来，您就知道会发生什么，因为速度是相对的——它似乎对冲刺的影响较小。
【讨论】：
-
是的，我在上面添加了评论，但是有些团队在发布新版本之前以发布冲刺结束。一些团队在每个 sprint 之后发布，但他们通常非常擅长在 sprint 期间发现错误（他们可能有非常好的测试和实践来开发“无错误”）
-
感谢您的评论。如果我们决定将这些错误与原始 sprint 桶联系起来，我们仍然必须计算我们在 sprint 中某处修复和重新测试所花费的时间。因此，它可能会在图表中产生额外的几个小时的峰值或其他东西，从而影响结果
-
Spikes 没问题 - 如果您在 sprint 中发现问题，您会重新估计并重新计算剩余的工作量。这通常会导致烧毁趋于平缓，甚至出现飙升。
我倾向于处理这个问题的方式是将错误修复移到 sprint 之外。因此，在演示/发布之前，可能会在三周的冲刺之后进行一周的错误修复。
这不是一个理想的解决方案，因为没有尝试估计将在错误修复阶段修复的错误数量。所以我期待其他人提供比我更好的解决方案。
【讨论】：
-
您好，您可能在 Scrum 期间遇到了一些高级或严重错误，需要立即引起开发人员的注意，因此可能会对其余可交付成果产生影响。
-
一个巨大的严重错误仅在新版本发布之前出现的可能性有多大——就像大卫提到的那样，发布冲刺当然会更专注于修复/关闭错误。
-
它不仅在发布之前，而且在冲刺期间，一些错误可能需要比预期更长的时间，我的问题是我们如何计算这些时间。我认为它应该在原始预期猜测的基础上增加额外的时间，这可能会影响图表
-
请记住，您不会跟踪花费的小时数，而是剩余的小时数 - 有或没有新的错误。比预期更长的任务或冲刺期间发现的错误/东西可能会导致剩余小时数增加。
-
是的，这将使事情超出预算，因为我们没有添加其他资源，并且通过保持剩余时间的小时数，我们通过不直接报告来准确地预算这些东西我们花在错误修复上的时间
我认为在诊断出问题之前很难估计修复错误的工作量，而诊断通常是花费时间的最大部分。
如果你的 bug 数量相当一致，我会让它“在洗涤中出来”而不是速度。对于影响团队迭代目标的生产缺陷，我通常会这样做。
如果您在迭代过程中发现由于错误问题而落后（例如，您看到燃尽图看起来不会在迭代结束时与您的范围线相交），那么您可以调整范围（放弃最低优先级的故事）以适应额外的工作。
【讨论】：
在每个 sprint 中，我有两个“任务”——一个针对在当前 sprint 中发现的错误（即在未发布的代码上），一个针对在其他任何内容中发现的问题（任何发布的版本）。这有助于我跟踪（每个开发人员）修复错误所浪费的时间。
后一类记录的任何时间都被视为浪费，是减少的关键目标。对前者的登录时间进行了审查，以了解如何将其与导致它的功能和更改更紧密地联系起来。
不要针对错误进行估算，而是尝试将这段时间添加到针对您正在开发的功能进行单元/功能测试的估算中。
随意调整任何模型以适应您的团队的工作方式 - 在任何 Scrum 团队中都应该有一种持续改进的文化，并且开发人员应该能够在学习 Scrum 时提出建议并尝试改进。
【讨论】：