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中工作两个sprint，然后轮换，因此要为这个team单独设置一个scrum。这样其他的scrum team(被称为feature team)可以不受影响的关心功能的开发和改进。

有些人不愿意长期做bug修复，因此上面的轮换模式很适合。也有极少的人就喜欢修复bug，那么他可以长时间的在triage team中工作。

回到实践中来，一旦发现紧急bug issue增多导致sprint计划被打乱，就应该在redmine backlogs中创建一个新的scrum项目来专门处理bug issue。同时需要增设两个角色：triage developer和triage QA, 这个也是一个scrum项目，有自己的product owner和scrum master来管理。