您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 角色 咨询 工具 火云堂 讲座吧   建模者  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
为什么你应该遵守0 Bug 原则?
 
转自网络,火龙果软件    发布于 2016-4-18
928 次浏览     评价:      
 

你处理过无数 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 ,就感觉自己的作品不完美了。由于这个文化,开发者和产品都转而追求高质量标准。 

 

   
928 次浏览  评价: 差  订阅 捐助
相关文章

深度解析:清理烂代码
如何编写出拥抱变化的代码
重构-使代码更简洁优美
团队项目开发"编码规范"系列文章
相关文档

重构-改善既有代码的设计
软件重构v2
代码整洁之道
高质量编程规范
相关课程

基于HTML5客户端、Web端的应用开发
HTML 5+CSS 开发
嵌入式C高质量编程
C++高级编程
 

WEB应用程序UI模版代码编写
C# 编码规范和编程好习惯
什么是防御性编程
善于防守-健壮代码的防御性
Visual C++编程命名规则
JavaScript程序编码规范
更多...   


设计模式原理与应用
从需求过渡到设计
软件设计原理与实践
如何编写高质量代码
单元测试、重构及持续集成
软件开发过程指南


某全球知名通信公司 代码整洁
横河电机 如何编写高质量代码
某知名金融软件服务商 代码评审
东软集团 代码重构
某金融软件服务商 技术文档
中达电通 设计模式原理与实践
法国电信 技术文档编写与管理
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号