作者：Zhang(daniel_zhy)

JIRA，一個(gè)非常出色的Issue跟蹤系統(tǒng)，這里的Issue不單單是指BUG， 很多時(shí)候也可以是TASK， IMPROVEMENT， NEW FEATURE， 甚至是一個(gè)QUESTION。在多年前， 我曾經(jīng)嘗試使用過(guò)那個(gè)經(jīng)典的的Bugzilla，但是一個(gè)項(xiàng)目作下來(lái)，大家都反映那個(gè)東西的界面實(shí)在是太粗糙，簡(jiǎn)直無(wú)法忍受而且報(bào)表功能也是在太弱。最后大家就討論自己作一個(gè)BUG的跟蹤系統(tǒng)，就在大家已經(jīng)完成了設(shè)計(jì)文檔準(zhǔn)備編碼的時(shí)候， 我們發(fā)現(xiàn)JIRA原來(lái)就是我們要找的東西，而且比我們要的更多。它內(nèi)置一個(gè)可以配置的工作流引擎(osworkflow)，一個(gè)快捷的全文檢索功能(基予Apache Lucene).和一個(gè)可以配置的Dashboard(portlet)，以及一個(gè)和CVS連接的引擎，通過(guò)這個(gè)連接，在一個(gè)Issue中直接可以看到修改的文件名稱(chēng)，如果配置了viewcvs的話，還直接直接定位到行，根據(jù)一個(gè)問(wèn)題可以跟蹤到代碼的行，這正式我們夢(mèng)寐一求的功能。 也正是這種特性，才使我們能夠把一個(gè)個(gè)Issue當(dāng)作發(fā)布和版本管理的一個(gè)單元。

CVS，這個(gè)應(yīng)該大家都知道。在系統(tǒng)開(kāi)發(fā)過(guò)程中，一切的源代碼和設(shè)計(jì)文檔都應(yīng)該進(jìn)入版本管理系統(tǒng)來(lái)進(jìn)行管理， 有的時(shí)候可能資源庫(kù)可能會(huì)膨脹的很大， 但這個(gè)代價(jià)是值得的。

XPlanner, 在整個(gè)管理體系中，進(jìn)度管理一直是一個(gè)?比較薄弱的環(huán)節(jié)，我也曾試過(guò)dotproject這樣的管理軟件，但由于dotproject管理的太過(guò)詳細(xì)，填報(bào)起來(lái)太復(fù)雜，大家漸漸都失去了填報(bào)的熱情。這個(gè) XPlanner軟件可就簡(jiǎn)單多了。指定了迭代，story，然后就可以填寫(xiě)進(jìn)度了。由于這個(gè)軟件也是OpenSource的，所以如果覺(jué)得不滿意，修改起來(lái)也很方便，現(xiàn)在老林就對(duì)這個(gè)系統(tǒng)作了些改進(jìn)，可以直接和JIRA系統(tǒng)連接起來(lái)，JIRA中建立issue后，可以在XPlaner中反映出來(lái)，連填寫(xiě) story的時(shí)間都省去了， 然后在下班之前可以生成一個(gè)詳細(xì)的報(bào)告，列出每個(gè)人在這一天內(nèi)在自己負(fù)責(zé)的Issue在上的處理時(shí)間和進(jìn)度。

