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图形化插件