五月初在跟敏捷团队谈论缺陷管理技术时，大家情绪有些激动。谈论的思想是团队中可能不需要缺陷跟踪工具。看起来这个想法很另类。幸运的是，没有人很直接的反对这个想法，参加讨论的很多人只是说如果不使用这个让人喜爱的东西，会造成一系列的混乱，并对此持有悲观的态度。

　　尽管Lisa提供了一些例子来说明这些工具什么时候会有用，我依然会采取更激进的做法：缺陷跟踪工具仅仅是一种安慰剂，像希望做出一个更好的软件时，抛出一个硬币到喷泉并许下愿望，然后人们会得到一点点温暖和舒适的感觉。

　　几个人坚持认为缺陷跟踪挺重要的，但是他们不能用另外一种更简单及更高效的方法做这件事。一个大众性的观点是：使用缺陷跟踪工具是一个可重复使用的雷达，让团队看到一个缺陷是否重现；不过这一点用自动化测试会更好些。另外一个观点是跟踪bug，确保他们被修复。但是情况不是这样的。跟踪bug导致他们在数据库中积累起来直到被忘记。修复一个bug与修复系统菜单中难懂的标识相比，前者会得到更好的解决。有些人声称缺陷跟踪工具帮助他们分派任务和计划。一个带着便利贴的看板会更好的解决这个问题。更大或者分散的团队也许会从计划管理系统中得到收益，除此之外有很多更高效和不怎么官僚式的计划管理工具要比缺陷记录器好不少。一个非常流行的观点是bug跟踪方便人们生成有用的报告，好像这是一个有说服力的论据。Bug趋势也许对流程改变的跟踪效果很有用，但是你不是真的需要这种形式上的软件-你可以根据快速察看得到的数据生成趋势报告。

　　对软件质量来说，统计所有过去的bug是没什么用的，相对来说更实际的工作更有用些。但是做bug统计的人很多，并且很容易生成统计报告。 Douglas Hubbard 在《How to Measure Anything： Finding the Value of Intangibles in Business》把这个现象解释成为衡量量倒置（Measurement Inversion） ：