Scrum中管理bug

如果bug来自于正在开发的sprint

会在task阶段就被QA/Scrum Master/Product Owner标记为有bug，并且Story不能被置为done状态，这个很容易解决。

如果bug来自于已经结束的sprint，那么怎么办呢？

理想状态下是将bug放到backlogs中，然后由product owner调整其优先级，并决定放在后面的哪一个sprint中修复。

但是，有些bug处于十分紧急，必须立刻修复。

更糟糕的是，当这类型bug数据达到一定程度后，就影响到了Scrum的整体运作。因为Scrum要尽量保证不要因为突发的事件影响到已经正在进程中的Sprint，而在很多互联网公司有不少bug就是要立刻处理。

当一个团队不断地开发出新的产品，团队细分成若干小团队负责这些产品时，每个产品都可能产生紧急的bug issue.这时候每个Scrum都会受到影响。

下面的博客中的评论提出了一个很好的做法：http://www.mountaingoatsoftware.com/blog/bugs-on-the-product-backlog

John Price提出的观点是设置一个triage team处理所有的bug issue. 这个triage team有至少一个QA，通常也就是这个team的leader，然后每个产品team都出一个开发者。Triage team负责处理所有的bug issue.每个开发者在这个triage team中工作两个s