Jira基本定义
Jira是一款事务管理软件（很多地方说是缺陷跟踪工具，我认为这种说法不够全面）。无论是“需求”，还是“BUG”，或是“任务”，都是“事务”的一种，所以Jira可以胜任非常多的角色：需求管理、缺陷跟踪、任务管理等等。因为Jira提供了专门的Scrum视图和Kanban视图，所以特别适合敏捷开发团队使用。
Jira中的常用名词解释
Jira的界面操作复杂，但是Jira的逻辑并不复杂。常见几个名词需要弄清：
Project 项目，如我们现在jira中的【shy】
Epic 史诗，如我们科微现在的广【场活动1216】，万屏建的【大学重构】都叫史诗。
Sprint 冲刺，每一个史诗可能包含可很大块的任务，我们可以将史诗拆分成多个迭代，每一个迭代可以理解成一个sprint
Issue （问题），每一个Sprint下面有很多问题。这些问题包含具体的开发任务、Bug等。
Workflow 工作流，每一个任务或bug被解的过程都需要遵循一定的流程，每个流程都会有一定的工作状态。
Jira中项目的组成
Jira中项目的组成，横看成岭侧成峰，用我个人实践习惯来讲解。先上图：
Epic（史诗）
一个项目从业务角度可以看成是由多个块，每个块叫做一个史诗。
一个项目可以拆分成很多个史诗，史诗可以通俗易懂理解为大块的需求，如我们广场项目有活动模块、话题模块、还有异常词库模块等等，这样的每一块都是很大的模块，我们可以把这些大块分别的作为一个史诗
如何创建一个史诗（Epic）
Sprint（冲刺）
Sprint这个概念太关键了，非常像禅道里说的迭代。
Sprint（冲刺）周期：
Sprint（冲刺）周期是执行敏捷的基本节奏。每一个Sprint周期都是一个固定的时间盒。在这个时间盒内，要做的故事和任务（也就是产品需求）是确定的。当周期结束时，不管需求有没有全部完成，这个时间盒都会结束，并准备启动下一个时间盒。如此循环，通过快节奏的迭代冲刺，不断交付有价值的产品并且不断修正产品。
如何拆分Sprint：
一个史诗（Epic）可能还是很大，我们可以拆分成多个迭代完成，比如话题模块（史诗），是一个较大的模块，我们可能需要3周的时间完成，但是三周对于敏捷来说算是很长的迭代，不利于敏捷交付。我们可以把三周的内容拆成3个迭代。
如话题给的时间是从11月1日开始，我们可以做如下冲刺的拆分：
Sprint1：话题1101-1107，主要完成话题增删改查的操作等；
Sprint2：话题1108-1114，主要完成话题的详情展示，站内站外分享等；
Sprint3：话题1115-1121，主要完成话题的参与度统计分析等；
在一个Sprint执行周期中，有几个很重要的点：
1）、Sprint规划会议，在会上负责人会需要坐在一起，共同决定这次的Sprint要完成哪些用户故事，并将故事分拆为任务，然后对任务进行估算。
2）、日会/站会，找一个每天固定的时间，团队成员站在一起，每个人轮流陈述上一次日会之后已完成的内容，然后对比 “期望”与 “实际”，如果不符合，可以立即发现并寻找原因加以解决。
3）、Sprint评审/演示，在Sprint结束的时候对完成的内容进行演示，或者叫验收。团队成员从用户的角度演示本期Sprint交付的故事如何被使用。
4）、回顾总结，可能都觉得没什么用，甚至团队成员在会上不知道说什么。但坚持下去，很有用！对团队来讲长期收益巨大！团队会慢慢变得更有干劲、更有效率，输出的代码质量也会提高。
Issue（问题）
再次强调jira中的问题不只是bug。用户故事、任务、bug等都统称谓问题，这个无需介怀，习惯就好。在这里只是介绍常见的几种：
- 用户故事
用户故事就是从用户角度描述用户渴望得到的功能。
一般句式：作为一名<角色>，我可以<活动>，使得<业务价值>。
<角色>说明由谁执行动作，或者谁从相关活动收到价值，甚至可以代表发起相关活动的另一个系统；
<活动>说明在系统中执行的动作；
<业务价值>说明相关活动实现的价值。
如我们为甚么要创建广场话题这个功能，我们的用户故事可以写成：
使用广场的用户希望创建优质话题，与更多人碰撞思想的火花，进而帮助更多的人提升心灵品质。
对于开发人员看到任务背后的故事和价值想必也会更加认真。
- 任务
任务就不需要多解释了，就是我们为了完成这个项目需要做的具体事情，需要注明的是，开发任务最好指明【前端开发】、【后端开发】，甚至可以更细如【IOS开发】
设计任务最好指明【架构设计】、【数据库设计】
任务拆分和描述要让任务执行者一目了然，不要再猜谜语就好，这个也是沟通的基本素养。
- Bug
Bug就是故障也不做过多的解释。
如何创建问题：
创建问题的流程和前面所说的创建史诗类似
需要注意的是，每个问题都要指定具体的史诗（Epic）和具体的Sprint。虽然jira没有做强制限制，但问题较多的情况下，如果不归类好，会很凌乱，也不便于管理者管理。
Jira中的看板
Backlog
Backlog即“积压代办的事物或工作”。是一个具有优先级的需求列表， 并对每个需求进行了粗略的估算。在敏捷中表示可以预知的所有任务，包括未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来选中项目，进入backlog。
可以分两大块版本和史诗来查看整个项目的backlog。
1）版本：
我们常常会关注每一个版本的情况，如图点击版本详情后，我们可以看到SQ_V1.1.0_20191130这个版本还有的问题情况。
分别点击分类的问题就可以看到每个版本的具体问题，如点击正在处理的问题
2）史诗
也可以看到史诗的完成情况，如下图中问题个数等
可以点击查看史诗详情
可以查看每一个sprint下的任务完成情况，这就是所谓的Kanban，哪些任务未完成，哪些进行中，哪些已经提测，可以一目了然的看到。如果哪位成员在某一个sprint中积压大量工作，就要分析原因，解决问题，否则会带来较大风险，建议这个kanban可以每天晨会都过一遍，有必要可以投在公司电视屏上，大家实时查看。
任务看板
Bug看板
3）报表
Jira中还提供了比较丰富的报表，分别为敏捷、问题分析、预测管理三大类（根据需要自己点进去看一下一目了然，不做过多描述）
敏捷类
问题分析类
预测管理类
Jira中的模块维护
一些大型点的项目都会分模块，甚至分服务。如四合院app是由很多个服务组成，所以为了能很好的 分类问题，我们要专门的维护模块
附拆分实例
一个项目拆分成多个史诗，每个史诗被拆分成多个sprint，每个sprint下有多个问题
结语
不管敏捷还是传统，不管禅道还是jira，都是一些思想和工具而已，最重要的是要雷打不动的执行，执行过程中有更好的优化，再不断快速调整。
说到执行，这个就需要大家有很强的自组织能力，不能靠外力去驱动，而应该靠自己驱动自己。
以上也是对jira和敏捷结合的一种裁剪，并非一定要这样才行，但也确实是一些很根本要把握的点。适合自己的才是最好的，适合团队的才是最好的。希望对大家有帮助。