7. BUG管理

　　由于我們每天進(jìn)行著測(cè)試，因此經(jīng)常有BUG被測(cè)試部門(mén)發(fā)現(xiàn)，一旦發(fā)現(xiàn)了新的BUG，就會(huì)被添加進(jìn)BUG Tracking System中。目前較流行的BUG Tracking System有TestTrack、ClearQuest、Bugzilla等。BUG tracking system是開(kāi)發(fā)人員和QA之間的紐帶，開(kāi)發(fā)人員和QA通過(guò)BUG tracking system聯(lián)系著。每個(gè)BUG有其類型和級(jí)別，預(yù)定的類型有Crash-Data Loss, Crash-No Data Loss, Incorrect functionality, Cosmetic, Feature request等, 級(jí)別有P1、P2一直到P6，它們分別代表了重要性及緊急程度，P1的BUG需要很快fix，P5之前的BUG在本版本release之前必須fix掉，若真的不能或不重要?jiǎng)t由QA確定并降低優(yōu)先級(jí)進(jìn)入到下一個(gè)版本中去fix。QA發(fā)現(xiàn)一個(gè)BUG后在BUG Track中增加一個(gè)BUG，同時(shí)填入相關(guān)信息并assign給相應(yīng)的開(kāi)發(fā)人員，開(kāi)發(fā)人員收到BUG分析并fix后assign給QA去verify，其中要填上分析的結(jié)果以及如何解決的詳細(xì)說(shuō)明。若QA對(duì)此BUG verify通過(guò)則close BUG，否則verify failed并重新assign給開(kāi)發(fā)人員并等待其fix。每星期在Status Meeting上會(huì)進(jìn)行BUG狀況報(bào)告，主要由QA組長(zhǎng)報(bào)告BUG的狀況，主要是新增BUG數(shù)，fix掉多少，還有多少處于open狀態(tài)，有多少處于等待verify的狀態(tài)，據(jù)此可以了解開(kāi)發(fā)及測(cè)試情況。有時(shí)在Status Meeting上我們也會(huì)進(jìn)行BUG Review，BUG Review有時(shí)是單獨(dú)一個(gè)小組內(nèi)進(jìn)行，其主要作用是重新明確每個(gè)人頭上的BUG以及了解每個(gè)BUG的狀況，如開(kāi)發(fā)人員對(duì)此BUG將作何處理等，以此來(lái)了解開(kāi)發(fā)中是否有碰到比較棘手的問(wèn)題，增加了產(chǎn)品發(fā)布風(fēng)險(xiǎn)。在QA增加BUG和開(kāi)發(fā)人員fix BUG的游戲中，BUG的數(shù)量曲線圖會(huì)象股市曲線一樣上下波動(dòng)，但總體趨勢(shì)一般是前期BUG放量攀升，后期震蕩下挫，若到了后期新open的BUG數(shù)量一直上升則說(shuō)明風(fēng)險(xiǎn)在增大，有可能無(wú)法控制，也就是說(shuō)fix了一個(gè)BUG導(dǎo)致了多個(gè)新的BUG產(chǎn)生。在量化開(kāi)發(fā)進(jìn)度中也可以用代碼數(shù)量的曲線圖來(lái)粗略的呈現(xiàn)。在有大量新功能增加時(shí)可能代碼量的增加會(huì)較快，當(dāng)在fix bug階段，代碼的修改較多，因此代碼數(shù)量的增幅會(huì)降低，依據(jù)代碼量可以看出開(kāi)發(fā)的狀況處于何種階段。

　　需要指出的是我們對(duì)BUG的定義比較廣泛，一些新功能也可以作為BUG被提出，只不過(guò)這些BUG級(jí)別比較低，讓它們進(jìn)入到下一個(gè)版本中去實(shí)現(xiàn)。因此BUG的創(chuàng)建者也可以是技術(shù)支持人員、市場(chǎng)人員甚至開(kāi)發(fā)人員本身。關(guān)于開(kāi)發(fā)人員本身，因?yàn)樗赡軙?huì)找出一些BUG，有些是其他開(kāi)發(fā)者的，有些可能是此開(kāi)發(fā)者本身的，把這個(gè)BUG添加進(jìn)BUG庫(kù)中可以幫助開(kāi)發(fā)人員在以后產(chǎn)生新問(wèn)題時(shí)或類似的BUG時(shí)有一個(gè)借鑒和思路，但此BUG的verify必須要讓測(cè)試本模塊的測(cè)試人員來(lái)verify。

