将bug修复融入Scrum流程的最佳方法是什么？

Question

我在过去几天一直在研究和阅读有关Scrum的内容，并阅读有关Sprint规划和任务的内容。我脑海中浮现的一个问题是如何处理Scrum中的错误。 Henrik Kniberg在他非常好的书Scrum and XP from the Trenches中列出了处理这个问题的一些方法：

1. 产品所有者打印最多 高优先级Jira项目，带来 他们参加sprint计划会议， 把它们放在墙上 连同其他故事 （从而含蓄地指定了 这些项目的优先级相比 其他故事）。
2. 产品所有者创建引用Jira的故事 项目。例如“修复最多 关键后台报告错误， Jira-124，Jira-126和Jira-180“。
3. 错误修复被认为是 冲刺之外，即球队 保持足够低的焦点因子（对于 例子50％）确保他们 有时间修复错误。就是这样 简单地假设团队会 每个人花一定的时间 冲刺修复Jira-报告的错误
4. 将产品待办事项放在Jira中 （即沟渠Excel）。只是对待bug 像任何其他故事一样。

这真的需要根据每个项目来决定还是有更好的解决方案？我可以想到每种方法的问题。是否有混合物来自那些效果最好的方法？你如何在你的项目中处理这个问题？

Answer 1

这是一个非常好的问题，我对这个问题的不同方法有一些看法。

1. 在积极项目中平等对待所有错误在理论上听起来可能是一个好主意（在一个地方跟踪工作）但在实践中效果不佳。错误通常是低级别的，而且数量更多，因此如果您为每个错误创建单独的用户故事，那么“真实”故事很快就会变得模糊不清。
2. 如果以对产品所有者可见的方式完成，则为修复保留的每个sprint中的显式时间都可以。在每日Scrum期间应该提到错误，并且在sprint审核期间应该讨论修复的错误。否则，产品所有者将不会知道项目中发生了什么。
3. 将整个积压工具放入错误跟踪工具会导致与1中相同的一系列问题。此外，大多数错误跟踪器都没有考虑到Scrum，为此目的使用它们可能会很痛苦。

我们发现最令人满意的解决方案是在每个sprint上放置一个名为“Tickets”或“Bugs”的用户故事。然后，可以将这样的故事划分为描述特定错误的低级任务（如果在计划期间已知）或者为一般错误修复保留给定小时数的元任务。通过这种方式，产品所有者可以看到流程，而燃尽图则反映了进度。

请记住无情地关闭实际上是新功能的所有“错误”并为它们创建新的积压项目。还要确保在sprint结束之前修复针对当前sprint报告的所有错误，以便将sprint视为已完成。

Answer 2

实际上我认为最好的是jpeacock来自这个问题Do you count the hours spent on bug fixes towards the scrum?

让我引用它：

• 如果容易/快速修复错误（一个 班轮等），然后修理它。
• 如果错误不是微不足道的，而不是 阻止程序，然后将其添加到待办事项中。
• 如果错误是阻止程序，则添加一个 任务（到当前的冲刺）来 捕获修复它所需的工作， 并开始研究它。这个 需要移动其他东西 （从当前的冲刺）到 积压以计算新的营业时间 因为你的总时数可用 没有改变。

Answer 3

第一步是定义bug是什么。我教过一个bug只是一个bug，如果它的功能在生产中不起作用的意图/设计。这些成为错误类型的PBI，优先考虑新的开发。生产中缺少功能是一项功能，并成为正常的产品待办事项。在冲刺期间发现的任何有缺陷的代码被认为是不完整的工作，因为在完成当前的工作之前你不会继续下一个故事;因为团队总是在处理有问题的代码，所以没有必要在sprint中跟踪这些缺陷。 Post-it在这里非常方便，可以在队友之间快速提醒。修复损坏的代码总是先于编写新代码。如果缺陷是由于对故事的误解造成的，那么在开始讲故事之前，你需要研究你的接受条件。

库存是浪费。错误跟踪是库存。错误跟踪是浪费。

  

与积压项目同等对待所有错误在理论上可能听起来是个好主意（在一个地方跟踪工作）但在实践中效果不佳。错误通常是低级的，而且数量更多，所以如果你为每个bug创建一个单独的用户故事，那么“真实”的故事很快就会被掩盖。

如果你有比功能更多的错误，那么你需要处理你的工程实践。这是一种其他错误的气味，跟踪不是答案。深入挖掘。实际上错误总是很臭。它们并不酷，如果你有很多它们，你需要找到根本原因，消除它们，并停止专注于跟踪错误。

Answer 4

  

不要跟踪列表中的缺陷，找到它们并修复它们 - Mary Poppendieck

事实上，如果库存是浪费，那么缺陷库存会怎样......

这就是为什么我总是尝试通过测试驱动开发和持续集成来实现 Stop-the-Line 心态，以便我们找到并修复大多数缺陷，而不是将它们放在返工列表上。

当缺陷通过时，我们在编写新代码之前修复它们（无论如何都没有完成错误的故事）。然后，我们尝试修复我们的过程，使其更加防错，并在发生缺陷时检测它们。

Answer 5

没有一种尺寸适合所有解决方案，每个项目都不同。错误也可能被分类为关键任务，几乎不值得修复。

除非对系统的运行至关重要，否则我更喜欢将bug变成故事卡。这使得功能开发与错误修复的优先级非常明确。在错误修复被认为是“在sprint之外”的情况下，错误修复可能会转向修复真正微不足道的错误，而真正重要的业务功能尚未开发。

在将错误设置为故事方法之前，我们已经通过了许多排列。尝试一些不同的东西，并在团队复古会议上重播它们。

Answer 6

在我们的案例中（绿地开发，2-3个开发人员）发现错误被写下来，明确标记为错误，并根据其严重程度将其分配给下一次迭代或留在积压中。如果出现严重和紧急错误，则会将其添加到正在进行的迭代中。

Answer 7

我不知道为什么像修复bug一样简单的事情会因为规则而变得复杂.. Scrum的规则很少，还记得吗？ 每个功能，支持，推荐或缺陷都是Scrum中的Backlog问题，没有区别。因此，正如Scrum指南所说：  Sprint中的任务绝不仅限于您在计划会议期间决定的内容  每日Scrum帮助人们一路讨论“障碍”。

为什么呢？

如果您希望将缺陷（即积压问题）纳入PBI或保留在此Sprint中并提供它，那么您作为一个团队进行合理的讨论和思考......

Answer 8

更好的问题是如何在开发阶段停止创建错误？ 见 - ＆GT; http://bit.ly/UoTa4n

如果您要识别并记录错误，则必须在将来某个时间进行分类和修复。 这导致了稳定冲刺＆＃34;即一个完整的sprint只是为了修复bug。或者您可以将它们添加回待办事项并将其作为未来冲刺的一部分进行优先级排序。 这也意味着您将提供并期望获得签名并发布包含已知错误的软件（P3＆amp; P4又称化妆品和未成年人）。

这不是很敏捷吗？

Answer 9

我已经在我们的项目中提出了一个想法，即每三个sprint引入一个简短的错误修复冲刺。我们目前的冲刺是三个星期。

这个想法是，它将允许所有开发人员专注于修复错误，允许专注于常规冲刺中的新故事，并定期关注减少技术债务。

错误修复将分组到相关故事中并确定优先级。重点不在于sprint之前的大小调整，因为开发人员在努力修复错误修复而不会陷入困境来理解缺陷的本质。

有没有人试过这个或者对他们认为这可行的方式有任何反馈？

干杯， 凯文。