孟巖：劉振飛，你好。我知道你以前是方正出版印刷系統(tǒng)的核心開發(fā)人員，后來來到微軟的Office開發(fā)組。我認(rèn)識你的時候你還在微軟工作，狀態(tài)似乎不錯。為什么后來又離開微軟了呢？
劉振飛：93年到96年，我在北大計算機研究所讀研。96年畢業(yè)后，我留在所里繼續(xù)從事方正核心產(chǎn)品世紀(jì)RIP --- PSPNT的研發(fā)、維護、升級（還有外圍軟件開發(fā)比如新女媧補字NewNW、PDF流程系統(tǒng)等）。PSPNT是國內(nèi)比較大的、成功的軟件產(chǎn)品，我一直為曾參與研發(fā)過這個產(chǎn)品而自豪。
工作中，我模模糊糊地覺得應(yīng)該有一個清晰的、可控的流程，而不是依靠幾個開發(fā)“高手”來支撐一個項目。方正人的個人素質(zhì)非常優(yōu)秀，集中在一起應(yīng)該做得更為出色。我在方正的時候最多也就帶過10來人的隊伍，但即使這么小的團隊，已經(jīng)讓我精疲力竭、疲于應(yīng)付了。我發(fā)現(xiàn)面臨一個無法解決的難題：如何有效地控制軟件研發(fā)流程以保證產(chǎn)品質(zhì)量和進(jìn)度。我意識到做好一個軟件，只靠技術(shù)好是很不夠的，必須要有一套好的研發(fā)流程和配套的支持工具。你也知道國內(nèi)軟件企業(yè)的項目經(jīng)理都是“全才”：需求、設(shè)計、編碼、測試、維護乃至產(chǎn)品發(fā)布都要精通，事必躬親，但實踐中你又不可能樣樣都精通，所以結(jié)果只有一個：四處救火，累得半死但永遠(yuǎn)看不到盡頭。
當(dāng)時就覺得這么干有問題，但究竟問題出在哪里、如何有效改進(jìn)都不知道。我最納悶的是：這么10來號人的研發(fā)管理就這么費勁，人家微軟上千人、分布全球的Windows、Office研發(fā)隊伍是怎么有效管理的？我當(dāng)時深入研究了一些軟件工程方面的理論，比如花了一段時間仔細(xì)閱讀了原版的Rational Unified Process（RUP），覺得很興奮，RUP里面的研發(fā)理論很完備，和幾個同事聊天覺得應(yīng)該按照RUP的去做，但是理論歸理論，具體到實際產(chǎn)品開發(fā)該如何做，還是一籌莫展。
恰好那時候讀了微軟（中國）公司前總經(jīng)理吳士宏的暢銷書《逆風(fēng)飛飏》，提到了微軟的企業(yè)管理、內(nèi)部的數(shù)字神經(jīng)系統(tǒng)及相關(guān)敘述，非常感興趣，想去那里看看。剛好有個機會，得到了微軟（中國）研發(fā)中心Office組的一個PM（Program Manager）職位。在微軟的4年中，我先后經(jīng)歷過Office XP、Office 2003的研發(fā)，中間還夾著做過Project 2002。微軟所有產(chǎn)品的研發(fā)都遵循同樣的研發(fā)模式、使用同樣的研發(fā)工具來進(jìn)行管理，只不過產(chǎn)品大小不一、人員配置有點區(qū)別罷了。經(jīng)歷這幾個大產(chǎn)品的研發(fā)流程，加上在方正的體驗的對比總結(jié)，我覺得自己比較深入的理解了微軟做研發(fā)的“套路”。
我是C++程序員出身，當(dāng)PM后就沒怎么寫過代碼，總還想寫寫。剛好幾個朋友開的公司要做網(wǎng)站、短信、聲訊，還要對報紙做數(shù)據(jù)支持，他們需要一個懂研發(fā)管理的人去帶技術(shù)部。我覺得已經(jīng)熟悉了微軟的研發(fā)流程，這剛好是一個檢驗自己所學(xué)所思的機會，所以就離開微軟去做這家小公司的技術(shù)總監(jiān)了（而且滿足我另外的愿望：我對Windows之外的世界充滿好奇，比如每天去新浪網(wǎng)看新聞，他們網(wǎng)站是如何做出來的、用到什么樣的技術(shù)？Linux、開源軟件到底怎么回事？）
不過我一直認(rèn)為微軟是一家偉大的公司，很喜歡其工作氛圍。特別的，微軟的軟件研發(fā)流程我認(rèn)為是最先進(jìn)的，值得大家去學(xué)習(xí)。
孟巖：那請你介紹一下你所體會的微軟研發(fā)管理的妙處。
劉振飛：從我理解的角度，微軟的研發(fā)管理可以從以下幾個方面描述：
（1）研發(fā)人員分工明確。主要的三個角色： PM (Program Manager)、 Dev (Developer)、Tester三者分工明確、接口清晰，PM來定義需求、書寫出來每個功能特性 (Feature)的設(shè)計文檔(Spec)，Dev寫代碼來實現(xiàn)這個Spec，Tester來測試 Dev做出來的東西是否符合 PM定義的 Spec，三個角色之間并無必然的上下級關(guān)系，只是分工合作完成某個功能(Feature)。我將之形容為“三權(quán)分立”，三者之間有效合作并制衡。國內(nèi)企業(yè)好像還沒有PM這個角色，而測試人員又往往成為開發(fā)人員的附庸，一個 Bug是否要被解決全由開發(fā)人員說了算，這很糟糕，就像政治上一個權(quán)力沒有被有效的制衡一樣，一定會產(chǎn)生各種問題。
（2）研發(fā)工具很配套。PM將寫好的需求設(shè)計文檔(Spec)保存到 SharePoint文檔庫中，所有相關(guān)的人都可以隨時查看；Dev用Source Depot （功能類似CVS的微軟內(nèi)部源代碼管理工具）來保存源程序；Tester把發(fā)現(xiàn)的Bug記錄到Raid中以有效跟蹤這個問題的處理流程。
（3）分階段的研發(fā)流程。和任何軟件公司一樣，微軟的研發(fā)無非也分為規(guī)劃、開發(fā)、測試、發(fā)布等幾個階段。但是微軟的研發(fā)流程不走形式，可以統(tǒng)一產(chǎn)品組所有員工的思想，并且能夠有效地控制住進(jìn)度。做完一個版本后，還會讓所有員工匿名投票，找出這次研發(fā)過程中出現(xiàn)的各種問題以便在下個版本中解決 (此過程稱為 Postmortem，挺嚇人的一個詞)。
可以這么比喻，微軟這套研發(fā)模式讓其中的每個人都成了一架高速運轉(zhuǎn)的機器上的各種零件，少數(shù)零件壞了不要緊，可以隨時更換。當(dāng)然微軟有許許多多技術(shù)高手，但我認(rèn)為更重要是其研發(fā)模式保證了軟件產(chǎn)品的高品質(zhì)、可持續(xù)發(fā)展。
孟巖：提到微軟的研發(fā)管理，你說過一句話，我印象很深。你說微軟的研發(fā)管理中，它的bug管理系統(tǒng)是居于核心地位的。你這么說，有什么道理嗎？
劉振飛：前面說過，微軟所有產(chǎn)品的研發(fā)都遵循同樣的研發(fā)模式、使用同樣的研發(fā)工具來進(jìn)行管理。在所有的工具中，我最佩服的就是其Bug管理系統(tǒng)Raid（現(xiàn)在叫Product Studio）?？梢哉f，遍布全球的微軟研發(fā)人員能夠保持統(tǒng)一的思維模式、做事及語言習(xí)慣，與整個研發(fā)流程的配套工具密不可分，其中最重要的就是通過Raid把整個產(chǎn)品的研發(fā)有機的聯(lián)系起來。閱讀每個 Bug，你可以詳細(xì)的看到大家討論解決該問題的完整思路。
我曾讀過微軟Project 2002產(chǎn)品的Architect寫的一個備忘錄，其中提到： 如果Raid是別家的產(chǎn)品，需要微軟每年付出一筆巨大的費用，Bill Gates會支付這筆錢嗎？“He wouldn’t be happy, but you bet he would. Microsoft depends on Raid to get the job done.”當(dāng)時我“心有戚戚焉”，立即給這哥兒們發(fā)Email表示贊同之意J 他回信說希望Project能夠做的像Raid一樣成功，但可惜他要離開微軟自己開公司了。
在微軟上班，我每天第一件事是打開 Outlook來處理有關(guān)自己的重要郵件，第二件事就是打開Raid來看看有關(guān)自己的Bug情況，趕快處理。我一直納悶，微軟為什么不把這個Bug管理系統(tǒng)作為軟件來出售，那可是任何一家軟件企業(yè)都需要的??！
表面上看Raid其實是一個簡單的工具，那么它的重要性體現(xiàn)在什么地方呢？
l Raid從一開始就支持多用戶
l 一個團隊中的所有人都可以創(chuàng)建、指派Bug，或者改變Bug狀態(tài)
l 用戶可以非常自由的去定制Raid
l 基于SQL，很多有用的報告可以被生成出來
l 管理層需要所有Bug都在Raid中被有效的跟蹤處理
Raid的價值在于它密切跟蹤當(dāng)前產(chǎn)品的實際Bug狀態(tài)，使項目組中的成員非常有效的協(xié)調(diào)他們的工作。大家都很聰明，如果一個工具是容易理解的、而且管理層提供其使用指南（比如Bug怎么被指派和解決），那么簡單的工具也能提供巨大的價值。
孟巖：能否請你簡要地介紹一下微軟的bug管理體制？
劉振飛：在整個產(chǎn)品的研發(fā)過程中，特別是在測試產(chǎn)品、修復(fù)Bug的中后期，團隊中所有人都生活在Raid中：
- 測試人員（Tester）只要發(fā)現(xiàn)問題就立即新建一個Bug予以跟蹤并指派給相關(guān)的開發(fā)小組長（Dev Lead）
- 開發(fā)小組長會判斷這個Bug屬于某個特定的開發(fā)人員（Dev）并指派給他處理
- 開發(fā)人員會根據(jù)Bug的詳細(xì)描述信息找到問題所在，修改程序解決這個Bug并把Bug返回給當(dāng)初的測試人員；或者有爭議的時候，把Bug指派給這個Feature的定義者PM，要求一個澄清說明
- 測試人員在看到某個Bug被解決后，就去驗證這個Bug是否真的不存在了，根據(jù)最初的發(fā)現(xiàn)步驟去證實問題真的解決了就關(guān)閉這個Bug；若還能重現(xiàn)，或者不同意開發(fā)人員的解法，可以激活這個Bug，返還給當(dāng)初的開發(fā)人員做進(jìn)一步調(diào)查處理
- 當(dāng)測試人員和開發(fā)人員無法達(dá)成一致意見的時候，由對應(yīng)的PM出面做協(xié)調(diào)，判斷這個Bug的嚴(yán)重程度、對用戶可能的影響，根據(jù)產(chǎn)品的進(jìn)度和項目資源做出評估，是否真的需要修理掉這個問題
- 管理團隊利用Raid來跟蹤整個進(jìn)度：單個人的工作、小組的進(jìn)度，整個產(chǎn)品研發(fā)進(jìn)度
研發(fā)隊伍中的所有人都通過Raid來商議、溝通某個Bug是否符合當(dāng)前解決Bug的“門檻”，決定是否需要真正修理掉這個Bug、如何修理、可能的副作用、如何測試其解決方案等等。每個人可以在Raid中看到某個Bug的全部歷史檔案，比如幾年前發(fā)現(xiàn)的一個Bug一直推遲到這一版才解決，前幾年大家是如何討論的，可能的處理思路是什么，都被完整地記錄下來了。
每月、每周甚至每天，參與這個產(chǎn)品研發(fā)的人都收到一封當(dāng)前Bug狀態(tài)的Email：每個人都上有多少Bug，Dev、PM、Tester頭上Bug數(shù)最多的前5名都是誰，哪個子產(chǎn)品、子模塊中的問題還是處于上升階段，整個Bug的趨勢怎么樣等等。這是最詳盡的產(chǎn)品狀況“內(nèi)參”，暴露在團隊中每個成員的面前，一覽無遺。只要你的名字被列在Email中，你就非常緊張，因為你腦袋上的Bug比較多、影響整個產(chǎn)品的質(zhì)量。這些該死的Bug等待著你去快速處理，盡快把自己從排行榜上去掉。每解掉一個Bug，或者把Bug轉(zhuǎn)給另外的人去處理，就會舒一口氣，因為頭上又少了一個；某一天你頭上的Bug數(shù)降為0了，心里就會非常高興J
我覺得微軟的Bug處理過程，非常類似于“擊鼓傳花”的游戲。鼓點響起，你的任務(wù)就是盡快把自己手中的“花”（Bug）傳給下一個人，不要讓它在自己手里耽誤很長時間。從表面上看，在微軟工作從不打卡、上班時間也很自由、上午很晚到辦公室也沒人管你，但是有Email跟著、有Bug催著，你永遠(yuǎn)不可能偷懶。沒有人盯著你，只是事情如影隨形，而且所有和你相關(guān)的事情都是公開的，相關(guān)的人都知道，就像處于非常開放的輿論監(jiān)督之中，除了把事情辦漂亮你還能有別的選擇嗎？
最后要強調(diào)兩點：
（1） 上Bug不僅僅是測試人員的事情，團隊中的每個人發(fā)現(xiàn)問題時都上個Bug來跟蹤；
（2） Raid中不僅僅是跟蹤軟件功能方面的Bug，其他各種問題如需求文檔（Spec）的改動、界面上的錯別字、幫助文檔的遣詞造句問題、某項任務(wù)指派等等都可以通過一個Bug來跟蹤。
我至今對剛進(jìn)微軟時老板的一句話印象深刻：Everything should be tracked in Raid！
孟巖：就你了解到的情況，國內(nèi)的公司在這方面怎么樣？
劉振飛：在微軟這幾年，我也一直和國內(nèi)軟件公司的朋友們保持接觸。很遺憾的是，國內(nèi)的一些軟件企業(yè)，特別是不少中小企業(yè)，其軟件研發(fā)還是處于作坊式的狀態(tài)，只不過作坊規(guī)模有大中小之分罷了。有意思的是，走在國內(nèi)IT最前沿做各類網(wǎng)站的企業(yè)，根據(jù)我的了解，也在走軟件企業(yè)最初幾個“大蝦”（牛人）搞定一切的階段。我不是說個人技術(shù)好不重要，而是需要更進(jìn)一步，把研發(fā)管理真正搞起來，做出規(guī)模效應(yīng)，從而有效的保證質(zhì)量、控制進(jìn)度、把對某個人的依賴盡量降低，并使產(chǎn)品可持續(xù)發(fā)展。
你知道國內(nèi)不少軟件企業(yè)在做ISO9001或CMM認(rèn)證，花費不菲。少數(shù)企業(yè)純粹是為了認(rèn)證而認(rèn)證，對付著拿到證書就達(dá)到目的了；更多的企業(yè)確實是想利用這個認(rèn)證的過程，把自己的研發(fā)流程規(guī)范化。但似乎能從這些認(rèn)證中享受到真正的研發(fā)管理提升的并不是很多，甚至開發(fā)人員現(xiàn)在需要花費大量的時間去書寫一些例行公事的、沒有任何實際價值的格式化文檔，苦不堪言。
我覺得軟件研發(fā)管理必須結(jié)合自己企業(yè)的實際情況，不要生搬硬套書本上的理論，只要人員分工、配置合理，能夠控制質(zhì)量，什么方法都可以采用。黑貓白貓，能抓耗子的就是好貓。千萬不要走形式、走過場。
孟巖：其實國內(nèi)公司在研發(fā)方面與微軟的差距非常大，也存在于很多方面。為什么你獨獨看中bug管理？為什么你認(rèn)為中國中小型企業(yè)的軟件開發(fā)管理規(guī)范化，應(yīng)當(dāng)從bug管理入手呢？
劉振飛：從微軟的研發(fā)管理來看主要是需求、開發(fā)、測試這三大塊，毫無疑問國內(nèi)公司在開發(fā)這個環(huán)節(jié)一直都很重視，不過需求和測試較弱一點。大家現(xiàn)在都已經(jīng)認(rèn)識到充分理解業(yè)務(wù)需求的重要性，如果沒有很好的對項目或產(chǎn)品用戶需求的真正把握，后面所有的工作都將是白費工夫、事倍功半，這一塊缺乏的是如何有效地將用戶的需求轉(zhuǎn)成一份份詳細(xì)的、后面開放測試人員可以理解的文檔。
但是測試這一塊大家還是不夠重視，對測試人員的素質(zhì)要求也不是很高、人員比例也較低，測試人員往往依附于開發(fā)人員的直接管理，人微言輕。而在微軟，測試人員和開發(fā)人員的比例很多時候是1比1的，有時候會更高。測試人員和開發(fā)、需求人員一樣有自己單獨的行政管理路線，比如我就注意到有非常資深的測試人員可以做VP，專門管理某個產(chǎn)品的測試工作。這在國內(nèi)企業(yè)來說，幾乎就是不可能的。
通過前面的介紹，無論人員的配置和工具的提供，你可以看出微軟是非常重視測試的。所以我覺得如果我們學(xué)習(xí)微軟先進(jìn)的研發(fā)理念，可以從測試入手，打造必要的測試管理系統(tǒng)，通過這樣的系統(tǒng)，把需求、開發(fā)、測試三個環(huán)節(jié)融合在一起，讓團隊中所有的人都遵循同樣的研發(fā)思路：需求人員真正理解用戶的業(yè)務(wù)需要，認(rèn)真研究后形成需求文檔作為產(chǎn)品一個個功能的“合同”；開發(fā)人員寫出設(shè)計文檔，然后動手寫代碼；測試人員理解需求文檔，然后測試做出來的功能是否符合最初的設(shè)想。整個過程碰到的任何問題都要通過Bug系統(tǒng)來記錄、跟蹤，相關(guān)人員通過Bug管理來商談、溝通相應(yīng)的解決方案。
這樣通過Bug管理，逐步統(tǒng)一研發(fā)人員的思維、做事模式，讓整個團隊可以有效地運轉(zhuǎn)起來，并不斷優(yōu)化自己項目的軟件研發(fā)流程，提高產(chǎn)品質(zhì)量，從而使產(chǎn)品可持續(xù)發(fā)展。
孟巖：看來你對于bug管理可真是重視。聽說你在離開微軟后，開發(fā)了一個開源項目BugFree，號稱是要全面模擬微軟的bug管理機制。能介紹一下大致的情況嗎？
劉振飛：今年四月我加盟朋友的公司開始做網(wǎng)站，發(fā)覺自己已經(jīng)習(xí)慣了微軟的研發(fā)模式，于是建議這幾個朋友先做一個 “數(shù)字神經(jīng)系統(tǒng)”，其目的是讓一切可以數(shù)字化、文檔化的信息被記錄下來，為公司的進(jìn)一步發(fā)展和決策提供基礎(chǔ)信息支持。
BugFree 就是其中有關(guān)軟件研發(fā)的Bug管理系統(tǒng)部分。我太了解Bug管理對軟件研發(fā)的重要性、也對微軟的Bug系統(tǒng)有了深入掌握，所以需要有一個類似微軟的Bug系統(tǒng)才好開展工作。雖然網(wǎng)上有免費的Bug管理系統(tǒng)（如Mantis、Bugzilla），但是我看后覺得都不好使，和我在微軟用的差別太大，上?？铺┦兰o(jì)公司的 Bug管理系統(tǒng)倒也很像微軟的，但是要花錢買。琢磨著反正我也這一塊非常熟悉了，何不做一個出來自己用？于是決定借鑒微軟的研發(fā)流程和Bug管理工具自己開發(fā)一個，以便對我們開發(fā)新網(wǎng)站、聲訊軟件、客戶端軟件和公司事務(wù)管理中出現(xiàn)的問題進(jìn)行有效的跟蹤處理。
“數(shù)字神經(jīng)系統(tǒng)”中的BugFree是用開放源代碼的PHP+MySQL寫成、基于瀏覽器方式運行的。我以前沒有任何Linux+Apache+MySQL+PHP的開發(fā)經(jīng)驗，但我很幸運的招聘到幾名優(yōu)秀的Web程序員，可以在短短的兩個月時間內(nèi)搭建起這樣的系統(tǒng)。其中BugFree是由我的同事王春生開發(fā)的，他用了不到一個月的時間就把代碼寫完，讓我很是驚訝，從而認(rèn)識到基于Linux的Web開發(fā)魅力。之后我們測試一個多月，就可以在實際工作中使用并不斷完善?，F(xiàn)在BugFree已經(jīng)成了我們?nèi)粘９ぷ髯钪匾墓ぞ?，每個員工也都習(xí)慣用Bug來記錄跟蹤事情，不僅僅是代碼中的缺陷可以上Bug，新的需求、設(shè)計變化等都可以用這個Bug管理系統(tǒng)有效的管理起來。其實Bug 不僅僅可以用來記錄軟件中的缺陷，也可以用來跟蹤公司的日常事務(wù)。比如在公司的網(wǎng)上報銷系統(tǒng)還沒有建立之前，我們就用 BugFree來處理報銷的事情。甚至，一個同事給我上了這樣的Bug：你的桌面太亂了，請整理一下J
命名BugFree 有兩層意思：一是希望軟件中的缺陷越來越少直到?jīng)]有，Free嘛；二是表示它是免費且開放源代碼的，大家可以自由使用傳播。也算為中國的軟件業(yè)做點小小的貢獻(xiàn)，特別的，希望能對國內(nèi)中小企業(yè)的研發(fā)流程改進(jìn)、Bug的有效管理提供參考和幫助。
和微軟內(nèi)部的Raid比較起來，BugFree有如下特點：
（1）Raid是Windows客戶端軟件，BugFree是基于瀏覽器的。基于此，Raid 有很強大的編輯展示功能，而BugFree簡單、方便、易用；
（2）Raid可以進(jìn)行極其復(fù)雜的組合查詢，BugFree的查詢功能相對弱一些，但我覺得對中小企業(yè)已經(jīng)夠用了；
（3）一個Bug從創(chuàng)建到關(guān)閉這個“生命周期”的處理過程，BugFree 全面借鑒Raid的處理流程，處理方法甚至一些詞匯都和Raid一樣 (所以我現(xiàn)在用BugFree處理Bug的感覺和在微軟時候基本一樣)；
（4）BugFree 還有一個獨創(chuàng)的功能：當(dāng)一個Bug被指派給你的時候，系統(tǒng)會自動給你發(fā)一封郵件，告訴你有個Bug需要你處理，這樣結(jié)合 Email，BugFree被完美使用起來，成為我們現(xiàn)在網(wǎng)站開發(fā)、運行、維護必備的工具。我們還增加了兩個Bug統(tǒng)計功能：一是每天早上8點鐘每個同事都會收到一封Email，告訴他/她頭上還有多少 Bug等待處理；二是每周一中午給所有人發(fā)一封郵件，告知上周Bug的處理情況和到目前為止所有Bug的統(tǒng)計數(shù)據(jù)；
（5）BugFree程序規(guī)模很小，一個中等水平的PHP程序員就可以在1~2周內(nèi)看懂所有的代碼，然后就可以根據(jù)自己的需要做相應(yīng)的定制了；
（6）最最重要是，BugFree 是免費并且開發(fā)源代碼的。你可以體驗到微軟的Bug管理精髓，按自己需要自由地增加功能、修改代碼而不用擔(dān)心版權(quán)問題J
不過坦率的講，BugFree 僅僅是個工具而已，重要的是掌握其中蘊含的軟件研發(fā)的流程思想，才能用好這個工具。如果你以前沒有用過 Bug管理系統(tǒng)，那么一開始的時候也許你會覺得這個工具是在浪費時間，因為一個測試人員需要費神把發(fā)現(xiàn) Bug的詳細(xì)步驟記錄下來，有時還要貼一張示意圖，這一切都不如當(dāng)面說來得直接。
但是使用一段時間，你會發(fā)現(xiàn) BugFree很有用，它忠實的記錄著每個問題的處理過程，不斷提醒你存在的問題，永遠(yuǎn)不會丟失和忘記。如果你參與過較大軟件項目或產(chǎn)品的研發(fā)，就會理解它對軟件可持續(xù)發(fā)展是至關(guān)重要的。而且研發(fā)的規(guī)模越大，BugFree 的作用就會越大。
感興趣的朋友，可以到http://www.okooo.com/OpenSource 來體驗、下載最新版的BugFree。
