10 月,开发者不可错过的开源大数据大会-2021 WeDataSphere 社区大会深圳站 了解详情
写点什么

0 缺陷规则

2016 年 6 月 15 日

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

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

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

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

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

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

答案是使用 0 缺陷规则。

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

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

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

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

让我们开始吧。

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

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

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

缺陷可以分为 2 类:

  1. 缺陷是在开发新功能时带来的。比如说你在用 Scrum 方法工作(或是用任何敏捷迭代方法),缺陷是在”sprint”阶段,在你正在实现的新的用户故事中被找到的。 这类缺陷必须立刻修复,否则用户故事,或是说功能并没有真正完成。同时,你违反了敏捷基本原则:该做的做完了就好了,这表示只有在用户故事或是说功能经过完全测试,并得到客户的认同,才是真正的完成。如果有任一点没满足,就不能成为结束。

如果你还是没有弄懂这个概念,那我们可能需要重新回到敏捷基础,你可能需要参考一些其他文章,本文中将不再重复。
2. 其他的缺陷(非 sprint 缺陷) a. 回归缺陷——由于开发了功能 B,在功能 A 中出现的缺陷

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

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

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

  1. 你可以选择立刻修复它(或者在下一个 sprint 修复,但不能再晚了)
  2. 如果修复这个缺陷的价值不大,你可以选择不再修复它
  3. 你可以将缺陷推迟到之后处理(几个月后,或是下一个版本中)

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

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

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

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

图片来源: Wikimedia

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

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

嘘!这是一个大秘密!如果你选择几周后修复(这里说的不是下次版本发布时):

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

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

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

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

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

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

然后这将继续下去……

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

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

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

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

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

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

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

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

你可能根本没有空载时间。即使你有,你也需要先处理那些优先级更高的问题。
3. 为什么不在下个版本中,我们有更多时间的情况下来修复费 sprint 缺陷?你是认真的吗?你认为下个版本没有新功能?没有客户?没有截止时间?没有里程碑吗?

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

如果你还处在一个新版本的最初阶段,功能列表还没准备好,不如花时间在创新和社交活动上吧,你会从中受益更多。
4. 为什么不在专门的缺陷修复 sprints 中修复非 sprint 缺陷?我们之前用过这个办法,它是有一些优势——PO 没有选择,因为整个团队决定好这段时间只修复缺陷。每个人都修复缺陷,就感觉上像是“我们都在一起解决缺陷麻烦”。

然而,我并不建议用这个方法,因为这个方法仅仅处理了一部分积压已久的大问题,但没有彻底消除它,在后期我们还会碰到修复缺陷的问题,而且这个问题会变得更复杂。
5. 为什么不把修复非 sprint 缺陷作为用户故事列表的一部分?

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

a. 产品拥有者很难理解这些缺陷为什么比他们的用户故事优先级高。如果让他来选,他会更倾向于用户故事。哪个更重要?是删除弹窗中多余的滚动条还是添加搜索功能?这会导致低劣的产品和令人懊丧研发。

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

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

  1. 我们预先计划好将几个故事和缺陷一起处理,如下所示:


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


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


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

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

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

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

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

  1. 我的产品有 1000 个缺陷积压,我从何开始?

回顾所有的缺陷要花费 1 周的时间。如果你选择不再修复缺陷,或在下一个 sprint 中修复,那你就没有缺陷,你也不需要维护它们了。
2. 恐惧因素:

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

“如果我们决定不修复这个缺陷,它就不在了!我们将永远失去它!”

是的,这是真的,难道你没有感觉到解放吗?

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

很好,也许我们现在会将这个缺陷列为最高优先级,并决定立刻修复它!
3. 我们的团队只有两个人,我们也要使用 0 缺陷规则吗?

如果你们团队只有两个人,你不需要任何缺陷规则,你不该有这些缺陷,你绝对不会分拣它们。
4. 敏捷的一个主要原则不就是人高于过程,0 缺陷规则不是违背了这个原则吗?是的,确实是,根据我的经验,我更喜欢通过文化变革来解决问题,而不是增加过程来解决问题。0 缺陷规则是这个规则的例外,因为只有这个方法起效,其他办法都不能解决缺陷。

结语

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

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

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

关于作者

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

查看英文原文 0 Bugs Policy


感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016 年 6 月 15 日 19:281946
用户头像

发布了 217 篇内容, 共 54.6 次阅读, 收获喜欢 70 次。

关注

评论

发布
暂无评论
发现更多内容

签约落地!百度、山东共建人工智能数据标注产业基地

百度大脑

人工智能 百度智能云

区块链如何赋能数字城市建设?

CECBC区块链专委会

欧洲杯发布首座区块链奖杯:中国设计师创作,灵感来源小篆

CECBC区块链专委会

智慧组工系统搭建,组织部干部任免系统

13823153121

你真的很忙么?

escray

学习 极客时间 朱赟的技术管理课 6月日更

【端午节】TcaplusDB祝大家端午安康!

tcaplus

数据库 游戏 TcaplusDB

5分钟速读之Rust权威指南(二十)

码生笔谈

rust

百度创新发布“炫瞳活体”技术!起底金融级人脸实名认证方案背后的硬实力

百度大脑

人工智能

【21-3】PowerShell 环境

耳东@Erdong

PowerShell Windows Server 6月日更

算法训练营 - 学习笔记 - 第九周

心在飞

《原则》(十)

Changing Lin

6月日更

每日互动CTO谈数据中台(下):从演进、经验到规划

个推

react源码解析10.commit阶段

全栈潇晨

react源码

Python——字符串查找/替换/分割

在即

6月日更

Alibaba大佬用了3个月,把Java后端95%的技术体系都整理出来了!

Java架构师迁哥

【FlinkSQL】Flink SQL Query 语法(一)

Alex🐒

flink 翻译 FlinkSQL flink1.13

常见词向量模型

Qien Z.

6月日更 词向量 SkipGram 矩阵分解 Glove

时代变了,程序员の老冤家IE浏览器离场啦?!

空城机

JavaScript 微软 前端 IE 6月日更

如何在手机上保护自己的隐私?

石云升

隐私保护 数据安全 6月日更

关于 JavaScript 是否加分号的问题

KooFE

6月日更

从 Alpha 到 Beta,这次是 New mPaaS

蚂蚁集团移动开发平台 mPaaS

mPaaS 移动开发平台

☕️【Java技术之旅】带你实战使用String的功能特性

李浩宇/Alex

Java string 字符串 6月日更

绿色数据时代,全闪存与数据中心的注定邂逅

脑极体

Kubernetes手记(7)- 控制器配置清单

雪雷

k8s 6月日更

【FlinkSQL】Flink SQL CREATE 语法

Alex🐒

flink 翻译 FlinkSQL flink1.13

require() 方法详解

编程三昧

nodejs modules 模块 require

MySQL 亿级数据分页的优化

xcbeyond

MySQL 数据库优化 6月日更

MySQL基础之八:外连接

打工人!

myslq 6月日更

真相了!同事金三银四跳槽季斩获11张大厂Offer竟只是因为吃透了这份阿里Java面试核心知识手册

程序员小毕

Java 程序员 架构 面试 分布式

世界海洋日|TcaplusDB与你一同保护海洋生物多样性

数据人er

数据库 nosql tencentdb TcaplusDB

☕【JVM技术探索】Class字节码指令方法调用初探

李浩宇/Alex

Java JVM 6月日更 字节码指令

0缺陷规则-InfoQ