Bug管理的经验和实践
—发表在《程序员》杂志2005年第1期57~61页的原文—
孟岩：刘振飞，你好。我知道你以前是方正出版印刷系统的核心开发人员，后来来到微软的Office开发组。我认识你的时候你还在微软工作，状态似乎不错。为什么后来又离开微软了呢？
刘振飞：93年到96年，我在北大计算机研究所读研。96年毕业后，我留在所里继续从事方正核心产品世纪RIP --- PSPNT的研发、维护、升级（还有外围软件开发比如新女娲补字NewNW、PDF流程系统等）。PSPNT是国内比较大的、成功的软件产品，我一直为曾参与研发过这个产品而自豪。
工作中，我模模糊糊地觉得应该有一个清晰的、可控的流程，而不是依靠几个开发“高手”来支撑一个项目。方正人的个人素质非常优秀，集中在一起应该做得更为出色。我在方正的时候最多也就带过10来人的队伍，但即使这么小的团队，已经让我精疲力竭、疲于应付了。我发现面临一个无法解决的难题：如何有效地控制软件研发流程以保证产品质量和进度。我意识到做好一个软件，只靠技术好是很不够的，必须要有一套好的研发流程和配套的支持工具。你也知道国内软件企业的项目经理都是“全才”：需求、设计、编码、测试、维护乃至产品发布都要精通，事必躬亲，但实践中你又不可能样样都精通，所以结果只有一个：四处救火，累得半死但永远看不到尽头。
当时就觉得这么干有问题，但究竟问题出在哪里、如何有效改进都不知道。我最纳闷的是：这么10来号人的研发管理就这么费劲，人家微软上千人、分布全球的Windows、Office研发队伍是怎么有效管理的？我当时深入研究了一些软件工程方面的理论，比如花了一段时间仔细阅读了原版的Rational Unified Process（RUP），觉得很兴奋，RUP里面的研发理论很完备，和几个同事聊天觉得应该按照RUP的去做，但是理论归理论，具体到实际产品开发该如何做，还是一筹莫展。
恰好那时候读了微软（中国）公司前总经理吴士宏的畅销书《逆风飞飏》，提到了微软的企业管理、内部的数字神经系统及相关叙述，非常感兴趣，想去那里看看。刚好有个机会，得到了微软（中国）研发中心Office组的一个PM（Program Manager）职位。在微软的4年中，我先后经历过Office XP、Office 2003的研发，中间还夹着做过Project 2002。微软所有产品的研发都遵循同样的研发模式、使用同样的研发工具来进行管理，只不过产品大小不一、人员配置有点区别罢了。经历这几个大产品的研发流程，加上在方正的体验的对比总结，我觉得自己比较深入的理解了微软做研发的“套路”。
我是C++程序员出身，当PM后就没怎么写过代码，总还想写写。刚好几个朋友开的公司要做网站、短信、声讯，还要对报纸做数据支持，他们需要一个懂研发管理的人去带技术部。我觉得已经熟悉了微软的研发流程，这刚好是一个检验自己所学所思的机会，所以就离开微软去做这家小公司的技术总监了（而且满足我另外的愿望：我对Windows之外的世界充满好奇，比如每天去新浪网看新闻，他们网站是如何做出来的、用到什么样的技术？Linux、开源软件到底怎么回事？）
不过我一直认为微软是一家伟大的公司，很喜欢其工作氛围。特别的，微软的软件研发流程我认为是最先进的，值得大家去学习。
孟岩：那请你介绍一下你所体会的微软研发管理的妙处。
刘振飞：从我理解的角度，微软的研发管理可以从以下几个方面描述：
（1）研发人员分工明确。主要的三个角色： PM (Program Manager)、 Dev (Developer)、Tester三者分工明确、接口清晰，PM来定义需求、书写出来每个功能特性 (Feature)的设计文档(Spec)，Dev写代码来实现这个Spec，Tester来测试 Dev做出来的东西是否符合 PM定义的 Spec，三个角色之间并无必然的上下级关系，只是分工合作完成某个功能(Feature)。我将之形容为“三权分立”，三者之间有效合作并制衡。国内企业好像还没有PM这个角色，而测试人员又往往成为开发人员的附庸，一个 Bug是否要被解决全由开发人员说了算，这很糟糕，就像政治上一个权力没有被有效的制衡一样，一定会产生各种问题。
（2）研发工具很配套。PM将写好的需求设计文档(Spec)保存到 SharePoint文档库中，所有相关的人都可以随时查看；Dev用Source Depot （功能类似CVS的微软内部源代码管理工具）来保存源程序；Tester把发现的Bug记录到Raid中以有效跟踪这个问题的处理流程。
（3）分阶段的研发流程。和任何软件公司一样，微软的研发无非也分为规划、开发、测试、发布等几个阶段。但是微软的研发流程不走形式，可以统一产品组所有员工的思想，并且能够有效地控制住进度。做完一个版本后，还会让所有员工匿名投票，找出这次研发过程中出现的各种问题以便在下个版本中解决 (此过程称为 Postmortem，挺吓人的一个词)。
可以这么比喻，微软这套研发模式让其中的每个人都成了一架高速运转的机器上的各种零件，少数零件坏了不要紧，可以随时更换。当然微软有许许多多技术高手，但我认为更重要是其研发模式保证了软件产品的高品质、可持续发展。
孟岩：提到微软的研发管理，你说过一句话，我印象很深。你说微软的研发管理中，它的bug管理系统是居于核心地位的。你这么说，有什么道理吗？
刘振飞：前面说过，微软所有产品的研发都遵循同样的研发模式、使用同样的研发工具来进行管理。在所有的工具中，我最佩服的就是其Bug管理系统Raid（现在叫Product Studio）。可以说，遍布全球的微软研发人员能够保持统一的思维模式、做事及语言习惯，与整个研发流程的配套工具密不可分，其中最重要的就是通过Raid把整个产品的研发有机的联系起来。阅读每个 Bug，你可以详细的看到大家讨论解决该问题的完整思路。
我曾读过微软Project 2002产品的Architect写的一个备忘录，其中提到： 如果Raid是别家的产品，需要微软每年付出一笔巨大的费用，Bill Gates会支付这笔钱吗？“He wouldn’t be happy, but you bet he would. Microsoft depends on Raid to get the job done.”当时我“心有戚戚焉”，立即给这哥儿们发Email表示赞同之意J 他回信说希望Project能够做的像Raid一样成功，但可惜他要离开微软自己开公司了。
在微软上班，我每天第一件事是打开 Outlook来处理有关自己的重要邮件，第二件事就是打开Raid来看看有关自己的Bug情况，赶快处理。我一直纳闷，微软为什么不把这个Bug管理系统作为软件来出售，那可是任何一家软件企业都需要的啊！
表面上看Raid其实是一个简单的工具，那么它的重要性体现在什么地方呢？
l Raid从一开始就支持多用户
l 一个团队中的所有人都可以创建、指派Bug，或者改变Bug状态
l 用户可以非常自由的去定制Raid
l 基于SQL，很多有用的报告可以被生成出来
l 管理层需要所有Bug都在Raid中被有效的跟踪处理
Raid的价值在于它密切跟踪当前产品的实际Bug状态，使项目组中的成员非常有效的协调他们的工作。大家都很聪明，如果一个工具是容易理解的、而且管理层提供其使用指南（比如Bug怎么被指派和解决），那么简单的工具也能提供巨大的价值。
孟岩：能否请你简要地介绍一下微软的bug管理体制？
刘振飞：在整个产品的研发过程中，特别是在测试产品、修复Bug的中后期，团队中所有人都生活在Raid中：
- 测试人员（Tester）只要发现问题就立即新建一个Bug予以跟踪并指派给相关的开发小组长（Dev Lead）
- 开发小组长会判断这个Bug属于某个特定的开发人员（Dev）并指派给他处理
- 开发人员会根据Bug的详细描述信息找到问题所在，修改程序解决这个Bug并把Bug返回给当初的测试人员；或者有争议的时候，把Bug指派给这个Feature的定义者PM，要求一个澄清说明
- 测试人员在看到某个Bug被解决后，就去验证这个Bug是否真的不存在了，根据最初的发现步骤去证实问题真的解决了就关闭这个Bug；若还能重现，或者不同意开发人员的解法，可以激活这个Bug，返还给当初的开发人员做进一步调查处理
- 当测试人员和开发人员无法达成一致意见的时候，由对应的PM出面做协调，判断这个Bug的严重程度、对用户可能的影响，根据产品的进度和项目资源做出评估，是否真的需要修理掉这个问题
- 管理团队利用Raid来跟踪整个进度：单个人的工作、小组的进度，整个产品研发进度
研发队伍中的所有人都通过Raid来商议、沟通某个Bug是否符合当前解决Bug的“门槛”，决定是否需要真正修理掉这个Bug、如何修理、可能的副作用、如何测试其解决方案等等。每个人可以在Raid中看到某个Bug的全部历史档案，比如几年前发现的一个Bug一直推迟到这一版才解决，前几年大家是如何讨论的，可能的处理思路是什么，都被完整地记录下来了。
每月、每周甚至每天，参与这个产品研发的人都收到一封当前Bug状态的Email：每个人都上有多少Bug，Dev、PM、Tester头上Bug数最多的前5名都是谁，哪个子产品、子模块中的问题还是处于上升阶段，整个Bug的趋势怎么样等等。这是最详尽的产品状况“内参”，暴露在团队中每个成员的面前，一览无遗。只要你的名字被列在Email中，你就非常紧张，因为你脑袋上的Bug比较多、影响整个产品的质量。这些该死的Bug等待着你去快速处理，尽快把自己从排行榜上去掉。每解掉一个Bug，或者把Bug转给另外的人去处理，就会舒一口气，因为头上又少了一个；某一天你头上的Bug数降为0了，心里就会非常高兴J
我觉得微软的Bug处理过程，非常类似于“击鼓传花”的游戏。鼓点响起，你的任务就是尽快把自己手中的“花”（Bug）传给下一个人，不要让它在自己手里耽误很长时间。从表面上看，在微软工作从不打卡、上班时间也很自由、上午很晚到办公室也没人管你，但是有Email跟着、有Bug催着，你永远不可能偷懒。没有人盯着你，只是事情如影随形，而且所有和你相关的事情都是公开的，相关的人都知道，就像处于非常开放的舆论监督之中，除了把事情办漂亮你还能有别的选择吗？
最后要强调两点：
（1）上Bug不仅仅是测试人员的事情，团队中的每个人发现问题时都上个Bug来跟踪；
（2） Raid中不仅仅是跟踪软件功能方面的Bug，其他各种问题如需求文档（Spec）的改动、界面上的错别字、帮助文档的遣词造句问题、某项任务指派等等都可以通过一个Bug来跟踪。
我至今对刚进微软时老板的一句话印象深刻：Everything should be tracked in Raid！
孟岩：就你了解到的情况，国内的公司在这方面怎么样？
刘振飞：在微软这几年，我也一直和国内软件公司的朋友们保持接触。很遗憾的是，国内的一些软件企业，特别是不少中小企业，其软件研发还是处于作坊式的状态，只不过作坊规模有大中小之分罢了。有意思的是，走在国内IT最前沿做各类网站的企业，根据我的了解，也在走软件企业最初几个“大虾”（牛人）搞定一切的阶段。我不是说个人技术好不重要，而是需要更进一步，把研发管理真正搞起来，做出规模效应，从而有效的保证质量、控制进度、把对某个人的依赖尽量降低，并使产品可持续发展。
你知道国内不少软件企业在做ISO9001或CMM认证，花费不菲。少数企业纯粹是为了认证而认证，对付着拿到证书就达到目的了；更多的企业确实是想利用这个认证的过程，把自己的研发流程规范化。但似乎能从这些认证中享受到真正的研发管理提升的并不是很多，甚至开发人员现在需要花费大量的时间去书写一些例行公事的、没有任何实际价值的格式化文档，苦不堪言。
我觉得软件研发管理必须结合自己企业的实际情况，不要生搬硬套书本上的理论，只要人员分工、配置合理，能够控制质量，什么方法都可以采用。黑猫白猫，能抓耗子的就是好猫。千万不要走形式、走过场。
孟岩：其实国内公司在研发方面与微软的差距非常大，也存在于很多方面。为什么你独独看中bug管理？为什么你认为中国中小型企业的软件开发管理规范化，应当从bug管理入手呢？
刘振飞：从微软的研发管理来看主要是需求、开发、测试这三大块，毫无疑问国内公司在开发这个环节一直都很重视，不过需求和测试较弱一点。大家现在都已经认识到充分理解业务需求的重要性，如果没有很好的对项目或产品用户需求的真正把握，后面所有的工作都将是白费工夫、事倍功半，这一块缺乏的是如何有效地将用户的需求转成一份份详细的、后面开放测试人员可以理解的文档。
但是测试这一块大家还是不够重视，对测试人员的素质要求也不是很高、人员比例也较低，测试人员往往依附于开发人员的直接管理，人微言轻。而在微软，测试人员和开发人员的比例很多时候是1比1的，有时候会更高。测试人员和开发、需求人员一样有自己单独的行政管理路线，比如我就注意到有非常资深的测试人员可以做VP，专门管理某个产品的测试工作。这在国内企业来说，几乎就是不可能的。
通过前面的介绍，无论人员的配置和工具的提供，你可以看出微软是非常重视测试的。所以我觉得如果我们学习微软先进的研发理念，可以从测试入手，打造必要的测试管理系统，通过这样的系统，把需求、开发、测试三个环节融合在一起，让团队中所有的人都遵循同样的研发思路：需求人员真正理解用户的业务需要，认真研究后形成需求文档作为产品一个个功能的“合同”；开发人员写出设计文档，然后动手写代码；测试人员理解需求文档，然后测试做出来的功能是否符合最初的设想。整个过程碰到的任何问题都要通过Bug系统来记录、跟踪，相关人员通过Bug管理来商谈、沟通相应的解决方案。
这样通过Bug管理，逐步统一研发人员的思维、做事模式，让整个团队可以有效地运转起来，并不断优化自己项目的软件研发流程，提高产品质量，从而使产品可持续发展。
孟岩：看来你对于bug管理可真是重视。听说你在离开微软后，开发了一个开源项目BugFree，号称是要全面模拟微软的bug管理机制。能介绍一下大致的情况吗？
刘振飞：今年四月我加盟朋友的公司开始做网站，发觉自己已经习惯了微软的研发模式，于是建议这几个朋友先做一个“数字神经系统”，其目的是让一切可以数字化、文档化的信息被记录下来，为公司的进一步发展和决策提供基础信息支持。
BugFree 就是其中有关软件研发的Bug管理系统部分。我太了解Bug管理对软件研发的重要性、也对微软的Bug系统有了深入掌握，所以需要有一个类似微软的Bug系统才好开展工作。虽然网上有免费的Bug管理系统（如Mantis、Bugzilla），但是我看后觉得都不好使，和我在微软用的差别太大，上海科泰世纪公司的 Bug管理系统倒也很像微软的，但是要花钱买。琢磨着反正我也这一块非常熟悉了，何不做一个出来自己用？于是决定借鉴微软的研发流程和Bug管理工具自己开发一个，以便对我们开发新网站、声讯软件、客户端软件和公司事务管理中出现的问题进行有效的跟踪处理。
“数字神经系统”中的BugFree是用开放源代码的PHP+MySQL写成、基于浏览器方式运行的。我以前没有任何Linux+Apache+MySQL+PHP的开发经验，但我很幸运的招聘到几名优秀的Web程序员，可以在短短的两个月时间内搭建起这样的系统。其中BugFree是由我的同事王春生开发的，他用了不到一个月的时间就把代码写完，让我很是惊讶，从而认识到基于Linux的Web开发魅力。之后我们测试一个多月，就可以在实际工作中使用并不断完善。现在BugFree已经成了我们日常工作最重要的工具，每个员工也都习惯用Bug来记录跟踪事情，不仅仅是代码中的缺陷可以上Bug，新的需求、设计变化等都可以用这个Bug管理系统有效的管理起来。其实Bug 不仅仅可以用来记录软件中的缺陷，也可以用来跟踪公司的日常事务。比如在公司的网上报销系统还没有建立之前，我们就用 BugFree来处理报销的事情。甚至，一个同事给我上了这样的Bug：你的桌面太乱了，请整理一下J
命名BugFree 有两层意思：一是希望软件中的缺陷越来越少直到没有，Free嘛；二是表示它是免费且开放源代码的，大家可以自由使用传播。也算为中国的软件业做点小小的贡献，特别的，希望能对国内中小企业的研发流程改进、Bug的有效管理提供参考和帮助。
和微软内部的Raid比较起来，BugFree有如下特点：
（1）Raid是Windows客户端软件，BugFree是基于浏览器的。基于此，Raid 有很强大的编辑展示功能，而BugFree简单、方便、易用；
（2）Raid可以进行极其复杂的组合查询，BugFree的查询功能相对弱一些，但我觉得对中小企业已经够用了；
（3）一个Bug从创建到关闭这个“生命周期”的处理过程，BugFree 全面借鉴Raid的处理流程，处理方法甚至一些词汇都和Raid一样 (所以我现在用BugFree处理Bug的感觉和在微软时候基本一样)；
（4）BugFree 还有一个独创的功能：当一个Bug被指派给你的时候，系统会自动给你发一封邮件，告诉你有个Bug需要你处理，这样结合 Email，BugFree被完美使用起来，成为我们现在网站开发、运行、维护必备的工具。我们还增加了两个Bug统计功能：一是每天早上8点钟每个同事都会收到一封Email，告诉他/她头上还有多少 Bug等待处理；二是每周一中午给所有人发一封邮件，告知上周Bug的处理情况和到目前为止所有Bug的统计数据；
（5）BugFree程序规模很小，一个中等水平的PHP程序员就可以在1~2周内看懂所有的代码，然后就可以根据自己的需要做相应的定制了；
（6）最最重要是，BugFree 是免费并且开发源代码的。你可以体验到微软的Bug管理精髓，按自己需要自由地增加功能、修改代码而不用担心版权问题J
不过坦率的讲，BugFree 仅仅是个工具而已，重要的是掌握其中蕴含的软件研发的流程思想，才能用好这个工具。如果你以前没有用过 Bug管理系统，那么一开始的时候也许你会觉得这个工具是在浪费时间，因为一个测试人员需要费神把发现 Bug的详细步骤记录下来，有时还要贴一张示意图，这一切都不如当面说来得直接。
但是使用一段时间，你会发现 BugFree很有用，它忠实的记录着每个问题的处理过程，不断提醒你存在的问题，永远不会丢失和忘记。如果你参与过较大软件项目或产品的研发，就会理解它对软件可持续发展是至关重要的。而且研发的规模越大，BugFree 的作用就会越大。
感兴趣的朋友，可以到http://www.okooo.com/OpenSource 来体验、下载最新版的BugFree。
孟岩：好的，我们下期结合BugFree来具体看看一个软件开发项目的bug管理应该怎么做。
—发表在《程序员》杂志2005年第2期38~42页的原文—
孟岩：刘振飞，你好。上一期文章里，我们谈到了Bug管理的理念和经验。按照我的体会，Bug的控制是一个管理与技术相结合的课题。做好Bug的管理，一方面需要有完善的管理体系和制度，另一方面更需要有一个坚实的基础平台来支撑。确切地说，就是要有一个比较完善适用的软件，充当Bug管理的中枢神经。显然你是很看重这个软件系统的。我想问你一个问题，如果没有这样的软件系统，而是单方面强化管理，比如制定完善的流程和制度来管理Bug，你看这样可行吗？
刘振飞：从我的经验来讲，只靠制度而没有良好的Bug管理软件，根本无法确保Bug管理的有效性，因为仅靠这些规章制度很可能流于形式、走过场。正如源代码管理一样，如果没有类似CVS或VSS的工具，很难想象一个较大项目中的源代码仅仅靠公司的源代码管理制度和大家的自觉性，就可以让多个程序员之间的不同版本源程序保持同步、不冲突。光有制度是不行的，必须有配套工具来保证这些制度落到实处！
还有，做好 Bug 的管理，应该是从高层领导到中间管理层再到基层人员，都从内心认同其重要性，然后根据自己公司的实际情况制定相关的管理体系和制度，切实执行并逐步形成自己的风格。要实用、不要随波逐流。不能今天一个ISO、明天一个CMM、后天又来个6西格码。工具是思想的载体，再好的管理思想还是要通过工具来实现。购买也好、自己开发也好，必须有个 Bug 管理工具作为基础支撑平台。
孟岩：一个企业如果有意建立自己的“Bug管理神经系统”，大致可以有三种选择，一是购买成熟的商业产品，二是选择类似BugFree那样的开源软件，三是自己开发符合本公司现有架构的Bug管理软件。对于某些公司来说，最后一种模式应该是很有吸引力的。你主持了BugFree的开发，能否告诉我们，开发一个Bug管理系统难不难？
刘振飞：应该说不难，想自己开发一个Bug管理系统的朋友，你首先要明确本公司真正的需求是什么，再就是根据你的需求做出来后一定要在实际产品研发中真正应用起来，根据大家的反馈不断去完善。
像我们开发BugFree，从开始动手写代码到真正能够在公司里使用，前后也就两个月时间。为什么能够这么快做出来呢？最重要的原因是我把 BugFree的需求真正掌握了。我在微软天天使用Raid、时时刻刻和Bug管理打交道。我是站在微软这个巨人的肩上去深刻理解其20多年研发所总结出来的经验，所以四年下来，不让我熟悉Bug管理都难J 当我决定做 BugFree 的时候，脑子里很清楚为什么要做、做成什么模样、应该怎么做、做出来后大家怎么用，每个环节都考虑清楚了。这样真正实现的时候就很快了。
当然仅仅做出来是不够的，还要在实际工作真正使用起来，并根据大家的实践去不断完善这个系统。之所以敢于把 BugFree 开源出来展示给更多的朋友，是因为经过我们近20人的团队10个多月的实际应用，大家一致觉得它是个难得的好工具、是日常工作的好帮手，大家工作都离不开了。
不过，现在有不少成熟的Bug管理软件可以买的到，也有很多开源软件让你自由挑选。BugFree 是免费并且开发源代码的，你可以体验到微软的Bug管理精髓，按自己的需要自由地增加功能、修改代码而不用担心版权问题，为什么不试一试？实在不满意再动手自己造也不迟J
孟岩：那么去买一个成熟的商业产品如何？有什么比较好的选择吗？我听说科泰世纪公司在陈榕的领导下也开发了一个类似微软内部使用的Bug管理系统，你了解吗？还有开源社区里很流行的Bugzilla！，你怎么看？
刘振飞：成熟的Bug管理商业产品应该有不少，比如，IBM提供的Rational ClearQuest、微软将在VS.NET 2005（Whidbey）中集成的Bug管理系统、上海微创提供的BMS、科泰世纪《和欣软件工程管理工具》套装软件中的Bug管理系统等等，都应该不错。开源社区中，你可以选择Bugzilla！、Mantis等Bug管理系统。
老实讲，除了微软相关的Bug管理系统之外，其它的我都不熟悉。不过我认为不同的Bug管理系统之间功能上应该不会差别太大，因为大家都是从软件实践中总结出来的经验结晶，不会说某家有特别独到、别家根本想不到的地方。差别之处主要在于价格、安装配置、易用性、可定制、能修改源程序等方面。
在我决定做 BugFree 之前，曾经考察过上面提到的开源社区Bug管理系统，但是简单研究之后，觉得和我在微软用的Raid差别太大、不习惯；陈榕在微软工作时间更长，他们做的系统也是借鉴微软、最接近我的使用习惯，但是得花钱购买（尽管比起其它商业化Bug管理系统而言，价格不算贵），而且不能根据我自己的要求随便更改，所以干脆自己做一个算了。不管怎么样，我觉得多样性是一件好事，给了大家更多的选择机会。每家公司、项目、人员的状况都不一样，都可以根据自己的具体情况挑选自己喜爱的Bug管理系统。
顺便说一句，通过我自己做BugFree开源的经历，觉得自由软件的真正魅力不在于其零价格，而是其源代码的完全开放，你可以根据自己的具体情况自由的去修改、去定制，完整的控制整个系统。
孟岩：如果有这么一家公司，它接受不了整套的Bug管理制度，打算自己开发一个Bug管理系统，以适应自己企业的需求，让你给参谋参谋，你觉得一个良好可用的Bug管理系统，需要有哪些基本功能？
刘振飞：我觉得一个Bug管理系统需要具备以下外部特征：
1．可以完备的记录、跟踪Bug 的一生：从出生（创建新的Bug）、不断成长（记录相关人员寻找产生Bug的原因的讨论过程）、发育成熟（找到了一个处理办法）到最后死亡（关闭），同时也要允许Bug的复活（问题重现），继续其生长过程。
2．方便的查询功能，快速找到你关心的 Bug。比如：
a). 最近N个指派给我的 Bug
b). 最近N个由我创建的 Bug
c). 各种自定义条件的查询
3．提供各种Bug统计信息。比如每个人头上有多少个Bug、到目前为止Bug总数的统计、最近一周Bug曲线图等等，视具体需要可以有很多种统计。
4．方便的项目和模块管理，可以有很多项目、每个项目有多个模块，要能够很方便的增加、删除、修改。
5．简单的用户管理。作为一个可独立使用的系统，需要能够增加、删除用户。当然最好的是直接使用公司已有的管理系统中的用户认证。比如在微软，只要你登录公司内部网（域）后，你就可以直接使用Raid了，它直接集成了公司的用户认证，不需要单独一套用户认证系统，那样对使用者就很不方便，管理起来也会比较混乱。
孟岩：你结合BugFree具体谈谈，这些功能是如何协同的？开发者、测试工程师和PM在整个开发过程中，是如何围绕这个系统运转的？
刘振飞：先从基础设施说起。首先BugFree有一个独立且简单的用户管理，可以方便的增删用户：
然后是简单的项目/模块管理，管理员可以方便的增加新的项目、新的模块，或者更改已有项目/模块的显示名字：
因为仅仅有管理员才可以进入后台管理，所以这两个后台功能做的比较简单。
这样定义了项目/模块和用户后，BugFree的用户就可以进行Bug的跟踪处理了。举个虚拟的场景，林燕锋、你、我三个人在一家公司做网站，他是测试工程师（Tester）、你是开发工程师（Developer）、我是需求定义者（PM），我们三个负责公司网站的新闻频道：
[1]. 林燕锋发现新闻频道的后台管理中“编辑”功能打开速度非常的缓慢，无法忍受。于是他新建一个Bug说明这个问题，然后指派给我；
[2]. 我看到这个Bug后，赶快到新闻频道的后台试用一下，果然很慢。于是我把这个Bug指派给你，加上我的注释：“孟岩，这项功能使用很频繁，速度太慢直接影响了我们信息编辑的工作效率。请你研究一下这部分代码，看如何调整程序，以加快打开速度。”
[3]. 你看到这个Bug后，作为这部分功能的实现者，去认真地研究了当时的代码，经过调试，发现是数据库查询方式的问题，采用不同的方式之后，新闻编辑功能的速度大大提高了，于是你解掉（Fixed）这个Bug，并把你发现的问题原因和解决方法做了描述：“不好意思，以前的查询方法有点笨，现在已经修改了数据库查询方式，加快了浏览速度，具体改动请参见附件EditNews.php。”因为问题被解决，这个Bug会被自动指派给创建者林燕锋头上。
[4]. 林燕锋看到这个Bug被Fixed了，赶快去验证了一下，发现问题真的消失了，于是他关闭这个Bug，并加上注释：“太好了，刚才用了一下，速度确实快了很多。我代表信息编辑感谢你老兄的工作啊！:-)”
你看这样做，BugFree就非常完整地记录了Bug的一生：如何发现（创建Bug）、不断讨论（编辑Bug）、找到原因（解决Bug）到最后关闭它。这样开发工程师、测试工程师和PM在整个开发过程中，都被一个个情况各异的Bug们牵着鼻子，密切配合，不断发现问题、研究可能的原因、找到处理办法、验证解决方法是否真的凑效。BugFree 让所有项目/产品的研发参与者围着它转，忠实的记录了所有被发现问题的讨论处理过程，即使时间过了很久、我们三个都离开了这家公司，但当时我们处理的思路被保留下来了，后面接手的同事可以完整无误的看到全部的讨论过程，就像有台录像机把这个过程录下来一样。
孟岩：从内部来看，BugFree的架构是怎么样的？
刘振飞：BugFree 是用 PHP+MySQL 写成的。首先我们定义了七个相关数据表：
- BugProject: 项目表
- BugModule: 项目中的模块表
- BugInfo: Bug基本信息表
- BugHistory: Bug处理过程的历史记录表
- BugFile: Bug相关附件表
- BugQuery: Bug查询条件表
- BugUser: Bug的简单用户表
程序代码也是按照前面介绍的Bug管理功能展开的，基本上一个功能对应一个PHP文件，比如：
● Bug的处理过程
- AddBug.php: 加入一个新Bug
- EditBugForm.php: 编辑一个Bug的信息
- ResolveBug.php: 解决一个Bug
- ActivateBug.php: 激活一个Bug
- CloseBug.php: 关闭一个Bug
● Bug的查询
- QueryBug.php: 查询符合条件的Bug
- SaveQuery.php: 保存用户定义的查询条件
- DelQuery.php: 删除一个用户定义的查询条件
● Bug的统计自动通知
- NoticeBug.php: 发信通知每个用户的Bug情况
- StatBug.php: 发信给所有人告知当前Bug统计情况
BugFree 中使用Smarty技术把PHP代码和HTML隔离开，每个涉及到界面的.php文件，都有一个对应的在Template目录下的.tpl文件，这样代码结构就非常清晰，很容易看懂、维护和添加新的功能。
主要目录结构如下：
/ - 根目录下主要存放上述Bug一生处理流程、查询等功能文件
Admin/ - 后台管理对应的文件
BugFile/ - 存放Bug中的附件
Compile/ - 存放Smarty编译后的文件
Document/ - BugFree 的各种说明文档
Image/ - BugFree 中用到的各种图片
Include/ - 公用文件
JS/ - 用到的JavaScript文件
Shell/ - 存放需要定时执行的文件
Template/ - 所有界面模板文件（.tpl）
除去ADO、Smarty等第三方文件，BugFree 自身也就是由30多个PHP文件组成。更详细的说明请参看Document/FileList.txt (代码文件结构)。
所以你看，BugFree 的架构其实非常简单，代码量也不大。想探个究竟的朋友，只要明白了表的结构，然后按图索骥，根据功能逐个查看对应的代码文件就可以了。PHP 程序的复杂度要远小于C/C++，很直观。我觉得一个中等水平的 PHP程序员就可以在1~2周内看懂所有的代码，然后就可以根据需要做相应的定制了。BugFree 仅仅是个小工具而已，没有什么神秘的。
孟岩：看来BugFree的设计考虑是相当细致的。不过很多人都抱怨这个用PHP编写的软件不容易配置，尤其是在Windows环境下。你能否简单地给大家介绍一下BugFree的配置和部署方法？
刘振飞：上一期文章发表后陆续收到一些网友的Email，反映的主要问题是 BugFree 在 Windows平台上的安装问题，而Linux平台上似乎很少人抱怨。这从一个侧面说明在Linux上大家已经习惯自己动手配置、有问题自己能找到解决办法J
坦率的讲，因为时间、精力、资源有限，目前我们对 BugFree的安装配置这一块的测试做的很不够，所以还要请网友谅解。我也是通过这个软件，觉得做好开源项目真的很不容易，需要付出巨大的努力，因而很佩服那些为开源社区贡献优秀软件的人们。
从反馈的情况来看，我想主要的原因有三个：
[1]. 运行环境的版本问题，比如PHP、MySQL的版本
[2]. 程序路径问题
[3]. PHP 的配置参数
目前经过我们实际测试的工作环境有：
● PHP 4.3.8和MySQL 4.0.17 (基于RedHat 9 + Apache 1.3.x)
● EasyPHP 1.7 (我自己在Windows上测试过)
其他环境，如IIS、Apache2、PHP5等，还没有测试过。在Window上使用BugFree需要改动PHP.ini中的下述参数：
allow_call_time_pass_reference = On
error_reporting = E_ALL & ~E_NOTICE
register_globals = On
根据大家的意见，我特别写了一份文档“在 Windows 平台上安装 BugFree 的详细步骤”，公布在 http://www.okooo.com/OpenSource，供大家参考。
若有朋友成功尝试过其他版本的运行环境，欢迎你把详细步骤整理出来发送给我，这样我可以共享给所有网友。这就是开源的好处：和感兴趣的热心朋友们一起不断完善 BugFree。
孟岩：我记得BugFree 1.0开发出来以后，你特别兴奋，跟我说这个系统已经达到了微软内部系统的水准。不过马上你就开始做2.0版。2.0有什么大的改进吗？是你的1.0版还不够完善，还是说你对于Bug管理有了新的认识？
刘振飞：前面提过，BugFree 仅仅是个小小的Bug管理工具而已，所以第一版发布后我觉得从1.0计数有点不好意思，那么庞大的Apache才到2.0了嘛。所以我决定 BugFree 的版本从0.1计数，慢慢往上加J
BugFree 0.1版是在2004-10-11正式公开的。在我们内部使用过程中，逐步累积了不少新的功能需求一直没有来得及添加，而且 Ver 0.1主要有两个不足：
[1]. 最初的代码是10个月前写的，有很多不规范之处。而且PHP代码和HTML代码混在一起，很难阅读和维护；
[2]. 原先的界面看起来不是很美观，感觉有点局促。所以我和负责编程的朋友王春生认真讨论后，决定重新书写 BugFree 的代码，解决已知的若干小Bug，并增加了很多新功能。王春生写了程序，同时在我们内部不断测试使用。终于我可以按计划在2004-12-15公布出来了这个全新的版本 0.2 版。
Ver 0.2的主要的改动有：
n 用Smarty技术把HTML和PHP代码分开，代码很清晰，易于维护
n 多语言支持，目前你可以选择英文界面。增加一个新语言也很容易，就是增加一个对应的文件包含所有的字符串而已（由此BugFree可以走出国门了J）
n 系统配置很灵活，可以根据使用情况自己定义
n 全新的界面，显示空间更大，更加大气
n 增加BugFree的简单用户管理
n 符合你自定义查询条件的Bug改动时，会自动给你发信
n Bug信息中增加了两个字段：操作系统、抄送。“抄送”的功能表示这个Bug有变化时，也会发送给这些人
n 增强BugFree的查询功能
n 增加Bug的多任务分派功能，新建一个Bug时可以同时指派给多个人，这对事务跟踪和数据校对类问题非常有用