如何解决大量积压的bug？

#1 楼

这很常见。

问题基本上包括三个部分：



测量。每周要解决的积压问题变得越来越严重或改善
确定。
找出需要改变的事物，以使每周变得更糟的情况
清理。您一点一点地创建的



我将专注于第3部分-清理-但是如果您不执行第1部分和第2部分，您将很快进入又是一个坏地方（如果您根本不出去的话）。如果您想获得有关“测量和跟踪”的更多信息，则可以针对那些部分提出具体的答案，以获取详细的答案（当然，还可以征求各种答案）。另外，凯特（Kate）的详细答案对这些活动也有很好的信息。它们不能具有相同的优先级。也许分为高，中，低。
估计难度。在相对于其他票证的相对复杂性方面。使用分数和投票是一种方法。
分类，标记和标签。某些问题不太重要，例如布局问题，其他问题可能很重要，也许是数据库问题。创建类别并使用标签和标签可以帮助进行分类。 Jira，Trello或Pivotal Tracker之类的工具来管理故障单。
将当前开发的故障单与积压的故障单混合在一起。
删除旧的故障单。即使是“一个好主意”，“我们应该做”也常常不会做。删除内容要大胆。您始终可以重新创建或恢复故障单
编写测试。如果您已经积累了很多错误，那么人们是否正在编写测试以防止它们首先使用TDD / BDD进行测试？如果没有，他们应该立即开始以防止错误增加。
使用QA / QE帮助测试，查找，确定错误的优先级和分类
查看分配给sprint，sprint和sprint之间的工作量，看看您是否只是在进行过多的工作。 。
与现有的可用功能和当前功能开发相比，请考虑短期以及现在实际需要使用什么资源
请长期考虑如何避免再次遇到相同情况。应该监视票证的统计信息（增加，已解决，未解决等）以及每周的趋势。长期思考应包括对事物如何以目前的状态进行分析。

#2 楼

除了迈克尔·杜兰特（Michael Durrant）的出色回答和同样出色的评论之外，我建议您考虑一些其他事项：错误积压。您可能会发现以下各项的某种组合：


Bug聚集在应用程序的某些区域。这些通常是最复杂的领域，和/或设计和体系结构关注最少的领域。
大量错误是由未定义的用户案例或错过的用户案例引起的。
大量错误位于未经单元测试或单元测试的区域。
大量错误是先前已测试功能的回归（可能未经自动化测试或未经自动化测试） ）。


一旦您对错误进行了不错的分析，您会发现它们指向流程需要改进的许多领域。例如：


如果您的许多错误是客户报告的，那么您的团队可能需要花更多的时间来进行集成和端到端自动化，从客户报告的错误最严重的应用程序。
如果您的许多错误是回归的，则您的团队可能需要花费更多的时间来构建良好的单元和集成测试，并在功能更改时进行维护。您的许多错误已过时（即已在更高版本中修复，但从未关闭）或重复出现，您的团队可能需要花费更多时间来整理您的错误待办事项以及功能和用户案例的待办事项，并积极寻找重复的报告。


当您知道错误积压为什么会持续增长，它们来自何处以及它们的根本原因时，您的团队可能需要指定一个冲刺来进行错误清除sprint，从最高优先级的错误开始，然后逐步解决错误积压。
对于一个非常可怕的错误积压，您可能想要指定每四个冲刺（或任何适合您的节奏）进行错误清除，直到积压得到控制。
如果如果单元/集成/端到端测试自动化不足是问题的一部分，则您可能需要花费一个或多个冲刺来修复测试自动化。
如果您不能将sprint专门用于自动化或错误清除，那么问题可能出在整个食物链上，而不是您的团队中，并且需要与您的管理部门一起解决-一支团队无法花费他们通常需要管理层推动或要求他们提高质量实践或减少技术负担（您的错误积压所代表的时间）以产生比可持续性更多的新功能（在这种情况下，我表示同情。我去过那里并接受教育管理不好玩）。

#3 楼

过去，当我致力于解决错误报告时，我发现由于大量人报告同一错误，积压的订单得以减少。我们为我们的应用程序编写了一个类似的错误插件，该插件搜索所有打开的错误，并建议将哪些错误链接为同一错误，然后自动创建一个新的错误报告，其中包含所有客户提交的错误报告以及客户提交的错误的详细信息。相同的错误将所有错误链接在一起并与一个错误相关，在一个实例中，我们能够获取将近1000个错误报告，并将它们简化为一个主错误报告，该报告重复了很多次，原因仅在于该错误经常发生使用的功能会显示一个错误显示，而我们的错误显示具有一个“作为错误报告”按钮。

#4 楼

大量的错误清单很浪费时间。一遍又一遍地遍历列表时，错误将变得越来越难。我曾经列出了3000多个缺陷，而且还看不到尽头。丢弃所有缺陷并引入零缺陷策略。



