小强地狱(Bug Hell)

 小强地狱(Bug Hell)
会议上，负责测试工作的大牛发飙了。
大牛:开发的同志们，你们手里有那么多小强，为什么都揣着掖着，不舍得修复，让测试人员有事情可做?测试人员反映因为现有的小强没有被修复，有越来越多的小功能点不能进行测试，他们都要没事做了。
二柱:我们的开发任务很重，必须先把新功能全部实现后，再修复旧的小强。
大牛:这是不对的，我们有些小强在你们手头很久了，看似举手之劳，为什么不尽快修复，让我们测试组能继续完成测试?
二柱:我们都是按优先级来进行的，开发新功能的优先级远大于修复小强。
大牛:但是有些开发人员手里头有二三十个小强，难道数量不是一个考虑因素?
阿超:我同意，随着项目的深入，每个人同时既要开发新的功能，也要修复以前的缺陷。由于没有明确的优先次序，一般人都愿意把时间花在开发新功能上。但是我们的确需要平衡进度和质量。有这样的一种方法:小强地狱(Bug Hell)。如果开发人员的小强(Bug)数量超过一规定值，则此君被送入"小强地狱"，在地狱中，他唯一能做的就是修复小强，直到小强数量低于此阈值。这一阈值由团队根据实际情
况来确定，要注意:开发人员同时"入狱"的人数应在全体成员的5%30%之间，若比例太高，则要考虑阈值或小强数量的计算方式是否合理(是否只包括某一严重程度以上的Bug)。在项目过程中，阈值不宜频繁调整，最好事先宣布阈值。
二柱:但是我们已经违反了"最好事先宣布阈值"这一规定。
阿超:如果我们现在要让20%的同志入狱，需要马上运行一个TFS查询看看这一个阈值是多少?是15?好，那我们现在宣布给大家三天时间，第三天后，小强数量达到或超过15的开发人员请入狱，然后每天早上每日例会宣布入狱/出狱名单。
大牛:其实先把所有的功能写完也不错，至少我可以告诉客户"功能写完了"，让他们高兴高兴。

二柱:大牛，这不就是咱们以前项目的情况么?你一直问"功能都写完了，为什么还不能用"?我们一直说"还有一些小问题"，然后小问题总是不能解决，因为要真正解决这些"小问题"的话，我们还得重写一些功能。
阿超:对，很多问题，甚至是大问题，都隐藏在目前的小强后面，如果一味赶所谓的"进度"，到时候有些小强就变成了大怪物，因为我们已经在错误的基础上搭建了很多新的逻辑和功能，这时再来处理一些历久弥新的小强，就有投鼠忌器的麻烦。我们要分析小强，看看这是一个小问题，解决了就万事大吉呢?还是冰山的一角，解决后也许会发现更多、更棘手的问题。或者看似不经意的一个小强会让很多人加班重新实现功能-这就成了设计变更需求-DCR。