轉自：http://blog.csdn.net/marising/archive/2008/11/18/3327528.aspx
最近公司採用Jira來做特徵管理，項目管理，缺陷管理的工具。因此，自己摸索了一下jira的設置。先看看Project的屬性頁面：
Key: xxx
URL: No URL
Project Team:
Project Lead: 李海波
Default Assignee: Project Lead
Project Roles:
Issue Type Scheme: Default Issue Type Scheme
Notification Scheme: xxx Notification Scheme
Permission Scheme: xxx Permission Scheme
Issue Security Scheme: xxx Security
Field Configuration Scheme: xxx Configuration Scheme
Issue Type Screen Scheme: xxx Project Issue Type Screen Scheme
Workflow Scheme: xxx Workflow
CVS Modules: None
Mail Configuration: Mail notifications from this project will come from the default address
Project Category: None
需要設置的有：
Issue Type Scheme
Notification Scheme
Permission Scheme
Issue Security Scheme
Field Configuration Scheme
Issue Type Screen Scheme
Workflow Scheme
其中後面三項是最麻煩的。
1.Issue Type 類型
默認分爲Feature（特徵），Improvement（改進），Bug（缺陷），Task（任務），涵蓋項目管理的幾個方面，但是我認爲Improvement可有可無，可以由其他幾個來代替。特徵，是指新增加的需求，一般需要經過調研和評審階段。Task一般指設計和編碼的任務。Bug是測試過程中發現的缺陷。
2.Priority 優先級
Blocker，指導致測試或者開發無法進行的問題。比如數據庫訪問的公共庫，或者通信組件出問題，或者登錄組件有問題等等。
Critical，指主要模塊崩潰，內存泄漏，數據丟失等嚴重問題。
Major，主要功能有問題
Minor，次要功能有問題
Trivial，細微的問題，比如界面易用性，美觀等無關緊要的缺陷
一般項目分爲5級也就足夠，好像優先級是針對Bug的，但是Feature也是要用到的，Feature的優先高，就要儘快實現。
3.Statuses 狀態
workflow主要分爲Status和Transition。這裏定義的Statues是全局的都能用的，因此，缺少什麼狀態就要在這裏定義。我增加一個 Disputed（有爭議）的狀態，在Bug流程中，開發人員如果發現缺陷不是缺陷，是重複的，不能再現等，可以提交缺陷未Disputed狀態，由項目經理去決定。
4.Resolution 解決方案
Fix 修復
Wont Fix 不想修復，一般需要選這個吧。
Duplicate，重複的缺陷
Incomplete，未描述清楚
Cannot Reproduce，出現過一次，後來無法再現
Invalid，未驗證的，是個假缺陷
Later，以後的版本修復
5.Custom Fields 定製字段
默認有一些字段，但是好像不大夠，可以增加BugCategory和BugSource以及FeatureCategoy和FeatureSource字段，指明Bug的類別（系統，程序邏輯，數據格式，界面等bug）以及Bug來源（內部測試，集成測試，用戶反饋等）。
1.IssueType，Issue的類型
2.Summary，概要說明
3.Affects Version，影響版本
4.Component，Project下面的組件
5.BugCategory，缺陷類型（自定義字段）
6.BugSource，缺陷來源（自定義字段）
7.Priority，優先級
8.Assignee，開發者
9.Reporter，彙報人
10.Time Tracking，時間估計
11.Due Date，逾期日期
12.Fix Version，修復版本
13.Resolution，解決方案
14.Description，描述
15.Attachment，附件
6.Field Configuration
定義字段是否顯示，是否必須的屬性。在不同的IssueType中，字段的屬性是不一樣的。
7.Field Configuration Scheme
建立IssueType和Field Configuration的關聯，最好每個Type建立一份Field Configuration
8.Screens 視圖
Sceen的種類很多，大概分爲兩類。一類是Issue的創建，編輯，查看視圖;另一類是workflow的視圖，在流程進行過程中，需要填寫一些值，因此需要設計screen。需要注意的是Fix Version字段，只能在後續流程中填寫，在創建時無法填寫，就是說即便你在Screen中加入了，創建issue你也看不見。
9.Sceen Scheme
根據IssueType分別建立Scheme，比如Bug，就有Create Issue，Edit Issue，View Issue三類，分別對應一個Screen就足夠了。
10.Issue Type Screen Scheme
就是新建IssueType和Screen Scheme的對應關係，比如建立一個xxx project issue type screen scheme，然後bug對應9中的bug screen scheme。
11.Workflows 工作流程
下面的列表展示了一個流程的運行狀態和步驟。
Bug一般流程是
Open->Start Progress->In Progress -> Resolve Bug -> Resolved -> Close Bug -> Closed
Bug其他流程是
Open -> Dispute Bug -> Disputed -> Terminate -> Terminated
黑體字是狀態，其他的是動作
| Step Name (id) | Linked Status | Transitions (id) | |
| Open (1) | Open | Start Progress (11) >> In Progress Dispute Bug (31) >> Disputed |
|
| In Progress (2) | In Progress | Stop Progress (41) >> Open Resolve Bug (51) >> Resolved Dispute Bug (81) >> Disputed |
|
| Reopened (3) | Reopened | Start Progress (61) >> In Progress Dispute Bug (71) >> Disputed |
|
| Resolved (4) | Resolved | Close Bug (91) >> Closed Reopen Bug (121) >> Reopened |
|
| Closed (5) | Closed | Reopen Bug (111) >> Reopened |
|
| Disputed (6) | Disputed | Reopen Bug (131) >> Reopened Terminate Bug (141) >> Terminated |
|
| Terminated (7) | Terminated | Reopen Bug (151) >> Reopened |
看一個Transition的例子
Conditions：可以選擇誰有權限來處理
Post Functions：遷移之後的操作，狀態/字段的修改等。
Transition View:遷移之時的視圖，可以讓操作者填寫一些字段。參考8
12.Workflow Schemes
Issue Type和workflow的對應關係。
13.Permission Schemes權限設置
權限設置的地方有User Browser,Group Browser,Project Role Brower，後面兩個代表不同的用戶分組。
在Permission Scheme中，可以設置很多項的權限，這些權限就會反饋在使用過程中。Assignable User的權限，會決定創建Issue指定Assignee的權限。
14.Notification Schemes通知設置
自己看着設置吧，最好是別太頻繁樂，否則很煩人。
