本文来自作者
刘华
在
GitChat
上分享「敏捷利器 JIRA 和 Confluence 使用攻略」，
「
阅读原文
」查看交流实录
「
文末高能
」
编辑 | 小春
前言
工欲善其事，必先利其器！敏捷开发的持续交付，一定程度上导致了交付的碎片化，我们需要好的管理工具。
来自澳大利亚的 Atlassian 公司推出的 JIRA和 Confluence 是敏捷开发的两大利器，它们彻底地贯彻了敏捷开发所倡导的
去中心化、协作、集体讨论、信息共享、灵活、透明、可视化等原则
。
JIRA 是项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域（很多开源项目就是用 JIRA 收集和管理缺陷与交流）。
Confluence 用于企业知识管理与协同和构建企业 wiki。JIRA 与 Confluence 相互结合，更是相得益彰。
下面我将详细介绍通过实战总结的 JIRA 和 Confluence 的使用攻略以及两者的融合（由于公司用的是英文版，所以下面所有的功能点和截图都是英文的，截图中的敏感信息也做了遮盖处理，如有不便，敬请谅解）。
JIRA：一站式敏捷管理神器
JIRA 是完全按照敏捷开发管理所需要的所有要件来开发的，完美支持 Scrum和看板方法，其易用性、灵活性、扩展性得到业界广泛认同，可谓是“谁用谁喜欢”。下面我精选了一些亮点和大家分享。
Epic, Story 和 Sub-task
在敏捷开发中，工件有下面几个层级：
-
Epic - 史诗故事。包含某个特性或子项目的相关用户故事，便于用户故事归组。
-
Story - 用户故事。具有业务价值的端到端交付，你懂的。
-
Sub-task - 用户故事下需要分配给不同人处理的子任务，不可单独交付，比如前端开发与后端开发，上、下游组件开发等。
在JIRA中，所有的工件都统称Issue，而每个Issue可指定一个Issue Type，上面提到的Epic，Story和Sub-task分别是一种 Issue Type。
JIRA 的 Issue Type 非常丰富，而且可以自行定义，对应真实的工件类型，如Support Case、Change Request、Enhancement 等。下面重点讲一下敏捷中最重要的几种Issue Type的层级关系。
Epic
由于一个 Epic 包含若干个用户故事（Story），在新建或编辑Story时，可以通过 Epic Link 的属性把该 Story 指向一个已有的 Epic，从而建立两者的隶属关系。
Story
具有业务价值的端到端交付。满足INVEST原则。
在 JIRA 中，Story 级别的Issue不仅限于 Issue Type 为 Story。所有非 Epic 和 Sub-task 的 Issue 都可视为 Story 级别的 Issue。
Sub-task
如果一个Story需要拆分成任干个任务交给不同人或团队完成，可以在Story中新建Sub-task并分配给相应的人或团队。Defect也是一种Sub-task。独立测试团队对某个Story进行测试时发现Defect，应该在该Story下创建Defect (Sub-task)，把两者关联起来。
如下图，在一个Story级别的Issue中，可以按“More”按钮，然后按“Create Sub-Task”按钮来新建Sub-task。
Sub-task 和 Story 级别的 Issue 是可以相互转换的。所以即使一开始关系建错了，也没有关系，这也体现了JIRA强大的灵活性和对延后决策的完美支持。
小结三者关系是 Epic包含若干个 Story，Story 包含若干个 Sub-task。
工作流（Workflow）
有了Issue后，我们需要工作流来管理进度和状态。JIRA 支持不同 Issue Type 应用不同的工作流（Workflow），从而满足不同 Issue Type 的实际完成过程。
比如，一个需要开发的 Story 自然要走标准的软件开发流程——需求、设计、编码、测试、上线等，一个简单任务或 Sub-task 则只需要走简单的任务流程——待处理、处理中、完成。
在 JIRA 中，我们完全可以自定义不同的工作流并分配给不同的 Issue Type。如果我们新建了一个 Issue 但后来发现它应该属于另一种 Issue Type 走不同的工作流，可以通过 Move 功能进行切换，非常灵活。
可视板
敏捷与精益都追求可视化。JIRA提供了强大的可视板功能并完美支持Scrum与看板两种方法。在JIRA的顶端的Agile菜单，可以调出可视板管理菜单，包括最近打开过的可视板。
在可视板功能中，我们可以根据所采用的敏捷方法，选择建立 Scrum 可视板还是看板可视板
这里澄清一个概念，很多人把可视板——Board 与看板—— Kanban 等同起来，其实“看板”是一种方法，有3个要点：
可视化，限制在制品，量度与流改善
。
可视板仅仅满足了“看板”中可视化的要求，没有后落实后两个要点，其实并不算在实施看板。“看板”是日语，我们要区分其中文的字面意思和其真实含义。
在 Board 的菜单中，我们可以建立新的可视板。也可以 Copy 一个已有的可视板并进行修改。
在可视板配置界面中，我们可以通过帅选（Filter）功能来定义板的涵盖范围。这个范围可以非常灵活，既可以是一个 JIRA 项目中满足某些条件的 Issue，也可以是几个 JIRA 项目的组合。
JIRA 的 Filter 功能非常强大，复杂的帅选条件可以编写 JQL（JIRA中类似SQL的语法）来实现。
确定板的范围后，在 Ranking 的属性中按“Add Rank”或“Using Rank”，便可实现在板中通过拖动来实现优先级排序。
可视板中最重要的意义是进度可视化，因此我们可以按照自己的需求来定义板的外观。
比如需要切分多少个竖列（每个竖列应该代表一道工序或一个角色需要完成的子任务）来观察 Issue 的流动情况，各类型 Issue 的状态需要分配到哪个竖列中等。
在看板方法中，一个很重要的原则是限制在制品，我们应该根据每个竖列所对应的工序或角色的交付能力来设定最大和最小并行任务数。
设置好后，JIRA 会根据在该竖列中实际并行任务数是否在限定以外来提示团队（在 Scrum 中，限制在制品是通过 Sprint Planning 完成的，因此一般无需再对竖列的并行任务进行限制）。
当一个可视板的范围比较大，里面涵盖的 Issue 数量和类型比较多时，我们还可以在板中建立横向的“泳道”来把 Issue 进行分组显示，提高管理效率。“泳道”的切分可以是按被分配人、Epic或自定义条件进行。
一个含“泳道”的看板可视板的例子：
发布管理
我们可以在JIRA中做发布计划。在管理界面中，管理员可以根据发布计划定义 Version，包含发布日期与发布提要。在每一个 Issue 中，我们可以在 Fix Version/s 属性中指定它将在哪个 Version 发布。
我们可以通过Releases页面轻松发布Release Note。
通过代码版本控制软件如 SVN、Git 等的插件，只要在提交代码时，提交备注（Comment）中包含 JIRA Issue Key，相应的代码提交信息也会显示在Issue中，从而建立 Issue 与相应的代码的可视关系。实现敏捷与 DevOps 里倡导的可追踪性。
Confluence——去中心化的文档与知识管理
可以把 Confluence 理解成 Wiki。任何人都可以生成一份文档或知识点，任何人也可以对已有的文档或知识点进行编辑，所有编辑版本都会被自动记录，而且支持多人对同一页面的并行编辑。
任何人也可以通过 Comment 对已有文档或知识点进行点评和讨论，构造协同、透明、信任的沟通环境。
除了可以构建普通的文档页面外，还可以通过其预设或自定义的模板生成会议记录、日历管理、博客、JIRA 报告等。
下面我重点介绍几个炫酷功能：
丰富的格式化
作为一款文档工具，文档格式化自然必不可少。通过格式化，我们可以迅速通过 Confluence 构建专业的文档，包含书签、Header、表格、引述、代码引用等。
如果使用像Chrome这样的标准浏览器，复制的截图可以通过Ctrl-V直接插入到文档中，非常快捷。
Confluence的页面可以导出生成Word或PDF文档，方便发送。
PS: JIRA Issue的Description也支持相同的格式化，也可导出为Word或PDF文档，便于我们为每一个用户故事或变更进行详尽、专业地记录。
页面关系灵活性
为了便于管理大量的文档，我们可以为不同的页面建立隶属关系，并可以通过Move功能随意变换这种关系，而且不影响页面的原链接地址，非常灵活。
表格过滤与透视
如果页面有表格，我们可以实现像在Excel里面的数据过滤与透视功能，如下图：
会议记录的行动跟踪
通过 Confluence 编写会议记录，不光可以记录会议议程，还可以记录行动并分配给具体个人和指定完成日期。
Confluence 有一个行动汇总页面，可以一次性看到不同会议的所有的行动完成情况。被分配的个人在行动完成日期前也会自动收到邮件提醒。
