零 bug 策略：要么立马修复，要么忽略

609次阅读  |  发布于4年以前

你在管理着多少个 bug，100，200，还是 2000 个？可能你自己也说不清，因为这个数字一直在变化。

但我却能说出我们的 bug 数：0 个。

你究竟在 bug 分派和管理上花费了多长时间，还是只能把它们从这个版本拖到下一个版本？

作为一个团队经理（group manager），我每个月要花半小时的时间在 bug 管理上，并且同样的 bug 不会在我眼里出现第二次。

你有没有考虑过，当你使用 Scrum 或其他敏捷方法工作时，要如何处理 bug 呢？

答案就是使用 0 bug 策略。过去五年中，我参与过不同产品的 Scrum 项目，这个策略是基于我的工作经验得出的。

我们也尝试过其他方法，但都宣告失败。例如，我们试过提升 bug 在产品待办事项中的优先级，但没什么用处。比起修复这些 bug，客户更倾向于给产品开发一些新功能，然后这些 bug 就会被推迟到下一次迭代中。

0 bug 策略解决了这一问题。

下面我们来了解一下 0 bug 策略，以及为什么我认为这是最好的解决方案。

什么是 0 bug 策略？

0 bug 策略是一种非常先进的处理 bug 的策略，但同时它也非常易于实施。

你只需要谨记一条准则：不论何时对 bug 的处理方法只有两种选择，或修复它，或关闭然后不再去想它。

如何实施？

Bug 可以分为两类：

如果你们正在使用 Scrum 方法（或其他敏捷迭代方法），在实现用户故事（user story）的 sprint 过程中产生的bug。

这类 bug 必须立刻修复，否则用户故事，或者说新功能的实现就会受到影响，而且你也违背了敏捷开发的原则：DONE is DONE（木已成舟，指开发完成就不再更改）。只有经过全方面测试，并得到客户的认可后，用户故事或新功能才能算得上是真正的完成。

我们应该如何处理第二类 bug？

永远不要推迟 bug，如果你现在无法修复它，那么你可能永远都不会再修复它了。

那我们应该怎么做呢？或者选择修复它，或者关闭它，这就是 0 bug 策略的精髓。

如下这种 bug 是必须进行修复的：两个用户无法同时进入 UI

如果修复一个 bug 需要超过两天的时间，可以考虑不进行修复，举个例子：

在 Safari 的使用过程中，当屏幕分辨率为768×1280 时登录页面中的帮助文本有些模糊。其他浏览器或其他的分辨率就没有这样的问题。

可能有人会问，为什么不能推迟一些时间再解决这些 bug 呢？

如果以后再修复，你需要花费比现在更多的时间和精力才可以。因为几周后：

然而问题不仅仅是你需要投入更多时间才能修复 bug，这只是一个很小的方面。

后续你还要对这些 bug 进行维护、分类和管理。无论是把它们放在产品待办事项中（在某些 bug 分类系统中），还是作为主要功能清单的一部分，你都需要对这些 bug 按优先级排序，这无疑会耗费很多时间。处理旧 bug 则需要更长的时间，因为你不能像熟知新 bug 一样那么了解它们了。同时，bug 分类也是很烦人的。

根据我的经验来说，当经理、开发人员、产品所有者和架构师坐在一个 bug 法院（试图决定如何处理 bug）时，这场讨论将变成一场没有赢家的战争：

你将永远无法修复这个 bug，它会永远存在你的系统里。这类 bug 会越来越多，它们会一直跟着你。你只能一次又一次地进行分类，把它们记录在每周的报告中，并且在质量指数中计算它们。

为什么这些 bug 永远无法被修复？

为什么不能在发布最后的加固阶段修复非 sprint 期的 bug？

在加固阶段，你应该努力让你的版本更稳定一些。你要尽力寻找未知的问题，而不是在这时修复那些推迟的小 bug。

不论何时，你都不可能修复所有的 bug，总会有一些被推迟到下一个版本解决。而在下一个版本中你肯定会发现新的 bug。那些低优先级的 bug 永远不会被修复，但你还需要花时间维护它们。

也许 4 年后你决定不再修复它们，因为不值得的浪费精力。想象一下，如果在创建 bug 时就直接选择不进行修复，你将节省多少时间。

为什么不能在空载时间修复它们？

你不会有空载时间的，如果有的话，也会有更重要的问题等着你去处理。

