项目管理工具JIR
第一种说法：
JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。
JIRA功能全面，界面友好，安装简单，配置灵活，权限管理以及可扩展性方面都十分出色。
JIRA创建的默认问题类型包括New Feature、Bug、Task和Improvement四种，还可以自己定义，所以它也一是过程管理系统。
Jira融合了项目管理、任务管理和缺陷管理，许多著名的开源项目都采用了JIRA。
JIRA 是目前比较流行的基于Java架构的管理系统，由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。同时，开源则是其另一特色，在用户购买其软件的同时，也就将源代码也购置进来，方便做二次开发。
第二种说法：
现在来看JIRA，这是一个项目管理的很好辅助工具，将所有项目开发、运作过程中的所有task 、 bug、创意、改善意见都可以融汇进入这个系统。可以在第一时间将这些问题指派而责任人进行处理。
而想用JIRA来做好BUG管理和项目管理，有这几个重点要做好！
1.定义模块
模块反应了问题出现因素的范围。所发现的问题、所需要进行的任务、改善意见的指向、创意所应用的范围。
2.定义里程碑
问题、任务、意见、创意都需要分配在某一时段进行处理，时段可以是时间为单位的，周、日、时、分，也可以是里程碑，alpha/beta/close beta/open beta。如果所有的事情都可以以这两种单位计量的非常清晰，那么首先可以称赞的一点是，你的负责心已经体现出来了，你知道在什么时间该做什么事，同时，你让你的战友们知道，他们应该在什么时候做什么事！
3.定义全局处理流程
第1点和第2点，是你在为这个项目管理做的基础准备，有了第1点和第2点，那说明你在其中的工作，但这并不表明这个系统就可以运作起来。要运作起来，就必须你和你的战友们都可以在处理JIRA上的所有事务时的处理流程。
建立：建立一个issue。什么样的东西应该建立在JIRA中，我得到的经验是，所有的工作任务、所有的bug（开发过程中的，A与B之前的，A与C之前的，B与C之前，所有、所有），不单是测试小组所发现的一些黑盒测试的bug，开发过程中的也不遗漏。这样，你可以看到这个项目在动的，每天所有人都在发现问题，解决问题。
分配：问题要给能解决问题的人，问题要给理解这个问题的人。程序上问题你给了一个商备人员，那你不对了；程序的问题你给了程序，可以程序不明白你说的是什么，那也是你不对了。要降低沟通过程中的风险，建立问题者，想清楚，这个问题要由谁来处理，要告诉他什么信息。你在没有告诉清楚这些信息的时候，你对这个问题还是最大责任者。
开始：开始是指接收到这个issue后的处理手段之一，因为还有拒绝这种可能。开始处理这个问题，在向所有人声明一件事情，这个问题我开始着手处理了，我会按着计划和需求来完成这个事务。那么，开始做这件事的人，你要很坦诚的向自己说，我知道这个事务是什么，我知道要怎么去处理，我知道要在这个时间内怎么处理。你开始接受这项事务，是你对于分配给你这个事务的人的一个回应。这时事务的责任在你的身上。用你的职业精神来处理这个事务吧。
解决：整个的处理过程统称为解决。虽然有可能出现解决不了、或者在解决的过程中需要其它人来帮忙，也可能需要很多的讨论和会议，这都是解决的过程，在这个过程中，把你做过的事情，对于这个Issue相关的资料，信息版本，记录下来。让别人知道，你是用什么方法来解决的，你这种解决方法是不是很安全，还有没有其它更优化的方法。
关闭：解决完一个事务后，通常这种事务的责任转移到分配人的头上，分配人要处理的事情是，这个事务是否如需求、计划所完成，完成质量是否符合要求。在通过验证后，这一个问题需要你的关闭。在出现不符合的情况，你不能关闭这个issue，你要提供更多信息，更多资料，方便他再来解决。
重开：对于bug，出现重现的情况是常见的，这时不要让JIRA上有更多的垃圾信息，也方便开发人员找到问题原因，你需要重开这个bug，并附上相关的信息。
4.每日的统计与清理
管理项目要盯，每日的盯是少不了的，看全局的issue数量、关闭情况、进行情况、所剩未解决的数量。你可以有的放矢的去针对这些问题来看。也可以看到，谁的问题比较多，谁的进度比较慢。因为什么问题将影响进度，因为什么问题将影响产品品质。
你也有责任要清理一些问题，这种情况出现在，你没有让所有战友都可以很好的使用这个系统。清理的另一意义是理，有一些问题，你可能要在这一阶段放弃，那需要理到某一个其它时段，这个问题需要换由其它人再进行继续的处理等等。
5.阶段的统计与整理
阶段，这么划分吧，每周3/2这样两个阶段，这是除了第4点所说的之外的最小阶段吧。以它就是周、版本计划阶段、版本大的阶段划分这样的划分情况。
通过阶段内的完成情况，你可以看到谁处理的问题太多了，谁少一些，谁的难度高一些、谁的能力不足、谁不负责任。哪个部门做得不足，哪一模块需要更多人帮忙。如果说日为单位是盯的话，那么阶段来统计与整理，就是盯之后的分析与解决方案。
6.最大力度的使用过滤器
Jira提供了较多的查询条件可供个人创建过滤器和与团队分享过滤器。同时还可以自定义自己的主页，相信自定义主页这个功能在google上你已经感受过了。同样这些过滤器可以变为你的主页中的一部分，把你最需要关注的issue都呈现在你每日的第一位置。
JIRA是目前比较流行的基于Java架构的管理系统，开发者是 Atlassian，是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。
同时，开源还有另一特色，就是在用户购买其软件的同时，也就将源代码也购置进来，方便做二次开发，许多著名的开源项目都采用了JIRA。它配置灵活、功能全面、部署简单、扩展丰富等超过150项特性得到了全球115个国家超过19,000家客户的认可。
那，到底什么是Jira？
Jira是一款非常优秀的项目管理工具、完善的敏捷测试流程，页面表单自定义、工作流程自定义，丰富的图表数据统计插件，开放外部API（可与邮箱、钉钉、git进行集成，做到消息时时同步）。当然Jira的功能远不止这些……提高工作效率，试问舍它取谁？？？
需要实现如下目标：
1. 需求管理, 子需求管理（一个需求可能拆分成若干个细的需求）
2. Bug管理
3. 需求/子需求和Bug相关联，可以看到每个需求相关的Bug数量及进度
4. 可以根据条件进行搜索，比如说想看有多少Open的Bug, 每个开发人员Fix bug的进度等。
谈到Jira，就不得不关联敏捷开发了。正式由于项目是基于敏捷开发进行的，因此才引入了 JIRA 这款适合于敏捷开发的项目管理工具。
Jira之敏捷流程管理(scrum 看板模式)：
我简单说一下之前落地流程吧
通常业务部门出BRD，产品部门出PRD，并在需求池Backlog里面放置用户产品故事（story），大的模块（Epic）包含多个小的产品故事。
需求评审后，技术leader和测试leader对当前需求没有疑议之后，当场给出开发排期与测试排期。我们得到一个预上线时间，根据这个时间我们建立这个项目版本Sprit。
说到这里，我们介绍一下看板模式的三列含义
to do 将要做的事情
in progress 正在做的事情
done 已经完成的事情
这个项目sprint中的所有task都是基于我们产品部门的用户故事进行的；举个例子：1个产品故事，包含前端页面开发的task、后端接口的task、测试用例的编写。
各个职能部门、前端组、后端组、测试组、运维组、配管组建立每周周sprint（周计划），周sprint又与各条产品线的sprint中的task进行关联。
是不是很精彩，呵呵，Jira的强大远不如此
下面，我打算选几个重要的功能给大家介绍下Jira，让你们更深入的了解这个工具。
项目
安装好 JIRA 之后，需要首先创建一个项目，这里我们以权限系统为例。简单的介绍一下新项目的添加以及设置。
问题类型
项目添加好之后，JIRA 默认的是 Bug 类型，而我们要进行的是管理敏捷开发流程，因此需要对应于敏捷开发中的 Task，这就需要手动的修改一下默认的 Issue 及 Issue 的顺序。
工作流
JIRA 是基于工作流进行的，而且他也提供了很强大的工作流管理。JIRA 提供的默认工作流为五个状态：Open，Close，Resolve，In Progress，ReOpen。而我们真正使用的时候，这几个状态往往满足不了需求，例如，一个正在进行的任务，突然发现不符合条件进行，需要挂起，那么应该放到哪个里面呢？
GreenHopper看板上面会把Story，Task，Sub-Task等都列上来，而对于Story和Task在我们的思路里，是不希望它们是一样的处理流程，例如，对于Story我们只希望它从Open到Resolve或Close即可，不需要进入In Progress。基于这些问题，我们需要自己创建一个适合我们项目开发的工作流。
而 JIRA 正是提供了自定义的工作流，让你自己去设置工作流，以满足工作的需要。下面来看一下具体的配置。
首先，把默认工作流中用不到的状态去掉，然后保存。
到此处为止，我们就把不需要的状态已经删除了。当然，为了完成我们自己的工作流，还需要添加一个状态。
到这里，自定义工作流就完成了。接下来还需要在配置一下工作流方案，这里就不再一 一介绍了。
总结：
通过 JIRA，使得我们能够快速的实施敏捷开发，自动化的管理敏捷开发中的各个环节，使我们能够把精力集中到业务的实现、技术点的攻克上。
JIRA的以上的亮点，很大程度上是为实现一个目标，那就是工作效率优化，如果在平时的工作中大家可以把JIRA平台当作中介，除了上传各类需求文档、数据报表、UI原型图，还将工作产出及时更新到JIRA平台上，实现资源和信息的共享， everyone都和平台交互，结果all都知道，而不是A与B之间的交互，而others却不知道。
JIRA，不仅仅是一款项目管理工具，同时也代表了一种敏捷开发的思想。
JIRA，是一个工具，是改变你原始管理思维的一个突破。如果你要用的话，请记住，Jira不是你一个人会用就行了，是一个团队、一个系统。否则他运转不起来，就算转起来了，也有出现更大问题的时候。
现在我面对的就是出现这个大问题的时候。希望通过这样的一处整理思路的过程，让公司的JIRA系统可以快速恢复起他应有的作用。