为什么你应该遵守0 Bug 原则？

你处理过无数 Bug ，却不见得明白正确处理 Bug 的真正铁则。本文仅介绍作者一家之言，欢迎讨论。今日书单彩蛋：《数据科学家修炼之道》。

1

你处理过多少个 Bug

你处理了多少 Bug ？100个？200个？还是2000个？ 

可能你自己也不能说出准确的数字到底是多少，因为它始终在变化。 

但我知道我们究竟有多少 Bug ：0个。 

你究竟参加过多少次 Bug 分拣会议？你在 Bug 管理上用了多少时间（还是仅仅将缺陷从这个版本带到下个版本）？ 

作为团队经理，我每月会花费半小时在 Bug 管理上。并且，同一个 Bug 从未在我眼中出现过第二次。 

2

如何正确地处理 Bug？

答案是使用0 Bug 规则。 

这是基于我在过去的5年中，在不同scrum团队中实现不同产品的经验所得。 

我们也尝试过其他的办法，但全部都失败了：例如说，我们曾尝试过提升 Bug 管理在产品待办事项中的优先级，但是这完全没有用。

客户总希望多开发一些功能，而不是解决 Bug 。所以在这种情况下， Bug 管理就会被推迟到下一次迭代。 

但使用0 Bug 规则的话， Bug 管理就可以有条不紊地进行。 

0 Bug 规则非常先进，但是它是处理 Bug 的非常简单的过程。 

它强调了一个你需要遵循的简单规则——每当你遇到一个新的 Bug ，你可以选择立刻去修复它，或者你选择不再修复它，然后也不再去想到它。就是这么简单。

3

为什么 0 Bug 原则是唯一可行的办法？

现在，让我们来看看为什么这是唯一可行的办法。

 Bug 可以分为2类：

1. Bug 是在开发新功能时带来的。

比如说你在用Scrum方法工作（或是用任何敏捷迭代方法）， Bug 是在“sprint”阶段，在你正在实现的新的用户故事中被找到的。

这类 Bug 必须立刻修复，否则用户故事，或是说功能并没有真正完成。同时，你违反了敏捷基本原则：该做的做完了就好了，这表示只有在用户故事或是说功能经过完全测试，并得到客户的认同，才是真正的完成。如果有任一点没满足，就不能成为结束。 

如果你还是没有弄懂这个概念，那我们可能需要重新回到敏捷基础，你可能需要参考一些其他文章，本文中将不再重复。

2.其他的 Bug （非sprint缺陷） 

a.回归 Bug ——由于开发了功能B，在功能A中出现的 Bug  

b.客户 Bug ——客户，或是不是开发组成员的产品用户所报告的 Bug  

c.在开发完功能/用户故事后发现的 Bug 。从理论上来说这不应该发生，但是当我们发现缺少测试覆盖，或是在做 Bug 跟踪和产品固化时可能会发生。

所以，让我们从理论上来讨论一下如何处理第二类 Bug ——非sprint Bug ： 

1. 你可以选择立刻修复它（或者在下一个sprint修复，但不能再晚了） 

2. 如果修复这个 Bug 的价值不大，你可以选择不再修复它 

3. 你可以将 Bug 推迟到之后处理（几个月后，或是下一个版本中）

请你永远，永远，永远不要推迟 Bug 。请尽力避免。如果你现在不修复它，那你永远都不会再修复它。 

那我们该怎么办？我认为你只需要立刻修复它，或选择永远不修复。这是我们在文章一开始就讨论过的简单规则。 

立刻需要修复的 Bug 包括：“两名用户不能同时进入UI。” 

如果修复它需要超过2天，你可以选择不修复的 Bug 包括：“当屏幕分辨率为768X1280的用户使用Safari时，登录页面的帮助文本是模糊的。对于其他的浏览器，或者其他的屏幕分辨率来说就没有这个问题。” 

《皇帝的新衣》故事中的小男孩哭着对皇帝说：“可是他什么都没有穿！”。对于这个问题他将会问，“为什么？为什么这些 Bug 不能推迟？为什么我不能等到以后再修复它？” 

如果以后修复，你会用更多时间，非常多，大概是好几万倍时间！ 

嘘！这是一个大秘密！如果你选择几周后修复（这里说的不是下次版本发布时）：

