[轉載]
孟巖：劉振飛，你好。我知道你以前是方正出版印刷系統的核心開發人員，后來來到微軟的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時可以同時指派給多個人，這對事務跟蹤和數據校對類問題非常有用
n 可以添加多個附件
n 改變Severity的顯示方式
n 有快捷鍵支持
n 用Pear中標準的樹狀列表TreeMenu
n 使用ADO訪問數據庫
目前這個0.2版的代碼質量和用戶界面都有了很大改進，但其中的Bug管理思想和0.1版相比沒有任何變化，只不過代碼更清晰、界面更漂亮、使用起來更方便了。
—發表在《程序員》雜志2005年第3期46~49頁的原文—
孟巖：劉振飛，你好。在這個系列的前面兩篇文章里，我們先是探討了Bug管理的理念和意義，然后又從軟件系統的構建角度更進一步探討了Bug管理技術層面的問題。這次我想我們應該來探討Bug管理中“人”的問題了。當然，所謂人的問題，就是管理制度的問題。有了先進的理念、堅實的軟硬件基礎，還需要有相應的管理制度與之相配套，否則Bug管理就只是一個擺設。你認為一個軟件開發團隊應當制定嚴格的Bug管理制度嗎？沒有一個相配套的管理制度，會有怎樣的后果？
劉振飛：我們在第一篇文章中討論過，微軟的軟件研發可以總結為以下兩點：
（1）．需求（PM）、開發（Dev）、測試（Test）三權分立，分工明確、各司其職
（2）．每個產品的每個版本遵循同樣的模式：流程＋工具＋人，并不斷反饋（以改進流程、升級工具并提高團隊/員工的能力）
回到你這個問題，Bug管理制度其實就是定義Bug處理流程，有了好用的工具之后，我們需要這樣的流程去明確指導如何對Bug進行管理。但是一個軟件開發團隊應當制定嚴格的Bug管理制度嗎？坦率的講，不需要。嚴格的制度在軟件行業就意味著教條、負擔和不切實際，讓一幫聰明的大腦陷入無邊無際的條條框框不能自拔，明知道是包袱還要去背、是火坑還要去跳，直到有一天終于受不了，最終結果不外乎三個：過勞累到、對付一天是一天或者干脆辭職換個工作。因此我覺得應該用“Bug管理指導原則（guidance）”來替換“Bug管理規章制度（rules & regulations）”這個詞。
所以我認為Bug管理就是去制定適合自己團隊實際情況的Bug處理流程和指導原則，制定者（管理層）應該起到真正指導的作用，他們要非常清楚下面這些問題的答案：
l 我們需要測試什么：哪些軟件（網站）、哪些模塊
l 測試人員的分工：什么人負責什么模塊
l 測試工具和環境：巧婦難為無米之炊。你不能安排一個測試人員去測某個模塊，而沒有給他提供必要的軟硬件環境
l 測試的進度安排：干這一行加班是不可避免的，但是需要有度，人不是機器，長期的勞累誰都扛不住。如果時間很緊，那只能去抓重點，要有所不為
l 發現一個問題時，如何用Bug管理工具去創建一個Bug：標題如何寫、嚴重程度、詳細重現步驟、錯誤狀況、期望結果、現場附件、這個Bug去分配給誰
l 當一個Bug被處理掉時，測試人員應該如何驗證并關閉
l 當一個Bug的解決方法有爭議時，誰來仲裁
l 定期的Bug提醒，比如當前每個人的Bug情況
l Bug狀態報告：Bug數目的變化趨勢及我們應該采取的行動
l 階段性的總結反饋：哪些地方我們做的好，哪些做的不好，為什么、如何改進
l … …
沒有這樣配套的Bug處理流程和指導原則，再好的工具都將會是一個擺設、甚至是添亂的工具。就像一個樂隊有非常出色的各種樂器，但樂隊指揮是個外行（就像成龍電影《雙龍會》一個鏡頭），那么演奏出來的一定會是混亂的樂章。
孟巖：根據你的了解，國內中小型軟件開發企業中Bug管理制度方面有什么缺陷？主要的問題是什么？
劉振飛：我想目前中小軟件企業的Bug管理主要存在的問題是：
1. 不重視測試，認為測試人員無關大局，隨便測測就行了。當然這種情況正在逐步好轉，因為大家都開始意識到了測試重要性；
2. 有些企業，認識到測試的重要性后，卻走向極端 --- 制定了極其嚴格的規章制度：無數瑣碎、難用的測試工單、非常嚴密的一級級權力控制，在Bug管理系統中誰能看到什么信息、誰可以解決、誰可以關閉等等，非常嚴格。一個需要靈活變化的工作變成了工業制造車間流水線的一個工種，讓測試人員陷入制度的泥潭，不能把主要精力投入測試工作本身；
3. 管理層自身沒有制訂明確的Bug處理流程及相關指導原則，讓測試人員在黑暗中摸索，走到哪兒算哪兒，不能給他們以切實有效的指導和幫助；
4. 管理層把軟件的質量保證責任一股腦推到測試人員身上，任何問題都去指責下面的測試人員，殊不知測試僅僅是研發的一個環節，前面需求、開發兩個環節如果沒有好好做，測試將會極其被動，比如：沒有需求文檔，怎么測試？這是一個系統工程；
5. 錯誤的考核標準：管理層用Bug個數去衡量測試人員的工作成績，誰發現的Bug多誰的工作就做的好。這是一個十分危險的傾向，將直接導致測試人員去重視Bug個數這個數字本身、而不是產品的真正質量。
遺憾的是，即使在微軟內部，各個地方研發中心也有這個傾向，比如經常出現大陸、臺灣、韓國、日本四個地方某個軟件的測試人員虎視眈眈的在半夜盯著某個版本的問世，一旦下載到最新的Build，馬上安裝測試，把表面上的Bug趕快“搶”到、記錄進Raid/Product Studio中，然后心滿意足的打車回去，很高興比另外三個對手多上了幾個Bug。我記得微軟內部有個專門的培訓曾認真的研討過這個問題：不能用Bug數目來衡量Tester的工作。但是微軟太大了，當某地方或部門不能找到更合適的標準的時候，Bug數目本身就是最快捷的答案了。
這是我現在經常思考的問題之一。
孟巖：能否請你比較系統地闡述一下微軟的Bug管理制度？
劉振飛：其實前兩篇文章已經陸續談過微軟的Bug管理指導原則了，這里系統的總結一下：
u 管理層要求所有的Bug都要通過Raid（Product Studio）來跟蹤處理。這個看起來很簡單的Bug管理工具是每個員工和其他同事有效協作的重要保證
u 每個產品都細分模塊（Area，SubArea），每個模塊都有明確的需求定義者（PM）、開發工程師（Dev）和測試工程師（Tester）這三個角色。一個問題出現了，一定會落實到某個人的頭上去跟蹤處理，絕不能出現“無主”的Bug
u PM負責書寫的Spec是這個功能特征（Feature）的“合同”，以此Spec來指導開發和測試。當Dev和Tester就某個Bug發生爭執的時候，PM負責給出一個明確的說明
u 測試不僅僅是Tester的事情，盡管那是他們的專職工作。研發團隊中的所有人每發現產品的問題時候，都有義務把這個問題告知負責這個模塊的測試人員去記錄跟蹤這個Bug，或者干脆自己新建一個Bug來跟蹤
u 你可以創建一個Bug指派給自己，以跟蹤某件事的處理。比如開發人員把源代碼中的某處問題用Bug記錄下來，以后抽出時間來進行處理
u 團隊中的所有人都可以創建、指派和更改Bug的狀態
u 當你創建一個Bug的時候，描述一定要足夠詳細，讓下面處理Bug的人和其他關心這個Bug的同事能夠通過Bug描述準確的重現這個問題，而不是猜測某些步驟或者跑過來當面問你
u 通常一個Bug的處理過程是這樣的：
1. Tester發現一個問題，到Raid中創建一個Bug，描述這個Bug的詳細信息，比如重現步驟（Repro Step）、錯誤結果（Result）、期望的改動（Expect）、運行版本等；然后把這個Bug指派給負責該模塊的Dev Lead
2. Dev Lead判斷后把這個Bug指派給某個特定的Dev
3. Dev處理掉這個Bug并返還給原Tester，或者請求PM給出一個澄清說明
u 管理層通過Raid來跟蹤整體進度，以及每個員工、團隊在其中的貢獻
u 有專人定期給相關同事發出Bug的狀態報告
u 每個人都可以方便的自助查詢Bug的分布處理情況。Bug管理系統對所有的團隊成員都是毫無保留的敞開大門（除了你不能刪除Bug，另外所有的操作都被忠實的紀錄下來）
u 隨著時間的推移，管理層要逐步給出明確的Bug解決指導方針：哪些Bug是可以不理睬的（Won’t Fix），哪些是可以推遲到下個版本處理（Postponed）。比如在最終Build到來前的幾周，也許非常嚴重的Bug，像數據丟失、程序崩潰之類的也都要推遲到下個版本再解決了。
u 當一線員工出現爭執、無法達成一致意見的時候（盡管這種情況不多見），管理層要快速給出處理意見等等。
孟巖：在微軟，如果違反了這些制度，會有什么后果？
劉振飛：哈，這個問題有意思。我還真沒有仔細考慮過，如果一個研發人員在微軟違反了這些“Bug管理制度”，會有什么結果？他一定不會因此被開除J，不過他肯定會努力學習和適應這些Bug處理原則，他的直接上司也會指導他如何做才是正確的。
讓我們換個角度去考慮這個問題。Bug管理是研發管理的有機組成部分，而研發管理是微軟企業管理極其重要的部分，只有好的企業管理才能把業務做好，業務做好了，公司就有好的利潤，這樣公司發展了員工也跟著賺錢了。微軟可以很奢侈的在眾多求職者中招聘到合適的員工，這個員工進來后不可能對微軟近30年研發總結出來的“Bug管理制度”發生抵觸情緒、甚至有意去違反破壞這些處理原則，他所能夠做的只能是快速去體會、理解、適應這些流程和指導原則。
我曾聽到這樣一個故事：國內某大型軟件企業研發老總訪問微軟，詢問如何進行研發管理，微軟一位研發高層答曰：很簡單啊，定期看看Email發來的Bug報告和曲線圖，然后通過Email告訴各軟件負責人，下一步應該注意哪些問題就可以了。我們國企老總很愕然，百思不得其解。如果沒有相關的軟件研發流程和指導原則、配套工具以及熟悉這些的員工，管理層無論如何達不到這樣的“輕松自在”--- 用Email進行研發管理。
有時候想，我們需要“拿來主義”。與其羨慕Bill Gates的錢袋、痛罵微軟帝國的“霸權”，還不如好好研究學習人家的研發管理和企業管理：如何把幾萬個聰明的腦殼有效的管理起來？如何讓分布全球的幾千名研發人員每隔上18個月生產出新版本的Office和Windows？為什么我們上百人、幾十人甚至幾個人的軟件企業就管理不好？
孟巖：在整個Bug管理的系統中，測試人員是非常關鍵的一個角色。以前測試人員在團隊里的形象好像是灰色的，這兩年各公司都開始重視測試工作和專業測試人員的培養。你覺得測試人員在Bug管理體系中處在一個怎樣的位置上？測試人員與開發人員之間的關系如何？
劉振飛：測試人員在整個軟件研發管理體系中都是一個十分重要的、無法替換與省略的角色。經過多年產品研發的體會，我現在無法想象一個軟件企業沒有或者不重視測試和測試人員。就像沒有經過質檢人員檢驗過的流水線生產出來的電視機，能出廠嗎？會有人買嗎？
測試人員和開發人員是對立統一的關系。說對立，是因為測試人員需要專門挑出開發人員做出來的功能模塊的毛病、發現其考慮不周的地方；說統一，這兩個角色需要努力協同工作，把負責的模塊做好。只有每一個模塊問題減少了，整個產品才能提高質量；好質量才有好價錢；公司賺到錢了大家才能有好收入。所以開發和測試是同一戰壕里的戰友，只有共同努力才行。
孟巖：現在很多開發工程方法提倡“全員測試”，很有點類似日本企業里流行的“全員質量管理”。特別是單元測試已經將功能性測試變成開發人員的一項職責，這是否與Bug管理體系有沖突？全員測試是否會導致責任的不清晰？你覺得單元測試與Bug管理是否矛盾？能否協同工作？
劉振飛：一點也不矛盾。開發人員把一個功能模塊送去測試的時候，應該已經把最基本、最常用的功能邏輯測試通過，否則測試人員發現這些基本問題后，很快還得退回去給開發人員，這樣雙方都費時費神。
我所理解的“全員測試”就是每個人當發現問題的時候，不能說“這是測試/研發人員的事情”而置之不理，而應該把這個問題記錄到Bug管理工具中，或者告訴相關的測試人員去跟蹤。產品是公司的產品，是大家共同的飯碗。當然測試人員的專職工作就是去分模塊測試，而且測試得有計劃、有條理、有總結歸納；別的同事可能不是那么系統化而已。
在Office 2003（Office 11）發布后啟動的下一版Office 12研發伊始，微軟Office組的管理層就根據大家的反饋，啟動了一項叫做“Engineering Excellence”的活動，全面總結上一版研發流程中經驗教訓，提出了十多條大的、具體的過程改進辦法全面執行，其中有一條叫做“Feature Crews”，就是加強測試：在把源代碼check in到代碼庫之前，就開始測試一個功能特征（Feature）。該Feature對應的PM、Dev、Tester緊密合作在本地Build上，當一個Feature進入總產品代碼庫的時候應該經過認真測試、非常穩定可靠，就是說把測試工作大大往前（開發階段）提了。當然Office組有專人立即設計、開發相關的支撐工具去保證“Feature Crews”這個新方法能夠順利執行。當我第一次看到這份“Engineering Excellence”活動說明時，真是佩服得五體投地！！很多像這樣具有優秀管理、執行能力的各個小組織，組成了微軟公司優秀的大團隊。
孟巖：這樣吧，假設你領到一個團隊進行軟件開發，以BugFree為基礎進行Bug管理，能否簡單地介紹一下你打算制定怎樣的Bug管理協作制度？比如，有哪幾個角色，角色之間如何協作，那些規定需要作為硬性要求保證執行，如何保證等等。
劉振飛：我現在還真是正在帶領著一個團隊去這么干（北京金環天朗通信技術發展有限公司 http://www.newsky.cn/）。我所計劃的Bug管理指導原則是：
ü 產品（WAP、彩e或彩信雜志、網站等）中碰到的所有問題都要用BugFree來跟蹤處理
ü 有一個專職的測試小組
ü 團隊中每個同事發現一個問題時，都有義務去告知相關的人員或者直接創建一個Bug
ü 需求、開發、測試三個角色的定位要非常明確。特別的，提出需求的人要把需求認真考慮好、細化成文檔，然后才能提交正式開發、測試
ü 發現一個Bug時，測試人員提交給某個開發小組長，他來負責指派給具體的開發人員；產生爭議的時候由需求定義者來出面說明；“矛盾”很大時我來協調和仲裁。Bug的處理過程都要用BugFree記錄下來：
ü 每天系統自動通知頭上有Bug的人自己還有幾個問題。我會檢查這些Bug，看到不合適的地方就去添加我的意見
ü 每周系統自動通知所有人前一階段Bug的整體情況；同時測試小組要匯總上周的Bug測試情況，告訴團隊中所有同事哪些模塊容易出問題、主要有哪些類型的問題
上面這些我能夠作為“硬性要求”的，只能是前兩條：
? 任何人再向開發人員反映問題的時候，開發人員會告訴他們：創建一個Bug來跟蹤
? 剛剛成了一個測試小組
其余的只能融化在日常工作中，管理層不斷在很多細節上要求、甚至親自示范（比如我會使用不同的產品，發現問題上Bug），去教會大家測什么、如何測、發現問題怎么辦、Bug解決后怎么辦。
因為整個研發團隊剛招聘了不少新人，由于歷史的原因以前也沒有重視測試工作，大家這方面的經驗相對而言比較少，所以目前我最重要的工作是給大家不斷灌輸這些意識，手把手去教他們如何創建一個Bug、解決一個Bug時應該怎么描述、提供哪些信息等等。坦率的講，這個過程會非常辛苦勞累。去年我在的公司比較小，一切我都可以從零開始設計規劃。但現在不同，因為公司業務有很多、人員也有了一定規模、以前的程序有很多，而且基于這個行業自身的特點，新的需求很多、變化非常頻繁，所以在這種情況下如何把研發流程理順、Bug管理到位，對我也是很大的挑戰。我會根據對業務的深入理解去不斷調整、細化上面提到這些“制度”。
孟巖：BugFree在設計上為此作了什么特別的考慮？
劉振飛：我想主要有這么幾點：
（1） BugFree是基于Web的Bug管理系統，我們研發人員很容易上手使用、簡單方便
（2） 一個Bug從創建到關閉這個“生命周期”的處理過程，BugFree 全面借鑒微軟內部工具Raid的處理流程，處理方法甚至一些詞匯都和Raid一樣，代表著“先進的生產力”J
（3） 當一個Bug被指派給你的時候，系統會自動給你發一封郵件，提示有個Bug需要你處理，這樣結合 Email，不斷提醒研發隊伍Bug的存在和進展。我們還增加了兩個Bug統計功能：一是每天定時（比如早上8點鐘）每個同事都會收到一封Email，告訴他/她頭上還有多少 Bug等待處理；二是每周一中午給所有人發一封郵件，告知上周Bug的處理情況和到目前為止所有Bug的統計數據
（4） 很方便的去自定義查詢條件，以后輕輕點擊一個按鈕隨時查看你關心的Bug
（5） BugFree是用開源的PHP+MySQL寫成的，規模很小、代碼也很規范，所以需要的時候很容易定制或擴充功能。
孟巖：非常感謝你，劉振飛。我們通過這三期訪談，已經較全面地談到了Bug管理的方方面面。從前兩次的反應來看，很多讀者都對這個話題非常感興趣，你能否用三句話總結一下你的主要觀點？
劉振飛：
1． 測試是軟件產品研發的重要一環，需要IT企業的高度重視，就像重視開發一樣。
2． 選擇一個得心應手的Bug管理工具，比如使用最接近微軟內部Bug管理系統的開源軟件BugFree ，是免費的！J
3． 明確Bug管理的流程和指導原則，并把這些意識逐步灌輸到每個研發人員頭腦中；同時根據企業的具體情況不斷去完善測試流程和方法。
也真誠感謝你做這次訪談，通過這么多有啟發性、很有條理的問題，我算是有機會把這么多年的軟件研發經驗、特別是Bug管理的體會系統的總結一下，給自己留下一份很有意義的記錄。同時借這個機會，也感謝給我Email探討Bug管理實踐以及BugFree系統的讀者朋友表示感謝，如果這三篇訪談能對大家的實際測試管理工作有所幫助、BugFree能夠被真正使用起來，那我就非常自豪和快樂了。
另外，我也會根據自己的使用經驗和網友們的反饋，逐步完善BugFree，讓它成為一個長期的、有生命力的開源項目。
孟巖：最后一個題外話。我知道你現在從事研發管理工作，招聘過不少技術人員，對那些未走出校門的大學生和剛剛踏入社會的大學生們，有什么意見和建議？
劉振飛：春節后我剛剛完成我們部門今年的第一輪招聘，一共收到了1000多封簡歷、面談過近100人，最后錄取了9名新同事。去年也曾招聘過一些新人；一方面是很多大學生工作不好找、另一方面是很多企業招到一個合適的人也很費勁。在招聘過程中，真是什么情況都碰到過。
作為一名有幾年工作經驗的老畢業生，我想對年輕的學弟學妹們提幾點建議以共勉：
1. 爭取做一個善良的人、多站在別人的角度上去考慮問題。
2. 要樹立為自己努力工作的心態，你不僅僅是為老板打工。如果對工作不滿，趕快換一個，千萬不要耗著；我們比上一代人幸運、可以有更多的選擇工作機會，所以不要浪費自己的青春年華。
3. 珍惜在學校讀書的四年寶貴時光，打好專業基礎（比如計算機專業的起碼應該把離散數學、數據結構認真搞明白）、提高基本素質（比如誠信、溝通表達及團隊協作能力）。
4. 如果你想朝技術方面發展，多去鉆研鉆研那些優秀的開源軟件，學習別人的智慧；
5. 擺脫那種非常純的技術情結，要逐步明白在市場經濟的企業中，業務、管理最重要，技術是一種“后勤支持”，沒有我們想象的那么重要。
6. 不斷學習來提高綜合素質。技術之外的書籍：哲學、歷史、經濟、文學等都需要好好讀一讀。古人云，“世事練達即文章，處處留心皆學問”。比如我看電影和話劇的時候，覺得這兩樣和軟件研發非常相似，劇本就是需求、演員就是開發人員、彩排類似測試，導演呢就像一個項目經理，一個票房很高的電影就像很受歡迎的軟件產品一樣。
7. 身體是革命的本錢。毛主席他老人家的這句話千真萬確，健康的身體是扛住工作和生活壓力的重要保證。
8. 想辦法去慢慢培養自己金錢和管理意識，碰到合適的機會也可以嘗試自己創業，即使失敗了也可以學到很多書本之外的知識。難道陳天橋生下來就注定要當中國大富豪嗎？王侯將相，寧有種乎？