Jira中的全流程开发管理

1. 使用人员说明

• 需求相关：PO
• 开发相关：开发负责人，分系统负责人，开发人员
• 测试相关：测试人员，业务人员

2. 工具中的字段说明

2.1 Issue Type 事件类型说明

在创建一个Issue（事件）的时候，需要首先选择Issue Type（事件类型），该类型分为以下六种，具体分类及操作人员如下：

BR（业务需求）

记录原始的业务需求，包括：服务台收集的优化需求，DT/PM收集到的修改现有功能的业务需求，以及新的功能中业务提出的需求。每个业务需求由服务台/BT/PM定义并增加到Jira的Issue中，并分解为一个或多个产品需求PRD。

PRD（产品需求）

每一个PRD类型的Issue记录一条产品需求，该产品需求的粒度以可实现的最小功能为参考，工作量需少于5人天。PRD由业务需求分析得到并关联到上级的BR，由BT/PM定义并增加到Jira的Issue中，指派给开发负责人（PM/子系统负责人）。

Task（任务）

任务类型服务于开发团队，IT PM/ IT 子系统负责人接收到PRD，拆分为开发任务task或者Subtask并指定给相关的开发人员进行开发。该任务或子任务由IT PM/ IT 子系统负责人增加到Jira的Issue中，并跟踪其执行。

Subtask（子任务）

同task，可由PRD直接拆分为Subtask。

Bug（缺陷）

缺陷分为两类，一类是服务台或其他渠道收到的业务提交的缺陷，二是SIT及UAT出现的缺陷。缺陷由缺陷发现人增加到Jira的Issue中，一般是服务台或测试人员，其他人员也可以提交缺陷，缺陷提交后指派给相关开发人员。如果不确定开发人员，指派给开发负责人或子系统负责人。

Test（测试）

测试为编写测试用例的类型，可以针对某一个Component，PRD进行测试用例的编写、测试用例的执行及缺陷提交。

2.2 Status（状态）说明

状态说明了当前Issue的处理状态，默认为：TO DO （待定）。状态分为：TO DO（待定），Progressing（进行中），Resolved（已解决），Done（已完成），Reopen（重新打开），Pending(搁置)，Feedback（反馈）。

用户可以通过浏览Issue页面中的状态操作按钮，改变当前的状态，操作为【open】【progress】【reopen】【pend】【resolve】【Feedback】【Close】。状态如下分类：

• TO DO（待定）

每一个新建的Issue初始状态都为TO DO。

• Progressing（进行中）

Issue（事件）指定给解决人之后，修改状态为Progressing，表示该Issue正在解决的过程中。

• Resolved（已解决）

当解决人把指定的Issue解决完成后，修改状态为Resolved，表示该Issue已经解决完成，可以进行测试或验证了。

• Done（已完成）

测试人员或验证人员（通常是PM），确认该Issue正确后，修改状态为Done，表示该Issue已经被验证完成，是一个合格的Issue。原则上，解决人不能够直接close指定给自己的Issue，必须由指定给自己的reporter来验证。

• Reopen（重新打开）

验证不通过的Issue，修改状态为reopen，表示该问题仍未解决，可以指回给解决人继续解决。

• Pending(搁置)

无法处理，暂时搁置的问题，修改状态为pending。

• Feedback（反馈）

解决人对问题有疑问的问题，修改状态为Feedback，并指回给reporter。

2.3 Priority(优先级)说明

在Jira中针对于BR/PRD/Bug定义了4类优先级，分别是：P1，P2，P3，P4。

• 需求类：BR及PRD

需求的优先级是指需求被实现的紧急程度，分为P1,P2，P3,P4四个等级。对于需求的优先级要考虑多个维度，如：产品价值，时间关键性，减少风险及技术成本等。优先级是相对而言的，区分可参考如下分类：

P1

• 缺失该功能会造成严重的问题和恶劣的影响
• 该需求与核心用户利益相关
• 能够解决大量用户的高频问题，提升基础体验

P2

• 缺失该功能，在一定时间内可控，但长期会有糟糕的影响
• 该需求与大部分用户权益相关
• 需要加大投入，直到用户需求基本被满足。

P3

• 具备该功能解决很多问题、产生正面的影响
• 该需求与效率或成本有关
• 需要有投入，但是不能占用P1，P2上投入的资源，也是建立产品用户忠诚度的重要因素。

P4

• 具备该功能，在一段时间后可以有良好的效果
• 该需求与用户体验有关
• 属于矛盾、错误、无关型需求，资源具备的情况下可对产品进行完善。

• 缺陷类：Bug

缺陷的优先级指缺陷必须被修复的紧急程度，分为P1,P2，P3,P4四个等级。

P1

重要且紧急的缺陷，必须被立即解决

P2

较为紧急的缺陷，需要在5-10个工作日解决的问题

P3

重要不紧急的缺陷，缺陷需要正常排队等待修复或列入软件发布清单

P4

不重要不紧急的缺陷，可以在资源充足时被纠正。

2.4 Bug severity（缺陷严重程度）说明

缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。缺陷的严重程度分为：致命，严重，一般，轻微，建议。

致命

• 不能执行正常工作功能或重要功能，或导致系统瘫痪(死机)
• 严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启动该软件不属于更正办法）
• 服务器出现内存泄露

严重

• 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
• 包括用户使用当中出现页面级异常
• 连接错误
• 统计数据错误
• 语言翻译错误

一般

• 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能
• 包括用户界面不一致
• java script 脚本错误
• 文字错误
• 其它错误

轻微

• 页面显示格式不规范
• 不符合用户的使用习惯
• 影响体验的问题
• 其它错误

建议

• 使用过程中可以提升体验的问题
• 后续可以新增加的功能

 

3. 项目设置

3.1  Component/s（组件/子系统）

Component定义了系统的组件/子系统，便于较大系统的任务分配及缺陷管理。该功能需要具有管理员权限的人员设置，见图2-1。

 

图 2-1 设置Component

设置完成之后，在创建Issue时，可以选择已经设定好的Component，见图2-2。

 

图 2-2 选择Component

3.2  Sprint（冲刺/阶段性任务）