0缺陷规则-變量-匯編語言學習筆記

0缺陷规则

2023-09-05 阅读 73 评论 0

摘要：你处理了多少缺陷？100个？200个？还是2000个？\\可能你自己也不能说出准确的数字到底是多少，因为它始终在变化。\\但我知道我们究竟有多少缺陷：0个。\\你究竟参加过多少次缺陷分拣会议？你在缺陷管理上用了多少时间（还是

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

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

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

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

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

你是否思考过，如果你们团队使用scrum或是另外一些敏捷方法工作时，应该如何处理缺陷？

答案是使用0缺陷规则。

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

我们也尝试过其他的办法，但全部都失败了：例如说，我们曾尝试过提升缺陷管理在产品待办事项中的优先级，但是这完全没有用。客户总希望多开发一些功能，而不是解决缺陷。所以在这种情况下，缺陷管理就会被推迟到下一次迭代。

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

下面的文章向读者朋友们描述了什么是0缺陷规则，为什么它是唯一有效的方法。

让我们开始吧。

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

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

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

缺陷可以分为2类：

缺陷是在开发新功能时带来的。比如说你在用Scrum方法工作（或是用任何敏捷迭代方法），缺陷是在”sprint”阶段，在你正在实现的新的用户故事中被找到的。\\t\\\t
这类缺陷必须立刻修复，否则用户故事，或是说功能并没有真正完成。同时，你违反了敏捷基本原则：该做的做完了就好了，这表示只有在用户故事或是说功能经过完全测试，并得到客户的认同，才是真正的完成。如果有任一点没满足，就不能成为结束。
\\\t
如果你还是没有弄懂这个概念，那我们可能需要重新回到敏捷基础，你可能需要参考一些其他文章，本文中将不再重复。
\\t\\t
其他的缺陷（非sprint缺陷）\\t\\\t
a.回归缺陷——由于开发了功能B，在功能A中出现的缺陷
\\\t
b.客户缺陷——客户，或是不是开发组成员的产品用户所报告的缺陷
\\\t
c.在开发完功能/用户故事后发现的缺陷。从理论上来说这不应该发生，但是当我们发现缺少测试覆盖，或是在做缺陷跟踪和产品固化时可能会发生。
\\t\

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

你可以选择立刻修复它（或者在下一个sprint修复，但不能再晚了）\\t
如果修复这个缺陷的价值不大，你可以选择不再修复它\\t
你可以将缺陷推迟到之后处理（几个月后，或是下一个版本中）\

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

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

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

如果修复它需要2天以上的工作量，你可以选择不去修复它，比如：“当屏幕分辨率为768X1280的用户使用Safari时，登录页面的帮助文本是模糊的。而其他浏览器或其他屏幕分辨率就没有这个问题。”

图片来源：Wikimedia

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

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

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

你可能不太记得，或者你对这个缺陷的理解没有现在来得强烈。\\t
修复需要好的环境——验证错误和修复错误的好环境，在几周以后可能不复存在了。这意味着你需要投入更多的时间来搭建环境。\\t
导致原始缺陷的代码已经更改，其特性也会略有不同。\

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

第二部分是你需要维护、分类和管理推迟的缺陷。无论它们是在产品待办事项中（在一些缺陷分拣系统），还是在主要功能清单中。无论是哪种，你都要对它们进行优先级排序，这也需要时间。越久远的缺陷要用越长的时间，因为你不能像对待新的缺陷一样这么了解它们。

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

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

开发经理：“现在修复这个危险很危险！我们不如推迟吧！”\\t
产品拥有者：“你根本没有考虑到用户体验！没有为用户考虑！”\\t
开发者：“我们不用使用Java，只要做一个简单的GO模块就可以提升目标机器的性能。”\\t
架构师：“如果要修复这个缺陷，我建议我们放弃extJS而转向Angular，它性能很强大。但我们要记住，修复可能会带来安全影响。”\\t
QE：“测试这次修复非常简单，我可以在2小时内完成。当然，如果需要在所有浏览器中测试，模拟多用户使用就会要好多天。我们要确保从规模的角度不会有回归测试。”\

然后这将继续下去……

大家已经知道这个秘密了，你将永远不再修复这个缺陷，它将永远在你的系统里。缺陷的数量会越来越多，无论你将系统部署在哪里，这些缺陷都会跟着你。你一次一次的分拣它们，在每周报告中提到它们，在质量指标中计算它们。但是，在任何情况下，这些缺陷都不会被修复。

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

如果你决定了现在不修复它，这意味着你现在有更重要的事情要处理。可能是添加新功能。\\t
随着时间的流逝，你会推迟更多的缺陷，这个缺陷需要和那些新的缺陷竞争到底先处理谁。所以如果在现在，只有这个缺陷的时候你不去修复它，那将来有更多缺陷，你凭什么觉得你会再回头来修复这个缺陷？\

好了，说了这么多，让我们来看看0缺陷规则是多么伟大！

