在我们创建Jira时，Jira上会填写各式各样的字段，不同的字段对于不同的角色人员，使用方式也是不同的，通过这篇文章，希望大家能够对Jira使用有更深刻的认识。
为什么需要严格规范?
- 易于开发，测试，产品经理沟通协作，消除沟通上不必要的麻烦
- 规范的使用便于整个项目的进度跟进，任务统计，项目里程碑更清晰
- 清晰的展现项目开发过程中需求，任务，开发售后等多维度的统计
- 掌握和运用Jira，也是一个人个人能力的提升
问题类型
从Jira大的类型上以及差异上来划分，主要有默认类型与缺陷类型两大类，首先说明下Jira的问题类型，以便在我们创建Jira时能够选择合适的类型。
默认类型
（史诗）Epic：本身可以被拆成大量story的一个合集，此种类型的Jira经常代表一个大的功能模块，不对应具体的一个用户需求。
（故事）Story：具体的一个用户需求，由项目/产品经理去创建，描述一个用户需求的愿景
（任务）Task：常用于新增的任务或者任务调整
（子任务）Sub-task：建立在Story或者Task下的子任务，用于记录实现这个父任务的子任务，可以分工给不同的人
（改进）Improvement：对已有功能或任务的改进和完善
（重构）Backend Logic Enhancement：记录开发过程中需要进行的重构任务
（客户问题）Customer Issue：客户在使用过程中发现的问题，来自客户的真实环境
缺陷类型：
（缺陷）Bug：记录产品在测试过程中发现的问题
最佳实践
以下矩阵表，对每个字段加以深入说明，我们每个人的角色，都规定了使用的规范，在我们使用Jira时需要严格执行。
默认类型的Jira:
Bug类型的Jira：
结语
希望这篇文章能够对刚刚开启使用Jira管理的公司或者团队答疑解惑，Jira使用很简单，不过能够有个最佳实践是非常重要的。
小编也是依靠多年的敏捷开发经验细心整理的这套矩阵图，更多优秀原创帖子以及疑惑，欢迎关注作者
本文由博客群发一文多发等运营工具平台 OpenWrite 发布