扫码阅读
手机扫码阅读

如果你不知道怎么改进,就从修Bug开始吧!

146 2024-01-05
本文2539字,阅读约需3分钟。
有人说,我面对团队的研发现状不知从何下手,没关系,可以尝试从修bug开始!然而如果只是简单地改个bug,我也犯不上写一篇文章了。
不管你是什么样的开发方式,瀑布还是敏捷,本文都适用。本文将“大批量生产”和“精益生产”与我们现在的工作相比较进行论述,希望对小伙伴们有所帮助、借鉴和启发。
在大批量生产方式中,为了保持总装线不停顿而允许错误继续传递,第一个差错,不论是零部件有问题或是零部件没有问题但组装不当,很快就和之后工序中的差错相混。这会导致错误不断地倍增。一辆复杂的汽车中只要有一个缺陷的零件,就可能要花费大量的返工去修复它。
做完一点儿,就测试一点儿,如果出现问题,那很快就能定位bug。比如我一共就写了10行代码,测出bug来,那bug大概率就是这10行代码引入的。不但定位和调试的复杂度不高,同时因为程序员的记忆还非常新鲜,代码的上下文以及编码逻辑的来龙去脉记得非常清楚,改bug的速度和质量都会非常高。
如果代码积累一定量再进行测试,那么发现的bug就指不定是哪次代码提交引入的,而且可能多个bug和代码逻辑叠加,加上发现bug的时间点与bug引入的时间点间隔较长,需要程序员更多的时间来回忆,甚至由于有些信息从大脑中丢失带来误导,让改bug工作变得异常艰难。
每个工人都自然而然地认为,所有的质量问题都会在组装流水线的末尾被发现,他的任何导致流水线停止的行动都可能受到惩罚。
我们在工作中是否为了赶进度而不重视研发的质量,开发人员总是想着:“反正有测试人员兜底,他们测不出来是他们的问题,他们测出来了,我再修改,那个时候就进入了改bug阶段,我的研发阶段可是按时甚至超前完成了。”
而且由于要到总装线的末尾才能发现问题,那么可能在发现问题之前,大量的有类似质量问题的汽车都已经下线了。
临上线之前进行的测试,出于测试的规模以及上线时间的压力,不太可能测得那么细致,而且有限的几个测试人员进行测试,不可避免有疏漏,再加上系统本身就很复杂,不可能测出所有的bug,这样很多bug就被放到了生产系统中,成为潜在的逃逸缺陷。这些bug未来要么被客户发现,给客户和公司带来损失;要么在后续的某次测试中被发现并修复,这种情况相对好些。
如果我们能够在前期由开发人员尽早进行测试,或者由测试人员尽早参与到开发阶段,与开发人员共同测试,那么无论从测试的多视角还是细致程度,以及修复的质量和速度上,都会有更大的保障,这样就会让尽可能少的bug流到生产系统中。
在大批量生产的工厂里,出现的问题易于被当作随机事件。其理念是仅解决单个问题,并希望不要再发生。然而事实却是,当今一些大批量生产的工厂里,有20%的厂房面积和25%的总工时时专用于返工的。
我们会发现,非常多的小伙伴们每天像救火一样辗转于各种bug修复中,似乎在他们的眼里,这就是工作,这就是常态,反正干啥不是干啊。小伙伴们可以看看自己的团队,有多大比例的时间是在修bug,有多大比例的人是在专门修bug。这种情况是否有改进的空间,如果有,改进方法是什么?
大野耐一则不然,他制定了一套问题解决制度,叫做“5Whys”。教导生产工人如何系统追溯每个错误的根本原因,然后设计解决方案,杜绝此类错误再次发生。
小伙伴们可以想想,那么多的bug,可能成百上千,它们都是什么原因导致的呢?我相信导致这些问题的根本原因不会那么多,也许只有几个或者十几个,如果我们能够从源头把一个根本原因解决了,那么是不是未来就不会再出现这个原因导致的十几个甚至几十个bug呢?这是完全有可能的!
如何找到根本原因呢?大野耐一的“5Whys”就很好。我们一定要找到这个bug是如何引入的,特别是什么行为没做或者做了什么行为导致了这个bug的引入,那么就要对我们遵循的工作流程进行修缮,增加或禁止某些行为,并要求全员学习并遵守,通过试行有效后,将这个流程固化下来,从而从根本上杜绝此类bug的发生。
如果bug分析的行动计划是“以后我在做需求的时候想得全面些”,或者“我以后测试得更充分些”,那么不会有任何效果。
这就是为什么我们一定要落实到流程的修改,流程的修改一方面能够保证一个人多次进行同样的工作都保持很好的一致性,另一方面能够保证团队中不同人之间工作的一致性,当然这些都要基于大家都能够按照新的流程来做事情。
当大野耐一开始把想法付诸实施时,总装线总是停下来,工人们也很容易感到沮丧。但是当所有的工作小组在识别问题和追溯其根源方面取得经验后,质量问题的数量开始剧减。
当我们希望团队成员花时间和我们坐下来分析bug的根本原因时,团队成员通常都是一脸不情愿和不耐烦,觉得这个时间不产出代码,对他们来说没有价值。他们宁愿淹没在各种bug修复工作中,也不愿意把时间“浪费”在bug根本原因分析上。
对他们来讲,分析bug根本原因耗时,会导致进度受到影响,然而他们似乎看不到当前在解决的大量的bug很大程度是因为以前没有花时间做根因分析。当你问他们是愿意改bug还是做新特性,没有一个小伙伴表示愿意改bug,然而是他们自己为自己创造了要改的bug,这是不是足够讽刺和矛盾?
这里也有几个问题要辩证地去看
是不是上线之前一定要测出并修复掉所有的bug呢?未必,就像我们在生活中也经常有策略地向银行借债(贷款或者刷信用卡)一样,债务不一定就是坏事,技术债也不见得一定是坏事(比如上线时间的重要性远远大于改几个bug的重要性),关键是要有策略进行,并且要及时还债,否则就弊大于利。
还有就是团队成员是否有追求质量的原动力。虽然对组织层级来说,追求更早发现bug并修复bug是一件好事,但对于个人呢,这样做对他个人有什么好处?能关系到他的薪酬,他的晋升还是他的职业安全感?如果都没有啥影响,做啥不是做,那么他为什么要做?这需要管理层在规章制度、企业文化、绩效考核等方面进行引导。
注:本文所引用的文字来源于《改变世界的机器》,James P. Womack,Daniel T. Jones, Daniel Roos

推荐阅读
试点团队到底在试点什么?
变革管理者如果想明白这件事离成功也就不远了
敏捷教练现在是越来越不吃香了
这两天我收到了近10份高水平敏捷教练简历
原来Scrum的这几个会我都白做了
实例化需求的干货都在这里了
因为我看不上,所以我不要学!
国企到底适不适合敏捷?
终于有人把验收标准、验收测试和测试用例的关系说清楚了
如何对软件项目经理进行量化考核?
故事是不是拆得越细越好呢?
凭啥总逼我拆成小故事啊?
大多数人写用户故事的时机都是错的
团队级敏捷真的没你想的那么简单
天哪,你们的迭代竟然是这么玩的!
我也来聊聊传说中的敏捷和小瀑布
快速洞察敏捷研发团队状况之六脉神剑
原文链接: http://mp.weixin.qq.com/s?__biz=MzI4NjkwNzE4MA==&mid=2247484945&idx=1&sn=fb42871e7c34f002373126aa5192333a&chksm=ebd48852dca30144351722f7f5ebf713995ababddfe92875395d6237d76d8a2eb92250ab6de7#rd