Jira 能够记录：
●要做什么，可能包括用户需求、Bug、审批任务等
●根据事件处理的具体流程，当前由谁处理、之后由谁处理等
●开发安排，包括开发时间、版本计划等等
因此被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
但这也真的是一个非常重的工具，官方文档非常庞大。里边的一些功能的作用不理解，模块之间的关联也有些混乱，每个页面承载的信息非常多。
本文的主要目的还是对 Jira 的产品内在逻辑、设计目的和典型使用场景进行介绍。
核心基础
Project
如字面含义，Project 就是项目，对应真实的“项目”。
Issues
官方翻译为“问题”，接近于具体需要做的事情。某一个 Issue 属于某一个 Project。
Issue 有好几种类型，例如Epic，Story，Task、Bug等
Epic, Story & Task
Epic：一个庞大的功能，可能包含多个功能(Story、Task)，需要多个迭代才能完成；例如登录/注册页面，包含了登录、注册、找回密码等多个功能。有点类似功能模块。
Story：用户故事，并不一定包含非常详细、具体的需求和功能，更接近于用户遇到的问题，或者没有经过抽象整理的需求。
Task：任务，具体的、经过抽象的功能和需求。
所以首先遇到问题时可以记录为Story，开始需要细化需求的时候，把Story转换成Task。
但是如果一个Story就是一个简单、要解决的问题，也可以考虑直接进入开发。
Story和Task也可以通过Epic Link的方式添加到某个Epic下
遇到大的、需要新展开的项目，再记录为Epic
任务下的任务
一种方式是Epic下添加Issues in Epic；另一种方式是为任务设置子任务。
根据我们对Epic、Story、Task的定位，我个人认为为任务添加子任务主要适用于拆分Story，Task下尽可能不要添加子任务。
workflow
工作流，决定了某个 Issues 的生命周期和流程。Jira 在这方面提供了高度自由度，当然也就意味着相对复杂。
例如软件开发中“缺陷”的生命周期中，Open、In Process、Closed、Done、Pending 等，都是 workflow 中的某个状态。
Jira 的混乱与秩序
Jira 把所有的 Issues 都放在了一个池子里，这个感觉是很乱的。然而 Jira 通过 其内置的 Board、filter 等工具，对所有 Issues 进行整理和筛选，从而达到某种秩序。
这就好像硬盘存储，文件存储在硬盘上可能是零散在不同位置的，但通过操作系统的处理呈现给用户的却是完整、清晰的。
几个抽象的功能
Board
面板，是一个高度抽象的项目管理工具。
和项目、问题并没有强行的绑定关系，一个面板甚至可以用来管理多个项目。好比 Project/Board 是内容，Board 是表现形式。典型应用场景有：
●项目经理建立某个项目的看板，并进行项目整体进度的把控
●某个开发同学把自己相关项目的都关联到某个看板，查看自己的任务，对自己的工作内容进行安排
在面板中对某个 Issue 的状态进行变更，也会同步到相应的 Project 中，也就会影响到关联了该 Project 的其它面板。
Kanban Board VS Scrum Board
Scrum Board 比 Kanban Board 多一点敏捷开发的概念，会在敏捷开发相关的部分进行介绍
filter
即字面意义--筛选器，Jira中不同状态、不同版本、不同类型，甚至从属于不同 Project 的 Issues 都混杂在一个面板中，通过filter就可以对这些数据进行筛选，选出自己需要关心的部分，而不被其它信息干扰。
相比于 Board，filter 的功能会更加精细。Board 是聚合，filter 是筛选。
Dashboard
官方翻译为“面板”，我这里还是成为“快捷操作台”，以免和 Board 想冲突。
是一个信息聚合地，支持高度自定义，通过各种小工具，让用户能够根据自己的不同角色，聚焦于不同的模块和功能。有点类似 Android 的桌面小部件或者 iOS 的 Widget。
项目管理、流程管理中典型任务
敏捷开发管理
可以借助 Scrum Board 来管理敏捷开发。
●Backlog：类似需求池
●Sprint：类似迭代的概念，我们可以把需求放到某个迭代里进行安排
●Active Sprint：当前迭代的泳道看板，结合 workflow，更加清晰、聚焦于当前的任务
●Release：版本管理，在版本管理中进行说明
版本管理
可以借助 Board 中的 Releases 功能实现，可以设置不同的版本和信息，还可以把相关的 Issues 和版本进行关联。
对某一个 Issue 进行管理
●分配经办人：设置谁来处理该任务，同时可以对 Issue 进行关注
●设置状态：修改 Issue 在工作流中的状态
●设置优先级：如题
●设置关联的版本：如题
●具体信息：包括描述、附件，同时还可以对 Issue 进行评论
●链接：和其它 Issues 进行关联，例如某个 Issue 是另一个 Issue 的前置条件等
Issues 的分类和整理
除了前文提过的，通过 Board 聚合、通过 filter 筛选，也可以通过附加信息的方式对 Issues 进行整理。
例如添加 Label、将 Issue 添加到某个 Component 下。
另外 Issue 本身的类别 Story、Epic， Sub-task 也是分类整理的一种方式。
Epic，Label & Component
Label 则是比较灵活的工具，可以根据自己的需要使用，没有太多的约束，但是 Epic 和 Component 在网上的讨论非常多。
Epic 本质上是一堆 Story 的合集，是最终会被标记为“Done”的 Issue。因此如果有一个非常大的功能，可能更适合用 Epic。
而 Component 则不会被标记为 “Done”， 同时会有默认负责人等属性，因此适合作为相对稳定、静态的部件存在，所以我认为一个Component适合对应着一帮人。而具体怎么对应，取决于项目的划分。以下两种实践我认为都是可行的：
●UI、服务端、客户端……
●数据收集、数据存储、数据检索、数据分析、数据接口……
那么如果希望通过功能模块的方式对 Issues 进行管理应该怎么办呢？如果功能模块对应着不同的、专门负责的团队，就用 Component；否则可以考虑使用 Epic。
尾声
自己这几天研究来看，Jira 确实是一个非常有效的工具，这篇文章可能也还有一些重要但简单的概念没有介绍，例如经办人、到期时间等；另外自定义 filter、自定义 wolkflow 等高级功能我也还没提到，大家可以根据自己的需求，选择性地通过官方文档来了解。
