了解了敏捷开发 Scrum 的流程之后，我们再来谈谈 JIRA 。正如前边所说，JIRA 是一款优秀的问题跟踪及管理工具。JIRA 采用 J2EE 技术，能够跨平台部署。当然，对我们来说，他还有最重要的一个功能，就是协助管理敏捷开发，在经过 Sprint 计划会议之后，产品经理把讨论好的 Sprint 任务列表添加到 JIRA 的 Story 中。而且都包含着开发的具体业务，开发用时，技术难度等。组员们可以去 JIRA 上随意选择自己喜欢的任务领取。于是，就开始了一次开发迭代。

考虑到 JIRA 的安装和配置都比较简单，而且网上也有很多这方面的教程，这里就不再赘述了。这里推荐一篇文章，就是讲 JIRA 的安装和配置《 jira5.0+greenhopper6.1.6的安装》。当然我这里也有一份比较详细的教程，是项目开发时用于培训的，由于篇幅比较多，就不再博客上贴了，有需要的联系我就行。这里，我打算选几个重要的功能跟大家说一下。

项目添加好之后，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 正是提供了自定义的工作流，让你自己去设置工作流，以满足工作的需要。下面来看一下具体的配置。

首先，把默认工作流中用不到的状态去掉，然后保存。

到此处为止，我们就把不需要的状态已经删除了。当然，为了完成我们自己的工作流，还需要添加一个状态。

由于之前的项目中，也用过一款国内的项目管理工具 —— 禅道，不过对于敏捷开发来说，基于 Scrum 的理念、开发流程等，总觉得禅道有些不合适（个人感觉），不可否认，禅道已经做的很好了，只是感觉不适合我们这个敏捷开发的项目罢了，各位勿喷。而熟悉了 JIRA 之后，发现 JIRA 更适合敏捷开发。

在 JIRA 的设计理念中，就存在对 Scrum 的一系列支持。当你开始一次迭代时，JIRA 会帮你记录任何一个时间点，由 待办 → 处理中 → 挂起 → 完成 。这几个状态可以相互转换，根据具体的条件、具体的任务、具体的环境相互转换。没完成一个状态时，都会有详细的记录。而且，JIRA 还会记录每个人的工作量，统计每个组员完成的任务量。这在绩效考核中也是很重要的一部分。

通过 JIRA，使得我们能够快速的实施敏捷开发，自动化的管理敏捷开发中的各个环节，使我们能够把精力集中到业务的实现、技术点的攻克上。而且，有了 JIRA，在敏捷开发中，组员之间的相互协作也更加高效，不会再出现“有人忙得要死，有人闲的要死”的局面了。任务进行的条件无法满足时，可以先把任务挂起，重新开一个新的任务，当前一个任务满足条件时，再重新激活。

在我看来，敏捷开发就是把任务简化，把任务细化。然后把开发时间精细到每个任务，在最短的时间内集中精力完成任务。这也是为什么敏捷开发不提倡加班的原因。重要的不是敏捷开发的过程，而是敏捷开发的思想。

JIRA，不仅仅是一款项目管理工具，同时也代表了一种敏捷开发的思想。