Scrum中关于缺陷的处理，除了要修复它之外我没有更特别的建议。scrum一贯的做法是把所有要做到事情都加入产品backlog列表中。基于这个观点，我在这篇短文就要处理的事项以及何时处理给出一个总结，希望能给大家带来些帮助。
首先：不要把缺陷称之为“bug”
区分开缺陷和bug似乎有些可笑。但是在硬件开发过程中“bug”是指一个真正的故障。比如设备发热导致的故障—电路板上一根引脚被放到了错误的位置，产生了短路，并突然间被烧毁。这些都是真实的事件而不是一种脑子里想象出的东西。
有意思的是，这个故障（bug）中断了电路板的开发，这是由外部因素导致，而不是因为开发过程管理不善导致的。因此，在软件开发中提到bug更像是在向外推脱责任，而不是简单地承认自己犯了错。为了避免产生更多的缺陷，我们不仅要修复缺陷，还要改进工作方法。
那么什么叫做缺陷呢？
缺陷就是软件产品的错误表现。它不符合用户/客户/干系人描述的或PO统一收集的验收标准。缺陷不是我们发现的遗漏的地方，也不是现有产品待改进的地方—这些都更像是变更。
进行这种区别的目的是为了避免你可能经历过的相关争论，并且帮助我们理解如何处理这2个不同的概念。
如何处理缺陷，变更和未完成事项
首先，想象你正处于一个sprint中，正在处理一个产品backlog条目（可能是一个用户故事），这时你发现根本没法完成，因为无法达到验收标准。或许正是是因为那些你在开发时发现的缺陷，阻碍了你完成这个用户故事。敏捷团队倾向于马上解决这些缺陷，否则的话他们必须继续处理这些未完成的工作（类似于精益“零库存”）
其次，在sprint结束时，根据对完成的定义你完成了所有的用户故事。在评审会议上演示一个用户故事时，发现它并不符合客户的意图。假设这个异常操作在sprint开始之前并没有和PO一起讨论过，而且你们都知道如果你们就是产品的用户的话，你们是不会接受它的。这时，我们不应该急着找出一个人来为这个错误负责，而是要专注于如何在下次做得更好。在这个例子中，你的产品确实可以运行起来，但是你还应该向产品backlog中添加一个条目—修改这个预期外的产品行为，提升用户体验。这没必要被认为是返工或烂工作，在频繁的试错与改错中不断地学习，这是再自然不过的事情。
处理缺陷是一个痛苦的过程。这个痛苦促使我们想办法制定一套流程来管理他们，并为之做好计划。像这种复杂的缺陷管理流程是徒劳的。这不是在给这些混乱的缺陷排序，而是在回避找出造成缺陷的原因。
另外，在当前的Sprint中解决你能解决的所有问题，不管它是一个缺陷，还是一个好主意—也请记得要和PO分享。
如果在Sprint中，你发现了一个缺陷或者变更，但是你没有足够的时间去更改它，那么创建一个Backlog 条目，然后继续你当前的工作。是否接受你创建的条目，那由PO决定，但是不管怎样，接下来的Backlog 条目将会使Sprint更好。
请始终在回顾会议中想着这些情况，并从中吸取经验。
最后的警告
缺陷确实不好处理，因为很难去重现和修复它们。我没有真正的良方去帮助你更好地处理缺陷，但是我们可以做很多事情来避免产生缺陷。在应用开发中最好的编程原则是“先写测试用例”，结合测试驱动开发TDD和验收测试驱动开发ATDD，能够更好的提高代码的质量。努力提高代码质量在长期投资中可以得到更高的回报，大多数的敏捷团队能够很快的意识到这点。
原文链接：http://agileatlas.org/articles/item/how-to-handle-defects-in-scrum
