作为专业的软件开发者我们应用良好的技术实践，交付高附加值的无缺陷的产品。一旦缺陷出现，高效的敏捷团队会快速对其进行修复，很可能缺陷刚发现就被消除了。然而，这并不是说这些团队要修复所有的缺陷—因为有时利益干系人并不对花费气力修复缺陷心存好感。
典型的缺陷分类
为方便下面的讨论，我们把缺陷归为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
