将错误修复纳入Scrum流程的最佳方法？[关闭]

最近几天，我一直在学习和阅读有关Scrum的信息，并阅读有关Sprint计划和任务的信息。我想到的一个问题是如何处理Scrum中的错误。Henrik Kniberg在他的非常好的《Trenches》中的Scrum和XP中列出了解决此问题的一些方法：

1. 产品负责人打印出优先级最高的Jira项目，将它们带入sprint计划会议，并将它们与其他故事一起放在墙上（从而隐式指定这些项目与其他故事相比的优先级）。
2. 产品负责人创建引用Jira项目的故事。例如，“修复最关键的后台报告错误，即Jira-124，Jira-126和Jira-180”。
3. 错误修复被认为不在冲刺之外，即，团队保持足够低的关注因子（例如50％）以确保他们有时间修复错误。然后简单地假设团队将花费一定的时间在每个sprint上修复Jira报告的错误。
4. 将积压的产品放在Jira中（即Excel沟）。像对待其他故事一样对待bug。

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

这是一个非常好的问题，当涉及到解决此问题的不同方法时，我有一些观察。

1. 从理论上讲，将所有bug与待办事项平等对待可能听起来是个好主意（将工作跟踪在一个地方），但在实践中效果不佳。错误通常是低级的，而且数量很多，因此，如果为每个错误创建一个单独的用户故事，那么“真实的”故事很快就会被掩盖。
2. 如果以产品所有者可见的方式进行，则每个保留用于修复的sprint中的显式时间都可以。在每日Scrum期间应提及错误，并且在sprint审查期间应讨论有关已修复的错误。否则，产品负责人将不会知道项目中正在发生什么。
3. 将整个待办事项放入bug跟踪工具中会导致与1中相同的问题。此外，大多数bug跟踪器在设计时都没有考虑Scrum，为此而使用它们可能会很痛苦。

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

只需记住无情地关闭实际上是新功能的所有“错误”并为其创建新的待办事项。此外，请确保在Sprint结束之前针对当前Sprint修复报告的所有错误，以将Sprint视为已完成。

实际上，我认为最好是jpeacock回答这个问题，您是否算了花费在Scrum上的bug修复上的时间？

让我引用一下：

• 如果该错误容易/快速修复（一个衬里等），则只需对其进行修复。
• 如果该错误不是无关紧要的，也不是阻止程序，则将其添加到待办事项列表中。
• 如果错误是阻止程序，则添加一个任务（到当前的sprint）以捕获修复该问题所需的工作，然后开始进行处理。这需要将其他内容（从当前的sprint）移至待办事项以计入新的小时数，因为您的可用总时数未更改。

第一步是定义什么是错误。我教导说，错误仅是功能无法按预期/设计在生产环境中使用的错误。这些成为错误类型的PBI，优先于新开发。生产中缺少的功能是一项功能，并且成为正常的产品待办事项。在冲刺过程中发现的任何有缺陷的代码都被认为是不完整的工作，因为在完成当前故事之前，您不会继续进行下一故事。由于团队始终在研究有问题的代码，因此不必在sprint中跟踪这些缺陷。便利贴可以在这里方便队友之间的快速提醒。修复损坏的代码始终优先于编写新代码。

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

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

如果缺陷多于功能，则需要进行工程实践。闻起来有些不对劲，而跟踪并不是答案。深入挖掘。实际上，虫子总是很臭。它们不是很酷，如果有很多，您需要找到根本原因，消除它们，并停止专注于跟踪错误。

不要在列表上跟踪缺陷，找到并修复缺陷-Mary Poppendieck

确实，如果库存很浪费，那么缺陷库存又如何呢？

这就是为什么我总是尝试通过测试驱动的开发和持续集成来实施“ 停线”思维，以便我们找到并修复大多数缺陷，而不是将它们放到返工清单上。

当缺陷通过时，我们会在编写新代码之前对其进行修复（无论如何，带有错误的故事都不会完成）。然后，我们尝试修正流程，使其更具防错能力，并在出现缺陷时立即进行检测。

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

除非对系统的运行至关重要，否则我更喜欢将Bug用作故事卡。这使得功能开发与错误修复的优先级真正明确了。在错误修复被认为不在“冲刺”之外的情况下，错误修复可能会朝着修复真正的琐碎错误迈进，而实际上尚未开发出重要的业务功能。

在将Bug作为故事方法设置之前，我们已经经过了许多排列。尝试一些不同的事情，然后在团队复古会议上重播。

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

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

为什么？

因此，如果您希望缺陷（即积压问题）进入PBI或保留在此Sprint中并交付它，则您可以作为团队进行讨论和理性思考。

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

如果要识别和记录错误，则必须在将来的某个时间进行分类和修复。这导致“稳定冲刺”，即一个完整的冲刺仅用于修复错误。或者，您可以将它们重新添加到积压中，并在将来的冲刺中对它们进行优先级排序。这也意味着您将提供并期望获得已签发并已发布带有已知错误（P3和P4，又名化妆品和未成年人）的软件。

这不是真的敏捷吗？

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

这样做的想法是，所有开发人员都可以将精力集中在错误修复上，只关注常规冲刺中的新故事，并经常关注减少技术债务。

错误修复将分为相关故事并按优先级排列。重点不是在sprint之前确定大小，因为开发人员努力确定错误修复的大小，而又不会陷入了解缺陷的本质的困境。

是否有人尝试过此方法或对他们认为这可能如何工作有任何反馈？

干杯，凯文。