\\t
首先我们来分析一下为什么其他的方法不能起效。
\\\t
为什么在发布的最后，加固阶段不修复非sprint缺陷？在加固阶段你要努力让你的发布版本稳定一些。你要投入精力来寻找未知的错误，而不是修复你之前推迟的小缺陷。
\\\t
在任何情况下，你都不会去修复缺陷，所以你就把这些缺陷推迟到了下个版本。在下个版本中会有新的缺陷，所以这些低优先级的缺陷将永远得不到修复，但你却需要用一些时间来维护它们。
\\\t
可能在4年以后你会决定不再修复它们，因为不值得再修复它们了。想想入你在一开始就选择不修复它们，你得节约多少时间。
\\t\\t
\\t
为什么不在空载时间修复它们？
\\\t
你可能根本没有空载时间。即使你有，你也需要先处理那些优先级更高的问题。
\\t\\t
\\t
为什么不在下个版本中，我们有更多时间的情况下来修复费sprint缺陷？你是认真的吗？你认为下个版本没有新功能？没有客户？没有截止时间？没有里程碑吗？
\\\t
当然开发者都喜欢这2周修复缺陷，每个sprint都有一些缺陷会让团队更高兴。
\\\t
如果你还处在一个新版本的最初阶段，功能列表还没准备好，不如花时间在创新和社交活动上吧，你会从中受益更多。
\\t\\t
\\t
为什么不在专门的缺陷修复sprints中修复非sprint缺陷？我们之前用过这个办法，它是有一些优势——PO没有选择，因为整个团队决定好这段时间只修复缺陷。每个人都修复缺陷，就感觉上像是“我们都在一起解决缺陷麻烦”。
\\\t
然而，我并不建议用这个方法，因为这个方法仅仅处理了一部分积压已久的大问题，但没有彻底消除它，在后期我们还会碰到修复缺陷的问题，而且这个问题会变得更复杂。
\\t\\t
\\t
为什么不把修复非sprint缺陷作为用户故事列表的一部分？
\\\t
是的，这不是一个坏的选择。但它有两个主要的问题：
\\\t
a. 产品拥有者很难理解这些缺陷为什么比他们的用户故事优先级高。如果让他来选，他会更倾向于用户故事。哪个更重要？是删除弹窗中多余的滚动条还是添加搜索功能？这会导致低劣的产品和令人懊丧研发。
\\\t
b. 每个你现在不修复的缺陷在未来会花费更多时间。所以推迟缺陷不符合成本效益。
\\t\

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

\\t
我们预先计划好将几个故事和缺陷一起处理，如下所示：
\\\t
\\t\\t
\\t
团队只承诺保证前3项完成
\\\t
\\t\\t
\\t
然后PO决定将第三项优先级降低，因为“停止应用程序”的功能更加重要：
\\\t
\\t\\t
\\t
PO还不是很满意，因为“研究”用户故事不再团队的承诺列表中。
\\\t
\\t\

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

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

我们现在也同意，0缺陷规则是唯一的解决方法。

那为什么它并不这么普遍呢？

\\t
我的产品有1000个缺陷积压，我从何开始？
\\\t
回顾所有的缺陷要花费1周的时间。如果你选择不再修复缺陷，或在下一个sprint中修复，那你就没有缺陷，你也不需要维护它们了。
\\t\\t
\\t
恐惧因素：
\\\t
这可能是人们不喜欢0缺陷规则的真正理由。它们害怕。我向好多个团队介绍了这个方法，由于恐惧他们拒绝尝试它。我听到他们说：
\\\t
“如果我们决定不修复这个缺陷，它就不在了！我们将永远失去它！”
\\\t
是的，这是真的，难道你没有感觉到解放吗？
\\\t
“但是，如果我们不修复这个缺陷，那以后客户在产品中发现这个缺陷，难道我们要再来修复它吗？”
\\\t
很好，也许我们现在会将这个缺陷列为最高优先级，并决定立刻修复它！
\\t\\t
\\t
我们的团队只有两个人，我们也要使用0缺陷规则吗？
\\\t
如果你们团队只有两个人，你不需要任何缺陷规则，你不该有这些缺陷，你绝对不会分拣它们。
\\t\\t
\\t
敏捷的一个主要原则不就是人高于过程，0缺陷规则不是违背了这个原则吗？是的，确实是，根据我的经验，我更喜欢通过文化变革来解决问题，而不是增加过程来解决问题。0缺陷规则是这个规则的例外，因为只有这个方法起效，其他办法都不能解决缺陷。
\\t\

结语

我可以诚实地告诉大家，使用0缺陷规则对项目不是可有可无的，它非常有效。对我来说最难的一部分就是告诉产品经理，这个方法是唯一有效的正确方法。这需要产品经理稍微放掉一些手中的权利，这可能不是一件很容易的事情。最好的事情，就是让他们了解到使用这个规则并没有拖延进度，反而能事半功倍。

0缺陷规则的另外一个副作用，由于文化影响，现在开发者都尽自己所能追求高质量，没有一个开发者希望自己的代码中有缺陷。对大多数（优秀的）开发者来说，如果决定不解决缺陷，就感觉自己的作品不完美了。由于这个文化，开发者和产品都转而追求高质量标准。

这篇博文受到了Joel Spolsky的博客\"Software Inventory\"的很多影响，但大多数是由我和我的同事与合作伙伴在去VMware Israel的路上所撰写的。

关于作者

Gal Zellermayer是一位“万事通”。在过去的5年中，Gal在VMware公司中管理不同的R\u0026amp;D团队，所以他对于产品研发周期有很多经验。通过创新，通过建立产品待办事项列表，领导团队实现项目的同时保持产品高质量，将产品满意地交付给客户。但他最追求的是建立完美的软件团队，一个可以快速交付高质量产品的团队。Gal热爱新技术，新产品，以及过程。但是最让他兴奋的是和他一起工作的人，能看到他所辅导过的人在事业上取得进步是最令他感到骄傲的事情。