在Scrum中，进行bug的管理应该分为三种情境：1、bug来自于正在开发的sprint；2、bug来自于已经结束的sprint；3、bug十分紧急，必须立刻修复。其中，如果bug来自于正在开发的sprint，会在task阶段就被标记为有bug，这个很容易解决。
1、bug来自于正在开发的sprint
如果bug来自于正在开发的sprint，会在task阶段就被QA/Scrum Master/Product Owner标记为有bug，并且Story不能被置为done状态，这个很容易解决。
2、bug来自于已经结束的sprint
如果bug来自于已经结束的sprint，理想状态下是将bug放到backlogs中，然后由product owner调整其优先级，并决定放在后面的哪一个sprint中修复。
3、bug十分紧急，必须立刻修复
有些bug十分紧急，必须立刻修复。更糟糕的是，当这类型bug数据达到一定程度后，就影响到了Scrum的整体运作。因为Scrum要尽量保证不要因为突发的事件影响到已经正在进程中的Sprint，而在很多互联网公司有不少bug就是要立刻处理。
当一个团队不断地开发出新的产品，团队细分成若干小团队负责这些产品时，每个产品都可能产生紧急的bug issue，这时候每个Scrum都会受到影响。解决方法：
- 设置一个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来管理。
延伸阅读
如何制定Sprint计划
- Sprint目标
- 团队成员名单
- Sprint backlog(即Sprint中包括的story列表)
- 确定好Sprint演示时间
- 确定每日Scrum会议的时间、地点
文章标题：在Scrum中，怎么有效的进行bug的管理，发布者：Z, ZLW，转载请注明出处：https://worktile.com/kb/p/34016
微信扫一扫 
支付宝扫一扫 
