• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

像对待牛奶一样对待缺陷

作为专业的软件开发者我们应用良好的技术实践,交付高附加值的无缺陷的产品。一旦缺陷出现,高效的敏捷团队会快速对其进行修复,很可能缺陷刚发现就被消除了。然而,这并不是说这些团队要修复所有的缺陷—因为有时利益干系人并不对花费气力修复缺陷心存好感。

典型的缺陷分类

为方便下面的讨论,我们把缺陷归为3类:

1. 必须马上修复的

2. 重要的,但不是必须马上修复的

3. 未来可能会被修复的

必须马上修复的缺陷非常重要

当他们出现时,我们可能会暂停当前进行中的sprint(甚至终止当前sprint)转而来修复他们。举个例子,一个统计公司主要收入的关键软件中若出现了缺陷,延迟修复这个缺陷必定很愚蠢吧,我们必须马上解决它。因此,这类缺陷存在的时间一般不会很久。

重要的,但不是必须马上修复的

它的确重要,但是还没重要到要中断或终止当前sprint来处理它的程度。虽如此,它们也应尽快修复,可能会被安排在下个sprint中处理。许多团队会把它们加到产品backlog中,并对其进行优先级排序。这个方法很有意义,因为它给缺陷加上了业务上的考量,例如,在下个sprint中,我们能完成特性G,H,I,或者,我们能完成特性G和H,并且修复重要的缺陷。

未来可能会被修复的

未来可能会被修复的缺陷是不怎么关键的,影响小的缺陷。优秀的敏捷团队会在他们发现这些缺陷的时候就处理掉。但是,我也看到很多不是那么勤勉的团队,要不了多久,这些缺陷就会堆成山,拿它们怎么办呢?

首先,我们要确定把他们存储在哪儿。假如缺陷比较多的话,把他们放入产品backlog就会产生一些问题。大部分团队喜欢把产品backlog列表项维持在150个左右。所以把一定数量的低等级缺陷放入产品backlog会让backlog列表项的数量快速增长,以至超过这个上限。

所以,也许该把他们放到专门的缺陷跟踪系统中。但是,让他们在缺陷跟踪系统中越积越多,不仅显示出缺少专业的软件开发素养,而且也创造出了一个不断膨胀的列表,你不得不花更多的时间去管理它。当列表变长时,花费在它上面的时间会更多(管理一个长列表显然比管理小列表要更花时间)。而且,缺陷跟踪系统里的缺陷也“变老了”。

你有没有在这样的项目里工作过?它有一堆满4岁,5岁或更高龄的缺陷?令人尴尬的是,我碰到过。 我们是否可以认为,如果一个系统中的缺陷已经存在很久了,我们就永远不太可能去修复它了?况且,已经那么久了,修复这个缺陷可能是个坏主意—我们也许会让客户对规避该缺陷的既有处理方法不再奏效。 然后我们会得到一堆质问:你们到底做了什么?我们回复:我们修复了缺陷。客户们可能会说:为什么要修复呢?我现在不得不修改我的工作程序。

缺陷应该过期失效

我想我们应该像对待牛奶一样对待缺陷—我们应该给它们贴上保质期。假如你在过期前没有修复这个缺陷,那么它就是馊掉的,扔了它吧。假如它的确是个重要的缺陷,也值得为之付出时间,那当然要重新提交这个缺陷。若是这样的话,你至少知道它是值得去修复的—也许这会促使你增加它的重要性并且真正修复它。

作为一种改进策略,随着时间的推移,应该使用较短的保质期(一个离发现缺陷越来越近的日期)。这种方法将激励我们期望的行为—不让一个缺陷长期存在。也许你会发现,如果一个缺陷存在超过一天(或一个sprint)也许真的不值得修复它,你只会删除它!

 
译者: Scrum中文网

原文作者:Ken Rubin

原文链接:http://www.innolution.com/blog/treat-defects-like-milk

 

 

 

Search
最新敏捷认证课 ~ 火热报名中
3月30-31日
Scrum Master (CSM) 认证课
张宁宁 Lance Zhang 授课
4月20-21日
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
4月20-21日
专业Scrum Master (PSM I) 认证公开课
丁志润 Derek Ding 授课
6月22-23日
专业Scrum产品负责人(PSPO)认证公开课
丁志润 Derek Ding 授课
分类文章
9月15-17日
SAFe ScrumMaster & Leading SAFe官方认证双证班
Eric Liao & Scott Wang 授课
9月18-22日
SAFe认证-SPC SAFe认证培训师导师班
Kurt Jäger & Eric Liao 授课

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280