jira的基本配置和設定

最近公司採用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通知設定
自己看著設定吧，最好是別太頻繁樂，否則很煩人。

 

JIRA圖形化外掛程式