为什么不能在下一个版本中修复它们？

你确定么？难道下一个版本没有新功能、客户、截止日期和里程碑么？

当然开发人员都很喜欢那两周的错误修复时间，每次 sprint 有几个 bug 会使团队人员更高兴。

如果一个新版本刚开始的时候，功能列表还是空白的，不如在创新或社交活动上投入点时间，你会受益良多。

为什么不能在专门的 sprint 期中修复非 springt bug？

我们以前尝试过这种方法，的确有些好处。产品所有者没有选择，因为整个团队这段时间都在修复 bug，每个人都在做这件事，给人一种团队合作的感觉。

然而我却不是很推崇它，因为这种方法只是处理了其中一小部分，根本没法消除日积月累的 bug，后期你仍然会面临这些问题，而且问题会更复杂。

为什么不能把 bug 作为待办列表的一部分解决？

实际上这也是个不错的选择，但需要注意：

  1. 产品所有者很难理解为什么这些 bug 的优先级会比新用户故事要高，他们更倾向于用户故事。删除弹窗中多余的滚动条和添加搜索功能，哪个更重要呢？这将会降低产品的质量和研发热情。
  2. 每个现在你无法修复的 bug后期会消耗更多的时间。推迟 bug 不符合成本效益。

下面这张图展示了 bug 和用户故事混合记录的情况。我们尝试了将几个用户故事和 bug 放在一起处理：

在此期间，项目组只需处理前三条内容

产品所有者决定将第三项优先级降低，因为停止应用程序功能更加重要

产品拥有者还不是很满意，因为搜索功能没在列表中提及

我们和团队达成协议优先解决前三个用户故事，同时尽可能修复 bug。Bug 并没有得到修复。下次 sprint 的模式还是一样的，更多的bug 被积压，而新的功能都得到了处理。

现在，我们同意 0 bug 策略是唯一的出路了。

为什么0 bug 策略不常见？

0 bug 策略不太常见可能有以下几个原因：

我的产品已经有超过 1000 个 bug 了，我如何开始？

花一个星期的时间浏览这些 bug，或者选择不再修复它们，或者在下一个 sprint 中进行修复。你需要做的就是把 bug 数变为 0，然后保持住。

恐惧

这可能是为什么人们不喜欢 0 bug 策略的真正原因。我曾向几个团队介绍了这种方法，但是由于恐惧他们都拒绝尝试：

如果我们关闭了这个 bug，它就彻底消失了，我们永远也找不到它了！

没错，就是这样，难道你没有感觉到解脱么？

但是，如果我们关闭这个 bug，用户在使用产品时又发现它，不是还要重新修复么？

既然这个 bug 如此重要，不如现在就动手解决吧！

我们团队只有两个人，需要遵循 0 bug 策略么？

如果你们的团队只有两个人，就不需要任何策略，因为你们不应该有 bug，更不会去分拣它们。

敏捷开发的主要原则是人大于过程， 0 bug 策略是否违背了这个原则？

的确是，从我的经验来说，我更喜欢通过文化变革来解决问题，而不是增加过程。0 bug 策略是这个策略的例外。

总结

我可以诚实地说，使用 0 bug 策略并不是微不足道，相反它能带来很好的成本效益。对我来说，最难的部分可能是如何说服产品经理，这种方法是唯一正确的方式。这要求他们稍微放掉一些权利，这不是一件容易的事情。最好能让他们意识这个策略没有拖慢进度，反而大有用处。

0 bug 策略还有另外一个作用，现在的开发人员追求更高的质量，没有人希望自己的代码出现错误。有了 0 bug 策略，他们知道如果现在不进行修复的话，bug 将被关闭。因此，开发者和产品才能向更高的质量标准迈进。

这篇文章受到 Joel Spolsky 的博客 Software Inventory 的影响，但主要是我和同事在 VMware Israel 时完成的。

关于英文作者

Gal Zellermayer 是一个万事通。在过去 5 年中，他在 VMware 参与过不同研发团队的管理，Gal 对研发的生命周期有丰富的经验。通过创新和建立待办事项列表，领导团队实施，然后将高质量的产品交付给客户。他追求的是完美的软件开发团队-一个可以快速交付高质量产品的团队。Gal 对新技术、产品和过程都充满热情，但他最热爱的是与他合作过的人。所有他指导过的人在职业生涯中获得进步的时候，他都会为之骄傲。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8