作者：Mike Cohn
译者：李洁（Jerry Li）
文本来自于Mountain Goat Software的订阅邮件
当帮助组织考虑如何从现有组织结构中组建敏捷团队时，我经常被问“建立独立的bug修复团队是否一个好点子”。
不，这并不是个好主意。至少有三个站得住脚的理由告诉我们要避免组建独立的bug修复团队。
第一个理由，组建泾渭分明的开发团队和bug修复团队会令开发团队丧失责任心。开发团队应该负责产出高质量的工作。然而，当开发团队成员知道无需修复自己产生的缺陷时，他们就再也不会认真编写代码了。
我认为这是一件普遍而又不显眼的、潜意识的事情：当知道会有其他人来帮自己收拾烂摊子时，每个人都会变得更加马虎一点。
并且，我也见过一些团队故意利用无需修复自己bug的优势，将其工作进度谎报得快于实际进度。这类团队会在产品待办项真正完成之前就宣称已完成。然后，他们就会离开，留下bug修复团队独自修复那些只要他们说出来就能预防的bug
第二个理由，组建独立的bug修复团队会削弱bug闭环反馈。如果产品某部分有特别多的bug，而又是由独立的bug修复团队来解决这些bug，那么编写该产品的人员可能永远都无法从其错误中吸取教训。
Bug和产生过程之间的闭环反馈应当尽可能的短而紧凑，而独立的bug修复团队会阻碍bug的闭环反馈。
第三个理由，组建独立的bug修复团队会让开发团队的速率变得不可信。最后一个冲刺的开发速率更高，是因为团队超水平发挥，还是因为他们做事更加潦草？随之而来的是，任何基于冲刺速率制定的计划也都变得可疑起来。
因此，基于以下三大理由，您应当避免将bug修复的工作从开发团队中分离出来：
1. 它使开发团队丧失了对代码质量的责任心
2. 它削弱了bug和bug产生过程之间的闭环反馈
3. 它使开发团队的速率变得不可信
与组建独立bug修复团队相近的是，组建独立的维护团队。
在一个团队开发下一代产品期间，组建独立的维护团队来负责对当前产品的小需求和bug修复。
一个关键的区别是，维护团队和新产品开发团队都各自负责修复自己的缺陷。
虽然我更偏爱由同一个团队来执行老产品维护和新产品开发，但组建一个独立的维护团队也是合理的。例如，这样做可以让那些从事新产品开发的人员能有更多不受干扰的时间来聚焦于新特性的开发。
因此，组建独立的维护团队，或许是合理的；而然，组建独立的bug修复团队，是绝不合理的。让同一个团队负责修复自己的缺陷，能有助于您在敏捷上更加成功。
