如何处理Scrum的缺陷

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