天天看點

一些項目管理工具

JIRA

  一個非常出色的Issue跟蹤系統,這裡的Issue不單單是指BUG, 很多時候也可以是TASK, IMPROVEMENT, NEW FEATURE, 甚至是一個QUESTION。

  在多年前, 我曾經嘗試使用過那個經典的的Bugzilla,但是一個項目作下來,大家都反映那個東西的界面實在是太粗糙,簡直無法忍受而且報表功能也是在太弱。最後大家就讨論自己作一個BUG的跟蹤系統,就在大家已經完成了設計文檔準備編碼的時候, 我們發現JIRA原來就是我們要找的東西,而且比我們要的更多。它内置一個可以配置的工作流引擎(osworkflow),一個快捷的全文檢索功能(基予Apache Lucene).和一個可以配置的Dashboard(portlet),以及一個和CVS連接配接的引擎,通過這個連接配接,在一個Issue中直接可以看到修改的檔案名稱,如果配置了viewcvs的話,還直接直接定位到行,根據一個問題可以跟蹤到代碼的行,這正式我們夢寐一求的功能。 也正是這種特性,才使我們能夠把一個個Issue當作釋出和版本管理的一個單元。

CVS

  這個應該大家都知道。在系統開發過程中,一切的源代碼和設計文檔都應該進入版本管理系統來進行管理, 有的時候可能資源庫可能會膨脹的很大, 但這個代價是值得的。

XPlanner

  在整個管理體系中,進度管理一直是一個?比較薄弱的環節,我也曾試過dotproject這樣的管理軟體,但由于dotproject管理的太過詳細,填報起來太複雜,大家漸漸都失去了填報的熱情。這個 XPlanner軟體可就簡單多了。指定了疊代,story,然後就可以填寫進度了。由于這個軟體也是OpenSource的,是以如果覺得不滿意,修改起來也很友善,現在老林就對這個系統作了些改進,可以直接和JIRA系統連接配接起來,JIRA中建立issue後,可以在XPlaner中反映出來,連填寫 story的時間都省去了, 然後在下班之前可以生成一個詳細的報告,列出每個人在這一天内在自己負責的Issue在上的處理時間和進度。

WIKI

  在項目管理中,我們一直把它當作文檔管理和Portlet系統來使用,它現在已經變成我們的小組的工作台,在WIKI中我們制定了包括系統開發設計規範在内的一切設計文檔,以及數十個經常的HOWTO項目,例如如何配額一個标準的開發環境,如何使用CVS用戶端,如何使用JIRA,以及自己的 JavaDoc, JSDoc等。 我們也可以通過Wiki來簡單的整合系統,在Wiki中我們列出了所有開發環境和開發工具的入口,例如上面就放了進入JIRA,XPlanner以及我們各個Project的連接配接,甚至到 Apache中常用的Project的JavaDoc的連接配接,現在再也沒有人去記錄這些URL了,隻要打開Wiki所有的資源都在面前了,并且由于wiki本身的開放性,是以每個團隊的成員都是一個維護者,同時也是這個系統的受益者。在很多的團隊中經常出現的情況是一個小子對某個技術特别在行,大家遇到這方面的問題都問他,在小的團隊中, 面對面的交流通常是最快的交流方式,但是放到大的團隊中,這個就不大可行了,那個小子遲早有一天會被問的煩到吐血為至,特别是他自己的工作也無法按時完工的時候。還是抽一個小時寫出來,放到 wiki裡面吧, 别問我, 自己去查Wiki。

基于ISSUE的釋出管理

  從版本管理的角度來考慮,最理想的釋出方法就是把CVS中的代碼拿下來, 打上一個tag, 編譯并且測試一直到釋出。 這樣的管理方式的确是很簡單的,但事實上使用者可不買帳的, 使用者覺得在新的版本中某個新的功能他還不想要,這可能是他還沒有整理好業務初始資料或者在實際的業務流程上或人員上沒有做好準備, 上帝說了不要咱就不能把這個新功能釋出。在這個情況下,基于Issue的釋出管理是一個好的方案。

  這裡講的Issue就是前面JIRA系統中的一個issue。 通常每個Issue的完成都會伴随這一些代碼的修改。 基于Issue的釋出簡單的來說就是把一組Issue變更的檔案用patch的形式釋出到正式的系統中。

  基于Issue釋出的前提就是要在Issue和Source之間建立連接配接, 使釋出人員清楚的知道每個Issue修改的源代碼是什麼。我們實踐下來最簡單的辦法就是在送出source的時候必須加上JIRA編号, 沒有JIRA編号代碼是不能送出的。 這樣有以下好處:

1)防止一些沒有經驗的程式員無意義的送出, 比如一個小子今天送出了一個java檔案,明天發現這個變量命名有點不爽, 修改後就要送出,在這種情況下, 這個送出是沒有意義的,如果測試組已經測試這個Issue, 是否測試組要重新測試? 為一個變量名稱化這樣的時間和冒險是可嫩的。小夥子還是在第一次送出的時候就把變量名想好了再送出。

2)程式員偷偷的修改代碼,一個小夥子發現自己的已經Closed的Issue中有一個Bug, 便偷偷的修改代碼。 這個當然也是不可能的,凡是送出到CVS中的代碼就不是自己的了,那是大家的, 沒有足夠的理由想改當然沒有那麼容易。 先自己建立建立個Issue, 向Team leader報告, 然後再去修改代碼.。

繼續閱讀