现在，当出现新缺陷时：根据策略对其进行分类。立即修复关键问题，并在当前工作后修复常规错误。确定所有其他功能是否都是功能，改进或琐碎的功能。仅在下一个时期确实值得时才将它们放置在积压中。与记者明确沟通。
修复后，进行根本原因分析并解决产生错误的地方。改进流程和代码库。

敏捷团队应设法尽快修复所有错误。它降低了它们的速度，现在变得诚实了，由于过去的错误，新功能的推出速度会变慢。使用新知识检查并调整您的计划。

#5 楼

故障是软件交付中不可避免的一部分。我只简要介绍了敏捷项目执行中的故障管理列表，因此值得进行扩展。

实际上，缺陷是一个领域，包括敏捷软件开发在内的软件交付可能会变得混乱。幸运的是，有一些方法可以解决这种混乱或完全避免这种混乱。乔的问题暗示了可能的答案，但还有其他答案。实际上，我至少知道九种用于管理不断增加的故障列表的常见策略。

我的策略是：

Do nothing
Filter out the noise
Stop logging low impact defects
Close off low impact defects
Prune the backlog
Batch the defects
Blitz the defects
Fix some every sprint
Automate the tests

什么都不做

在决定采取哪种选择之前，您必须先知道谁在乎。谁在乎产品积压很大？产品拥有者？开发人员？专案经理？如果没有人在意，那就没问题了。


滤除噪音

那么，为什么他们要在意呢？也许您的开发人员很在意，因为他们在产品积压中看到了很多杂音，这是他们不应该做的事情。如果这是问题所在，那么只需确保开发人员在优先考虑那些影响较小的项目之前就不会看到它们。如果您的产品积压订单是电子的，则可以为此使用某种过滤。如果产品待办事项是在墙上的卡片，请将未优先处理的卡片放在其他地方。

可能是您的产品所有者讨厌优先考虑待办事项的低价值缺陷。过滤也可以在这里提供帮助。在这种情况下，请检查报告这些数字的位置，看看是否还有其他人在乎。如果较高的部分不在乎，请说服您的测试人员不在乎。或者，协商协商其他报告，例如仅影响高和中等的缺陷，不包括低缺陷，或报告每个类别中的缺陷数量。这实际上也是一种过滤解决方案。


停止记录低冲击缺陷

如果您必须采取措施减少列表中的缺陷数量，那么您可以按照Jo的建议，仅停止记录影响较小的bug。以这种方式忽略低冲击缺陷的唯一麻烦是扔掉卡并不能解决问题。人们可能会不断注意到同样的错误并再次提出来。但是，您可能会发现这种风险值得。


关闭低冲击缺陷

这有点类似于根本不记录低冲击缺陷。在这种情况下，您无法解决问题，而是确定永远不会解决问题，只需关闭票证即可。同样的风险会再次被提出，但可能没有关系。由于列表将过时，因此必须偶尔修剪产品积压。随着时间的流逝，由于系统的更改，某些项目将变得无关紧要。不相关的缺陷只会变得杂乱无章，应清除。


将缺陷进行批处理

另一种选择是将相关缺陷进行批处理。它们可能单独产生低影响和低价值，但总的来说它们的总价值将增加。例如，您可以将一组“电子邮件”缺陷分组在一起，并让产品所有者优先考虑这些分组，而不是对单个项目进行优先排序。 >常见的策略是消除缺陷。这意味着要分配整个团队来修复冲刺缺陷。这通常在重大发射之前立即发生。


修复每个冲刺

分配每个冲刺的故障要花一定比例的精力也是很常见的。我主张给技术团队每个冲刺时间以解决技术问题，并且可以将错误归结为解决问题。九种策略中的最后一种也是最好的方法是推动自动化测试。自动化测试的目标是在sprint中解决所有缺陷，从而大大减少了需要记录的缺陷数量。记录缺陷的步骤通常可以通过编写新测试来代替。

#6 楼

如果您没有大量积压，则不需要处理。我认为要管理您目前拥有的东西，除了别人已经提供给您的所有优点之外，您还必须弄清楚大多数缺陷也已注入的阶段。

根据敏捷理论，缺陷是技术债务，您实际上并没有在冲刺中分配时间来处理技术债务。每个冲刺都有一个明确的目标-处理故事。我知道现实中团队可能会在一边分配资源来解决技术债务，但这意味着它应该同时从sprint（降低速度）中夺走资源，这样做是正确的，这样可以避免由于缺乏而注入更多缺陷适当的资源/时间。

根据我的经验，除非您的积压来自旧代码（敏捷开发之前的几天），否则您应该查看敏捷案例的“完成标准”。故事完成后，应该“完成”，而不仅仅是为质量检查准备的代码。如果这些故事的缺陷太多，您应该确保在故事的完成标准中进行了必要的测试。希望您的待办事项将以这种方式减少。