　　8. Code Freeze

　　當(dāng)P5之前的BUG都被修復(fù)了，這時(shí)離產(chǎn)品發(fā)布日期也就不遠(yuǎn)了，一般是2個(gè)星期后就能release產(chǎn)品，這時(shí)要對(duì)VSS中的代碼進(jìn)行freeze，以保證代碼庫(kù)的穩(wěn)定性。Code freeze階段一般會(huì)把各開(kāi)發(fā)人員的check in和check out的權(quán)限關(guān)閉，若在這時(shí)仍有BUG報(bào)告上來(lái)并經(jīng)討論確定是重大的且必須在本版本中fix的，則需要經(jīng)管理層同意并特殊地授予權(quán)限，在修改完成后修改者要把修改了哪些文件，影響了哪些文檔等信息上報(bào)給各部門(mén)如QA、build人員、文檔編寫(xiě)者等。在code freeze階段，測(cè)試部門(mén)在緊張地進(jìn)行著各種測(cè)試，得出各種數(shù)據(jù)，并決定本版本是否可以release了。

　　9. Tech Talk

　　計(jì)算機(jī)知識(shí)更新速度非?？?，經(jīng)常有一些新的術(shù)語(yǔ)、新的名詞、新的思想、新的技術(shù)所產(chǎn)生，如過(guò)離開(kāi)此行業(yè)幾個(gè)月后重新回來(lái)就會(huì)對(duì)這些新的事物不解，而我們平時(shí)為了自己的項(xiàng)目埋頭苦干可能忘了周圍的世界發(fā)生了什么。Tech Talk就提供了一個(gè)讓我們了解新知識(shí)和最新發(fā)展趨勢(shì)的機(jī)會(huì)，讓大家把知識(shí)共享，共同提高。Tech Talk一般會(huì)在項(xiàng)目不是太忙碌的時(shí)候進(jìn)行，主持人會(huì)提前一個(gè)星期指定某個(gè)人去準(zhǔn)備一下Tech Talk，一般此人可能對(duì)某方面比較感興趣，然后他會(huì)花一些時(shí)間去了解這方面的情況，寫(xiě)成一個(gè)文檔如PowerPoint并上傳到局域網(wǎng)內(nèi)，同時(shí)通知大家可以先去瀏覽。Tech Talk的內(nèi)容非常廣泛，不一定同我們的項(xiàng)目緊密相關(guān)，任何新的思想、新的知識(shí)(當(dāng)然一般是限在計(jì)算機(jī)領(lǐng)域內(nèi))都可作為T(mén)ech Talk的內(nèi)容，而在主講人講完之后還有一段時(shí)間被大家提問(wèn)，共同對(duì)這個(gè)話題進(jìn)行討論，答疑解惑。當(dāng)然Tech Talk也可同我們的項(xiàng)目相關(guān)，如研究一下競(jìng)爭(zhēng)對(duì)手的產(chǎn)品技術(shù)，本公司產(chǎn)品的架構(gòu)等。研究本公司的產(chǎn)品架構(gòu)可以使大家對(duì)本公司的產(chǎn)品有一個(gè)全局的概念，從整體上來(lái)看自己的產(chǎn)品，順便整理一下產(chǎn)品的架構(gòu)使之更加清晰有條理。平時(shí)大家都只注重于自己負(fù)責(zé)的其中的一小塊，在Tech Talk中可以跳出自己的小框框來(lái)了解全局，同時(shí)這也是新員工了解公司核心技術(shù)整體框架的好機(jī)會(huì)。每個(gè)模塊的負(fù)責(zé)人需要闡述此模塊的方方面面，讓大家來(lái)了解并回答問(wèn)題。

　　10. Code Review