• 你可能不太记得，或者你对这个 Bug 的理解没有现在来得强烈。

• 修复需要好的环境——验证错误和修复错误的好环境，在几周以后可能不复存在了。这意味着你需要投入更多的时间来搭建环境。

• 导致原始 Bug 的代码已经更改，其特性也会略有不同。

事实就是，你在未来需要用更多时间修复的这个 Bug 只是一个小问题。

第二部分是你需要维护、分类和管理推迟的 Bug 。无论它们是在产品待办事项中（在一些 Bug 分拣系统），还是在主要功能清单中。

无论是哪种，你都要对它们进行优先级排序，这也需要时间。越久远的缺陷要用越长的时间，因为你不能像对待新的缺陷一样这么了解它们。 

这还不是全部。同时，分拣错误很烦人。你曾经参加过 Bug 分拣会议吗？相信我，这个会得开好久。 

照我的经验来说，如果你的团队有几个经理，几个开发者，几个产品拥有者和几个架构师，他们坐在“ Bug 的法庭”中，讨论如何处理 Bug ，这场谈话最终会变成没有赢家的战争：

• 开发经理：“现在修复这个危险很危险！我们不如推迟吧！”

• 产品拥有者：“你根本没有考虑到用户体验！没有为用户考虑！”

• 开发者：“我们不用使用Java，只要做一个简单的GO模块就可以提升目标机器的性能。”

• 架构师：“如果要修复这个 Bug ，我建议我们放弃extJS而转向Angular，它性能很强大。但我们要记住，修复可能会带来安全影响。”

• QE：“测试这次修复非常简单，我可以在2小时内完成。当然，如果需要在所有浏览器中测试，模拟多用户使用就会要好多天。我们要确保从规模的角度不会有回归测试。”

然后这将继续下去……

大家已经知道这个秘密了，你将永远不再修复这个 Bug ，它将永远在你的系统里。 Bug 的数量会越来越多，无论你将系统部署在哪里，这些 Bug 都会跟着你。

你一次一次的分拣它们，在每周报告中提到它们，在质量指标中计算它们。但是，在任何情况下，这些 Bug 都不会被修复。

还记得《皇帝的新衣》中的孩子吗，他哭着说：“这是为什么？为什么？为什么呢？”

• 如果你决定了现在不修复它，这意味着你现在有更重要的事情要处理。可能是添加新功能。

• 随着时间的流逝，你会推迟更多的 Bug ，这个 Bug 需要和那些新的 Bug 竞争到底先处理谁。所以如果在现在，只有这个 Bug 的时候你不去修复它，那将来有更多 Bug ，你凭什么觉得你会再回头来修复这个 Bug ？

4

0 Bug 原则厉害在哪？

1.首先我们来分析一下为什么其他的方法不能起效。

为什么在发布的最后，加固阶段不修复非sprint Bug ？在加固阶段你要努力让你的发布版本稳定一些。你要投入精力来寻找未知的错误，而不是修复你之前推迟的小 Bug 。 

在任何情况下，你都不会去修复 Bug ，所以你就把这些 Bug 推迟到了下个版本。在下个版本中会有新的 Bug ，所以这些低优先级的 Bug 将永远得不到修复，但你却需要用一些时间来维护它们。 

可能在4年以后你会决定不再修复它们，因为不值得再修复它们了。想想入你在一开始就选择不修复它们，你得节约多少时间。

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

你可能根本没有空载时间。即使你有，你也需要先处理那些优先级更高的问题。

3.为什么不在下个版本中，我们有更多时间的情况下来修复费sprint Bug ？你是认真的吗？你认为下个版本没有新功能？没有客户？没有截止时间？没有里程碑吗？ 

当然开发者都喜欢这2周修复 Bug ，每个sprint都有一些 Bug 会让团队更高兴。 

如果你还处在一个新版本的最初阶段，功能列表还没准备好，不如花时间在创新和社交活动上吧，你会从中受益更多。

4.为什么不在专门的 Bug 修复sprints中修复非sprint Bug ？我们之前用过这个办法，它是有一些优势——PO没有选择，因为整个团队决定好这段时间只修复 Bug 。每个人都修复 Bug ，就感觉上像是“我们都在一起解决 Bug 麻烦”。 

