11.5.5 “小强地狱”这种按照小强的数量判断是否需要修复bug的评判标准是否合理?

[GreyZeng]

原文地址

我们都是按优先级来进行的，开发新功能的优先级远大于修复小强的。
如果开发人员的小强（Bug）数量超过一规定值，则此君被送入“小强地狱”，在地狱中，他唯一能按做的就是修复小强，直到小强数量低于此阈值。（《构建之法》 11.5.5）

可以看出，“小强地狱”的唯一评判标准是小强的数量。我的理解是，数量不能成为判定是否必要修复小强的唯一标准，有一些bug会影响产品的总体运行，比如导致测试人员不能测试一些相关的技术点，或是对其他人的开发流程产生影响，比如在思路、数据上对他人有误导，我认为这些bug即使数量很少，也需要立即修复，否则会影响团队中其他成员的进度。一些bug不会导致严重的连锁反应，可以考虑积攒起来，用一段时间集中修复，避免在修复bug和开发新功能之间来回横跳，提高效率。

[GreyZeng]

我们的团队开发并没有使用”小强地狱“这种规则，不过在团队开发中的经历让我并不认同书中”开发新功能的优先级远大于修复小强的“这句话。我们在开发中由于时间比较紧张，所以有一个bug因为对现有开发没有造成影响所以没有及时修复，而是带着这个bug继续开发，结果之后的功能暴露了这个bug，当我们再想去修复这个bug的时候，发现修复难度和工作量都比刚开始大很多。

由此看来，一些bug并不适宜积攒起来集中修复，“小强地狱”这种规则还是比较生硬的，单纯凭借数量判断开发人员是否需要修复bug很容易将那些对之后开发产生影响的bug漏掉，反而影响进度，虽然敏捷开发强调开发的效率，但是从保证项目质量的角度来说，我并不认为开发新功能的优先级远大于修复小强的。
原文地址

[GreyZeng]

从团队项目的开发经历来看，bug应当由相应的开发人员修（谁的锅谁来修），只有通过设定合理的阈值，才能保证项目既快又稳的推进，当初的理解现在读来有些本末倒置之感，在敏捷开发中，萝卜的做法可以说是普遍存在，往往为了保证功能的正常交付而提升开发速率，降低开发质量，抱有后续再测，现在先不管的态度，结果可想而知，Bug极多，所以当超过阈值后，萝卜就应当前去修复自己的bug，否则积少成多，只会降低项目的整体质量。
原文地址