Bug管理的經驗和實踐

—MILY: 宋體">發表在《程序員》雜志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）�？梢哉f，遍布全球的微軟研發人員能夠保持統一的思維模式、做事及語言習慣，與整個研發流程的配套工具密不可分，其中最重要的就是通過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其實是一個簡單的工具，那么它的重要性體現在什么地方呢？

lANT: normal">         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），但是我看后覺得都不好使，和我在微軟用的差別太大，上�？铺┦兰o公司的 Bug管理系統倒也很像微軟的，但是要花錢買。琢磨著反正我也這一塊非常熟悉了，何不做一個出來自己用？于是決定借鑒微軟的研發流程和Bug管理工具自己開發一個，以便對我們開發新網站、聲訊軟件、客戶端軟件和公司事務管理中出現的問題進行有效的跟蹤處理。

“數字神經系統”中的BugFree是用開放源代碼的PHP+MySQL寫成、基于瀏覽器方式運行的。我以前沒有任何Linux+Apache+MySQL+PHP的開發經驗，但我很幸運的招聘到幾名優秀的Web程序員，可以在短短的兩個月時間內搭建起這樣的系統。其中BugFree是由我的同事王春生開發的，他用了不到一個月的時間就把代碼寫完，讓我很是驚訝，從而認識到基于Linux的Web開發魅力。之后我們測試一個多月，就可以在實際工作中使用并不斷完善�，F在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說明這個問題，然后指派給我；