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

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

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

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

　　衡量一个变量的经济价值通常与它通常所受到的关注度多少成反比。

　　一个常见的需要bug报告的借口是，管理者们需要知道软件的质量现状。由Bug来判断软件质量，这跟由湿度判断好天气一样不靠谱。有可能今天不会下雨，但这并不意味着我会喜欢它，除非外面是零下10度。Alan Weiss在《Million Dollar Consulting》这本书里已经解释的很好了：

　　质量，我耐心的解读这个词，并不是一些管理者眼中的那些，缺陷什么的。但是在消费者的眼中，质量就是有价值的东西。

　　衡量软件质量的报告很容易生成，但是价值很低，为什么不花一点更多的时间去确定实际的产品质量，然后再做出报告呢？一个有用的报告，再次强调一下，是为了同管理者们一起帮助他们做规划，他们是要根据这些报告要做哪方面的决定，并且这些决定对他们来说有多大的价值。无论他们最终怎么样，这才是报告信息的价值。由于来源的不确定性，这些决定和调查可以帮助我们衡量并减少不确定性。

　　不要执著于缺陷跟踪工具，好像他们是安全毯一样，在不同的背景下定义什么样的质量，例如大量的用户注册，会话的承载能力，准确的报告数据，衡量并且跟踪这些和相关风险。然后让它们形象化！看看那些家伙在Finn.no都做了什么-他们在那些跟他们主题有关的twitter作者们的个人简介，照片和人们的评论中解释这些问题。如果客户是快乐的，存在一些漏洞也是问题不大的。如果客户抱怨，跟多少bug是无关的。