然而，我并不建议用这个方法，因为这个方法仅仅处理了一部分积压已久的大问题，但没有彻底消除它，在后期我们还会碰到修复 Bug 的问题，而且这个问题会变得更复杂。

5.为什么不把修复非sprin Bug 作为用户故事列表的一部分？ 

是的，这不是一个坏的选择。但它有两个主要的问题： 

a. 产品拥有者很难理解这些缺陷为什么比他们的用户故事优先级高。如果让他来选，他更倾向于选择用户故事。

更重要的是什么？删除弹出窗口中的冗余滚动条还是添加搜索功能？这会导致低产品质量和失败的研究与开发。 

b. 每个你现在不修复的 Bug 在未来会花费更多时间。所以推迟 Bug 不符合成本效益。

当我们选择混合 Bug 和用户故事列表时会发生以下这些事情：

1.我们预先计划好将几个故事和 Bug 一起处理，如下所示： 

2.团队只承诺保证前3项完成 

3.然后PO决定将第三项优先级降低，因为“停止应用程序”的功能更加重要： 

4.PO还不是很满意，因为“研究”用户故事不再团队的承诺列表中。 

我们和团队协商完毕，他们承诺会完成前三个用户故事，也会尽可能修复 Bug 。 Bug 并未得到解决。 

类似的sprint又发生了，更多的 Bug 在积压，而新功能却都得到了处理。 

我们现在也同意，0Bug原则是唯一的解决方法。

5

0 Bug 原则这么牛，为什么没人用

红包系统由三部分组成：信息

1.我的产品有1000个 Bug 积压，我从何开始？ 

回顾所有的 Bug 要花费1周的时间。如果你选择不再修复 Bug ，或在下一个sprint中修复，那你就没有 Bug ，你也不需要维护它们了。

2.恐惧因素： 

这可能是人们不喜欢0 Bug 规则的真正理由。它们害怕。我向好多个团队介绍了这个方法，由于恐惧他们拒绝尝试它。我听到他们说： 

“如果我们决定不修复这个 Bug ，它就不在了！我们将永远失去它！” 

是的，这是真的，难道你没有感觉到解放吗？ 

“但是，如果我们不修复这个 Bug ，那以后客户在产品中发现这个 Bug ，难道我们要再来修复它吗？” 

很好，也许我们现在会将这个 Bug 列为最高优先级，并决定立刻修复它！

3.我们的团队只有两个人，我们也要使用0 Bug 规则吗？ 

如果你们团队只有两个人，你不需要任何 Bug 规则，你不该有这些 Bug ，你绝对不会分拣它们。

4.敏捷的一个主要原则不就是人高于过程，0 Bug 规则不是违背了这个原则吗？是的，确实是，根据我的经验，我更喜欢通过文化变革来解决问题，而不是增加过程来解决问题。

0 Bug 规则是这个规则的例外，因为只有这个方法起效，其他办法都不能解决 Bug 。

6

结语

我可以诚实地告诉大家，使用0 Bug 规则对项目不是可有可无的，它非常有效。对我来说最难的一部分就是告诉产品经理，这个方法是唯一有效的正确方法。

这需要产品经理稍微放掉一些手中的权利，这可能不是一件很容易的事情。最好的事情，就是让他们了解到使用这个规则并没有拖延进度，反而能事半功倍。 

0 Bug 规则的另外一个副作用，由于文化影响，现在开发者都尽自己所能追求高质量，没有一个开发者希望自己的代码中有 Bug 。

对大多数（优秀的）开发者来说，如果决定不解决 Bug ，就感觉自己的作品不完美了。由于这个文化，开发者和产品都转而追求高质量标准。 

老司机介绍

Gal Zellermayer是一位“万事通”。在过去的5年中，Gal在VMware公司中管理不同的R&D团队，所以他对于产品研发周期有很多经验。

通过创新，通过建立产品待办事项列表，领导团队实现项目的同时保持产品高质量，将产品满意地交付给客户。但他最追求的是建立完美的软件团队，一个可以快速交付高质量产品的团队。

Gal热爱新技术，新产品，以及过程。但是最让他兴奋的是和他一起工作的人，能看到他所辅导过的人在事业上取得进步是最令他感到骄傲的事情。