　　當(dāng)進(jìn)行工作移交時(shí)我們會(huì)進(jìn)行Code Review，在碰到棘手的BUG時(shí)也會(huì)進(jìn)行Code Review，Code Review是大家了解其詳細(xì)實(shí)現(xiàn)的一個(gè)好機(jī)會(huì)。在Code Review之后會(huì)對(duì)此代碼產(chǎn)生親切感而不是陌生懼怕感，相信很多人在讀他人代碼時(shí)會(huì)有非常痛苦的經(jīng)歷，Code Review是減少此痛苦感的好藥方。在進(jìn)行Code Review前，主講人會(huì)提前發(fā)出一個(gè)通知告訴相關(guān)人員要review哪些代碼，這樣參與者可以抽出時(shí)間提前了解相關(guān)代碼，對(duì)不懂的地方做個(gè)筆記以便在Code Review進(jìn)行中提出疑問(wèn)。在我們碰到比較棘手的BUG沒(méi)有什么思路或大惑不解時(shí)，這時(shí)找?guī)讉€(gè)相關(guān)人員或?qū)Υ舜a也熟悉的人進(jìn)行一次Code Review，這時(shí)形式比較隨意，大家可以臨時(shí)提出問(wèn)題，讓主講人解答，在這個(gè)過(guò)程中可能聽(tīng)的人并不會(huì)非?？斓亓私馄渲械脑敿?xì)過(guò)程，但是講的人在這個(gè)過(guò)程中重新理了一下思路，對(duì)所寫(xiě)的代碼被迫重新審視了一遍，在其中可能就會(huì)發(fā)現(xiàn)出解決問(wèn)題的辦法。在Code Review時(shí)有時(shí)代碼非常多，但可以一個(gè)功能模塊一個(gè)功能模塊地從總體到局部，由淺入深層層遞進(jìn)的方式進(jìn)行。一次Code Review的時(shí)間不要太長(zhǎng)，但可以分多次進(jìn)行。Code Review中大家會(huì)提出問(wèn)題和建議，集思廣益，多個(gè)人共同出主意，有些可能一個(gè)人沒(méi)有想到的問(wèn)題會(huì)被大家發(fā)現(xiàn)，互相學(xué)習(xí)，共同進(jìn)步。

　　11. 溝通與交流

　　大部分員工的大部分時(shí)間是在公司里度過(guò)的，因此公司的生活成了大家主要組成部分。員工之間關(guān)系的融洽，交流的暢通顯得非常重要，同時(shí)大家也不想自己的生活這樣枯燥乏味，一直同機(jī)器打交道。溝通無(wú)處不在，交流隨時(shí)發(fā)生，有許多關(guān)系是在工作之外建立起來(lái)的。軟件公司內(nèi)是很容易產(chǎn)生各種矛盾的，因?yàn)檫@是由你的工作性質(zhì)所決定的，比如QA或用戶會(huì)對(duì)你的實(shí)現(xiàn)不滿意，提出各種要求時(shí)，我相信你有時(shí)會(huì)有所抱怨的，無(wú)形之中就產(chǎn)生了對(duì)立，發(fā)展到后來(lái)會(huì)有抵觸心理。我相信大部分人都會(huì)有此感受，這不是你的錯(cuò)，這主要是由我們的工作性質(zhì)決定的。如果你的工作是把財(cái)富帶給對(duì)方，則對(duì)方會(huì)非常歡迎你的到來(lái)，把你奉為財(cái)神爺來(lái)對(duì)待，同你的關(guān)系會(huì)非常融洽友好。因此我們需要在工作之外來(lái)消除這種對(duì)立矛盾的關(guān)系，建立一種融洽的工作氛圍。我們?cè)谄綍r(shí)吃飯的時(shí)候飯桌上大家互相聊天溝通。我們建立了happy郵件列表，其中會(huì)發(fā)一些幽默笑話之類的郵件，給我們緊張的工作增加點(diǎn)輕松的氛圍。在下班后大家可以組織一下活動(dòng)，增加了公司的凝聚力。一個(gè)產(chǎn)品發(fā)布后組織一下旅游，讓繃緊的神經(jīng)松弛一下，更好地迎接下一個(gè)挑戰(zhàn)。

　　12. 后記

　　不同公司有不同的做法，我只是把我認(rèn)為比較好的流程與管理方式呈現(xiàn)出來(lái)，讓大家有個(gè)借鑒，當(dāng)然它也不是十全十美的，也不是放之四海而皆準(zhǔn)的，如果你覺(jué)得某些地方對(duì)你有所幫助或值得推廣，這是本文最想達(dá)到的效果。非常感謝I公司給了我這么美好的經(jīng)歷，也非常感謝I公司的同事們?cè)o我的巨大幫助，在此衷心地祝福I公司越來(lái)越壯大，逐步走向成功!也衷心地祝福我的同事們幸?？鞓?lè)!