WIKI，在項(xiàng)目管理中，我們一直把它當(dāng)作文檔管理和Portlet系統(tǒng)來(lái)使用，它現(xiàn)在已經(jīng)變成我們的小組的工作臺(tái)，在WIKI中我們制定了包括系統(tǒng)開(kāi)發(fā)設(shè)計(jì)規(guī)范在內(nèi)的一切設(shè)計(jì)文檔，以及數(shù)十個(gè)經(jīng)常的HOWTO項(xiàng)目，例如如何配額一個(gè)標(biāo)準(zhǔn)的開(kāi)發(fā)環(huán)境，如何使用CVS客戶端，如何使用JIRA，以及自己的 JavaDoc， JSDoc等。 我們也可以通過(guò)Wiki來(lái)簡(jiǎn)單的整合系統(tǒng)，在Wiki中我們列出了所有開(kāi)發(fā)環(huán)境和開(kāi)發(fā)工具的入口，例如上面就放了進(jìn)入JIRA，XPlanner以及我們各個(gè)Project的連接，甚至到 Apache中常用的Project的JavaDoc的連接，現(xiàn)在再也沒(méi)有人去記錄這些URL了，只要打開(kāi)Wiki所有的資源都在面前了，并且由于wiki本身的開(kāi)放性，所以每個(gè)團(tuán)隊(duì)的成員都是一個(gè)維護(hù)者，同時(shí)也是這個(gè)系統(tǒng)的受益者。在很多的團(tuán)隊(duì)中經(jīng)常出現(xiàn)的情況是一個(gè)小子對(duì)某個(gè)技術(shù)特別在行，大家遇到這方面的問(wèn)題都問(wèn)他，在小的團(tuán)隊(duì)中， 面對(duì)面的交流通常是最快的交流方式，但是放到大的團(tuán)隊(duì)中，這個(gè)就不大可行了，那個(gè)小子遲早有一天會(huì)被問(wèn)的煩到吐血為至，特別是他自己的工作也無(wú)法按時(shí)完工的時(shí)候。還是抽一個(gè)小時(shí)寫(xiě)出來(lái)，放到 wiki里面吧， 別問(wèn)我， 自己去查Wiki。

基于ISSUE的發(fā)布管理。

從版本管理的角度來(lái)考慮，最理想的發(fā)布方法就是把CVS中的代碼拿下來(lái)， 打上一個(gè)tag， 編譯并且測(cè)試一直到發(fā)布。 這樣的管理方式的確是很簡(jiǎn)單的，但事實(shí)上用戶可不買(mǎi)帳的， 用戶覺(jué)得在新的版本中某個(gè)新的功能他還不想要，這可能是他還沒(méi)有整理好業(yè)務(wù)初始數(shù)據(jù)或者在實(shí)際的業(yè)務(wù)流程上或人員上沒(méi)有做好準(zhǔn)備， 上帝說(shuō)了不要咱就不能把這個(gè)新功能發(fā)布。在這個(gè)情況下，基于Issue的發(fā)布管理是一個(gè)好的方案。

這里講的Issue就是前面JIRA系統(tǒng)中的一個(gè)issue。 通常每個(gè)Issue的完成都會(huì)伴隨這一些代碼的修改。 基于Issue的發(fā)布簡(jiǎn)單的來(lái)說(shuō)就是把一組Issue變更的文件用patch的形式發(fā)布到正式的系統(tǒng)中。

基于Issue發(fā)布的前提就是要在Issue和Source之間建立連接， 使發(fā)布人員清楚的知道每個(gè)Issue修改的源代碼是什么。我們實(shí)踐下來(lái)最簡(jiǎn)單的辦法就是在提交source的時(shí)候必須加上JIRA編號(hào)， 沒(méi)有JIRA編號(hào)代碼是不能提交的。 這樣有以下好處。
1）防止一些沒(méi)有經(jīng)驗(yàn)的程序員無(wú)意義的提交， 比如一個(gè)小子今天提交了一個(gè)java文件，明天發(fā)現(xiàn)這個(gè)變量命名有點(diǎn)不爽， 修改后就要提交，在這種情況下， 這個(gè)提交是沒(méi)有意義的，如果測(cè)試組已經(jīng)測(cè)試這個(gè)Issue， 是否測(cè)試組要重新測(cè)試？ 為一個(gè)變量名稱(chēng)化這樣的時(shí)間和冒險(xiǎn)是可嫩的。小伙子還是在第一次提交的時(shí)候就把變量名想好了再提交。

2）程序員偷偷的修改代碼，一個(gè)小伙子發(fā)現(xiàn)自己的已經(jīng)Closed的Issue中有一個(gè)Bug， 便偷偷的修改代碼。 這個(gè)當(dāng)然也是不可能的，凡是提交到CVS中的代碼就不是自己的了，那是大家的， 沒(méi)有足夠的理由想改當(dāng)然沒(méi)有那么容易。 先自己建立建立個(gè)Issue， 向Team leader報(bào)告， 然后再去修改代碼。