软件工程中的质量管理是对流程的管理，当产品交付过程被不断的重复，其性能会趋于稳定，质量得到保证。而在重复的过程中，监测产品指标，优化流程即为质量管理所关心的。
在项目中，对产品质量的管理有两个维度：评价和改进。其中质量评价以准确的统计数据为基础，流程改进以操作规范为目标。
质量评价基础指标：
每个迭代任务输出量是否稳定
每个迭代有效缺陷量是否稳定
流程改进关注点：
产品线上交付成功率
线上问题修复
金属质感分割线
本文结合目前的项目实践，描述一下质量管理在JIRA中的一些技巧。
项目背景：该项目是Web端的客户管理系统，采用SCRUM流程，敏捷方法，使用JIRA作为需求管理和缺陷跟踪工具。
一、从缺陷的基本属性说起
●Priority/Severity：ISSUE的优先级别和严重级别，通常作为产品发布的一个指标。
●Env：ISSUE的发生环境，任何线上问题都是流程改进的推动者。
●Sprint：ISSUE的排期点，测试准入条件之一，属于本周迭代的Sprint才予以跟进。
●IssueFoundSprint：ISSUE的发现版本，通常用来跟踪每个迭代新缺陷量。
●Assignee：ISSUE的当前所属人，测试准入条件之一，只有当前所属人为测试时，测试人员才予以跟进。
●Resolution：ISSUE的处理方式，可以作为有效缺陷、无效缺陷和三方缺陷等统计指标的数据源。
注：
1、Priority/Severity字段的使用需要整理项目的核心功能点，作为定义P0S0级别的标准。
2、有一个共识的规范的测试准入条件是有必要的。
3、有必要定义一个共识的Sprint跟踪未排期需求，目前JIRA中在Backlog中体现。
二、总结JIRA的操作规范
1、ISSUE的创建
项目中的任何计算人力的的事务均需要有ISSUE跟踪，无ISSUE跟踪的事项不予跟进。
2.ISSUE的关闭
有QA参与的ISSUE，统一由QA进行关闭，避免QA遗漏验证点。
3、ISSUE的备注
JIRA的状态变更需要跟进备注信息。
开发方：任务类的ISSUE，需要描述实现方式以及影响范围，缺陷类的ISSUE，需要描述问题产生原因。
测试方：需要描述验证点，验证数据以及验收结果。
4、ISSUE当前所属人
一个ISSUE如果需要其他人跟进，首先Assign给某某（此处作为某某是否需要跟进的依据），并在备注中提供对方需要的信息。
项目中的协作者均可以通过当前所属人作为自己的任务范围，不在此范围内的工作有理由不予跟进。
5、ISSUE的修复版本
开发方需要在结束一个task或修复一个bug时需要完善该字段。避免开发测试版本不同步问题。
6、Sprint变更
当一个需求延期，需修改该需求Sprint字段，并关联到“需求变更Epic”，备注中描述需求变更原因，@干系人。
7、特别事项类
配置类：每个迭代需要创建一个配置类ISSUE，用来跟踪本次迭代的配置变更。
需求变更类：每个项目应有一个Epic统一跟踪需求变更事项。
线上问题类：每个项目应有一个Epic统一跟踪线上问题。
目前，需求变更和线上问题是有Epic作为跟踪的，配置变更记录放在Wiki中和LCRM统一跟踪。
有了长期的数据，才可以进一步完善总结。下图是线上问题Epic下的部分关联数据。
JIRA的那些事儿到此结束了，有一个共识的基础的操作规范，可以营造更轻松有效的工作环境。
