JIRA-敏捷软件开发实用指南-全-

JIRA 敏捷软件开发实用指南（全）

原文：annas-archive.org/md5/9c4051da6a8f798eb088ef4e440d1be1

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

JIRA 软件是一个敏捷项目管理工具，支持任何敏捷方法论。从敏捷看板到报告，你可以使用这个工具来规划、跟踪和管理所有的敏捷软件开发项目。通过本书，你将学习到在 JIRA 软件的背景下，如何探索敏捷术语和概念。

本书适用人群

如果你想开始使用 JIRA 软件并学习如何以敏捷的方式运行你的 JIRA 项目，这本书是你的理想选择。

本书内容概述

第一章，开始创建你的项目，是关于如何开始创建项目的。我们将讨论项目如何帮助你保持工作有序，了解为什么 JIRA 如此受欢迎以及它的起源。我们还将讨论如何在 Atlassian 上创建一个帐户，以便你可以开始在云端使用 JIRA。我们将深入了解项目本身，以及如何利用项目来组织所有工作项。接着，我们将探讨屏幕、工作流和权限，这些内容将帮助我们定制项目，同时还会涉及与之相关的视图、通知和权限设置。

第二章，管理工作项，讲解了史诗（epic）、用户故事（story）、缺陷（bug）和任务（task）之间的区别，学习不同类型问题的定义，以及为什么我们要使用它们。我们将讨论这些问题的属性，了解这些不同工作项属性的含义，并且学习如何定制它们以满足你的需求。我们还将讨论如何管理工作中的项以及待办事项中的项，这些工作项都会在 JIRA 中显示为待办事项列表，我们将讨论如何定义、优先排序和细化它。然后，我们将讨论如何创建和配置一个看板，并介绍如何操作。如果你熟悉 Scrum，你就会知道我说的看板是什么意思。

第三章，在 JIRA 中运行项目，是关于如何执行项目的。我们将创建并开始一个 Sprint（迭代）。我们将利用待办事项清单来细化工作，然后规划并开始 Sprint 迭代。我们还将讨论每日 Scrum 会议，以及如何使用 JIRA 来保持团队的同步，确保我们是否按计划推进，是否能够达成我们的承诺。我们将重点讨论较小的故事或任务之间的区别，以及在什么情况下使用哪一种，然后我们将讨论如何关闭一个 Sprint，学习如何结束 Sprint，以及如何处理尚未完成的工作。

第四章，报告工作，深入探讨了版本和发布——它们是什么，它们之间有什么不同。我们将讨论燃尽图、Sprint 报告，以及如何解读这些报告来判断你的团队是否做得好。我们还将看一下速度图表，这可以帮助我们评估团队的表现。我们将查看发布的史诗燃尽图，以及版本和史诗报告，这些工具能够帮助你进行预测，这是一项非常强大的功能。

第五章，问题的搜索与过滤，介绍了 JQL，它是什么，如何在 JIRA 中使用简单和高级编辑器编写查询，以及如何导出结果。我们将讨论保存和管理过滤器，然后进行批量更改操作，并接着讲解如何利用这些过滤器创建新的看板。这将为你提供在 JIRA 中查看工作项的全新视角。

第六章，仪表板和小部件，教我们什么是仪表板，如何使用它，仪表板上可以放置的不同内容，仪表板可以有的不同布局，以及如何共享它，从而确保你能够广播团队的成果和进展。因此，这个课程没有太多前提要求，只需要一些我认为有帮助的东西——其中之一是具备 Scrum 的基础知识。因为在我们使用 JIRA 进行敏捷项目时，时常会提到 Scrum，所以你了解它会很有帮助。不过，最好能有一个至少有一个团队在一起合作，因为 JIRA 真的非常适合团队协作，而不仅仅是一个人在工作。尽管它也可以单独使用，但一旦学会了这些概念后，能够将它们应用到团队中会更加有益。

为了从本书中获得最大收益

• 你需要熟悉 JIRA 的基础知识，既要了解最终用户的视角，也要了解管理员的视角。

• 经验丰富的工作流、自定义字段以及其他 JIRA 管理功能将会非常有用

下载彩色图片

我们还提供了一份 PDF 文件，其中包含本书中所用的截图/图表的彩色版本。你可以在这里下载：www.packtpub.com/sites/default/files/downloads/HandsOnAgileSoftwareDevelopmentwithJIRA_ColorImages.pdf。

使用的约定

本书中使用了多种文本约定。

CodeInText：表示文本中的代码词汇、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 账号。举个例子：“让我们创建另一个 Sprint。我们称之为FP1 Sprint 1，并将This is my first Sprint作为 Sprint 目标。”

粗体：表示一个新术语、重要词汇或屏幕上看到的单词。例如，菜单或对话框中的词汇会以这样的方式出现在文本中。举个例子：“如果我们返回到右上角的 Backlog，我们可以看到我们的 Board 设置，所以我们点击它，然后在我们的 SETTINGS 下，我们可以看到 Estimation。”

警告或重要事项将以这种方式显示。

提示和技巧会以这样的方式显示。

联系我们

我们始终欢迎读者的反馈。

一般反馈：请发送电子邮件至feedback@packtpub.com，并在邮件主题中注明书名。如果您对本书的任何内容有疑问，请通过questions@packtpub.com与我们联系。

勘误表：尽管我们已尽最大努力确保内容的准确性，但仍难免出现错误。如果您在本书中发现错误，我们将非常感激您能向我们报告。请访问www.packtpub.com/submit-errata，选择您的书籍，点击勘误表提交链接，并填写相关信息。

盗版：如果您在互联网上发现任何我们作品的非法复制品，请提供该网址或网站名称。请通过copyright@packtpub.com与我们联系，并附上材料的链接。

如果您有兴趣成为作者：如果您在某个领域拥有专长，并且有兴趣编写或为书籍做贡献，请访问authors.packtpub.com。

评论

请留下评论。阅读并使用本书后，您不妨在购买网站上留下您的评论。潜在读者可以参考您的公正意见做出购买决定，我们在 Packt 也能了解您对我们产品的看法，而我们的作者则能看到您对他们书籍的反馈。谢谢！

有关 Packt 的更多信息，请访问packtpub.com。

第一章：开始创建你的项目

在本章中，我们将了解一些帮助组织工作的项目。我们将详细学习 JIRA 以及如何使用它来管理我们的所有项目。让我们开始吧。

在本章中，我们将学习以下主题：

• JIRA 简介

• 创建一个 Atlassian 账户

• 项目创建和管理

• 如何使用方案、屏幕、工作流和权限来设置项目

JIRA 简介

本节介绍 JIRA 软件的基本知识。在这一部分，我们将了解 JIRA 是什么，以及如何开始创建项目，并且 JIRA 如何帮助组织我们所包含的工作。

什么是 JIRA？

JIRA 已经使用了一段时间，最初作为一个问题票务系统，是一种错误跟踪软件，但随着项目管理的演变，敏捷流程变得越来越受欢迎。JIRA 已经成为一个非常有效的敏捷管理工具，适用于 Scrum 和常规项目，现在主要是以这种方式使用。

目前 JIRA 提供三种不同的软件包：

• JIRA Core

• JIRA 软件

• JIRA 服务台

这些软件包包括 JIRA Core 的基础软件，并且还包括敏捷项目管理功能。

JIRA 已经被广泛使用，拥有庞大的社区和众多的插件，允许进行计划、跟踪、发布和报告。以下是我们可以用来了解更多关于 JIRA 的链接：www.atlassian.com/software/jira。

JIRA 如何通过项目来保持工作有序

以下是查看 JIRA 项目的步骤：

1. 使用 JIRA 凭证登录。我们现在会注意到我们已经创建了一个“第一个项目”。这是一个软件类型的项目：

项目视图

1. 要了解这是如何完成的，点击“创建项目”。

2. 将这个项目命名为第二个项目。现在，我们可以在下图中看到我们有一个 Scrum 模板，如果想的话，我们可以将其更改为其他模板，但现在我们保持不变并点击“创建”按钮：

1. 我们有“第二个项目”，如下面的截图所示，我们在“第二个项目”中有了我们的“第一个项目”：

1. 前往查看所有项目，我们可以在这里看到所有项目：

1. 点击“第二个项目”。我们可以在下面的截图中看到这个待办事项视图是什么样子的。在这里我们可以创建测试故事，并将项目添加到待办事项中：

JIRA 使用项目来帮助我们组织工作，并为所有内容创建一个存储位置。它使用一个键（一个三到四位数字的 ID），我们也可以引用它。

我们将更详细地讨论 UI 中这些不同元素的功能，但目前需要注意的是，JIRA 使用项目来组织我们的工作。

创建一个 Atlassian 账户

在本节中，我们将学习如何创建一个账户，以及如何设置我们的 JIRA 软件，以便开始使用它进行项目管理：

1. 打开 Atlassian 网站。我们将看到关于公司、他们的一些不同软件产品等的丰富信息。我们将点击页面顶部的“试用免费版”按钮：

1. 我们会看到他们有一些选项。我们将使用 Jira 软件。他们有服务器版和云版：

1. 我们将使用云版本，因此请选择该选项。我们可以看到，云版本可以免费试用七天，但也有一些不同的付费订阅选项。由于我们只是一个小团队，所以我们选择第一个选项，$10 每月，并且我们将试用免费版：

1. 我们将看到在接下来的页面中，它会要求我们设置我们的 URL。我们选择 digitalcoffeetest，填写我们的名字、电子邮件，并且我们还需要添加密码：

一旦我们完成这些操作，网站将向我们发送一封电子邮件来验证我们刚才提供的数据。一旦我们检查邮件并验证信息正确后，我们将返回网站并登录。

创建账户就是这么简单。

项目创建与管理

在这一部分，我们将讨论如何创建项目并在 JIRA 中管理这些项目。

在 JIRA 中创建和管理项目的步骤如下：

1. 在左侧菜单中选择项目。我们可以看到我们有一个第一个项目和一个第二个项目：

1. 选择第一个项目。这将带我们到项目的待办事项视图。待办事项将存储所有我们希望在该项目中包含的故事、缺陷和不同的问题类型：

项目的待办事项视图

在左侧，我们将看到以下不同选项。首先，我们有一个搜索选项。在搜索框中，我们可以输入文字，或者也可以按下键盘上的斜杠键（/）。我们还可以对分配者进行过滤和查看：

• • 冲刺：我们可以选择这个选项，查看当前冲刺的看板视图

  • 版本：这决定了在我们发布版本时，谁能收到报告更新，这样我们就可以查看那些问题，并允许我们对不同的问题进行查询

  • 组件：这些是工作项的分组

1. 下拉到设置。这将带我们进入下一个屏幕：

如我们所见，我们有项目名称、密钥、URL、项目类型等信息，我们将继续使用软件，以便执行像 Scrum 这样的敏捷流程。我们可以分类，选择图像和描述，我们还可以决定谁是该项目的管理员，创建新的待办事项时，是否分配给项目负责人，在这种情况下就是管理员，或者我们甚至可以选择不分配。

左侧有许多选项，但我们将先查看总结，因为总结将展示所有不同选项的视图，如下所示：

总结

工作流

首先，让我们看一下工作流，以便了解工作流是如何运作的。我们将在下一部分中更详细地讲解工作流，但我们真正需要理解的是，这将控制任务从待办（To Do）到进行中（In Progress）再到完成（Done）的流转方式，并且这让我们能够自定义它的运作方式：

如果我们查看这个项目的截图，我们可以看到我们使用的是 Scrum 任务类型，这将允许我们选择在不同任务类型中出现的项目，如故事点（story points）、负责人（assignee）和验收标准（acceptance criteria）：

现在我们将研究字段。这让我们能够控制可用的字段：

我们可以做的事情之一是设置和创建组件。

1. 现在我们点击左侧的“组件”，并将此组件命名为Test：

1. 这将允许我们将该组件分配给不同的任务类型。我们可以执行一些操作，如设置权限，正如以下截图所示：

我们甚至可以设置通知，如下所示：

我们可以看到，当任务被创建时，当任务更新时，我们将通知所有观察者、当前负责人和报告人等。我们还可以自定义这一设置。如果你是那种已经收到了太多电子邮件的人，可能希望将其精简一些，这样我们就只会收到最重要操作的通知。现在我们知道如何在 JIRA 中创建和管理项目了。

如何使用方案、屏幕、工作流和权限来设置项目

在上一部分中，我们了解了 JIRA 的配置方案，以及如何根据屏幕、工作流、权限甚至通知来设置项目。

在本节中，我们将详细学习以下内容：

• 屏幕

• 工作流

• 权限

• 通知

屏幕

我们将切换到 JIRA 账户，查看我们的项目视图：

1. 首先，我们将选择一个项目，一旦项目加载完成，我们将继续选择该项目的设置。我们将进入左侧菜单并选择设置。正如我们之前学到的，我们将设置我们的设置。

2. 我们在前面的章节中简要了解了这一点，但接下来我们将更深入地学习屏幕（Screens）。我们可以看到，我们使用的是所谓的 Scrum 问题类型屏幕方案。我们有一个默认的屏幕方案，涵盖了不同的故事类型（Story）、史诗（Epic）、任务（Task）和子任务（Sub-task），然后我们有一个 bug 屏幕方案，涵盖了 bug 问题类型，如下图所示：

1. 点击右侧的编辑图标。然后我们可以查看默认的故障单界面，如下所示：

1. 这将使我们能够控制在问题类型中出现的所有不同字段。可能有些字段我们不需要使用，因为我们的组织不使用它们，或者我们认为它们没有价值，在这种情况下，将它们从界面中移除会提高效率，因此我们不需要查看它们。我们可以通过拖动和移动这些字段来调整它们的顺序，但假设我们不想要组件字段。那么，我们可以通过点击删除按钮轻松移除它们。组件将不再出现在我们任何问题类型中，除了 bug 类型，对吧？我们还没有配置 bug 类型。

2. 在底部，我们可以看到选择字段的选项，因此我们实际上可以选择一个字段，如果我们想要添加回某些内容，比如 Components：

或者，我们甚至可以直接输入 components 并以这种方式将其添加回来，然后我们会把它拖回到描述之前的地方，就像之前那样。这就是我们在 JIRA 中使用屏幕的方式。接下来，我们来看看工作流。

工作流

在左侧选项中，点击工作流（Workflows）。

工作流将允许我们查看状态如何相互影响，以及项目如何从一个状态移动到另一个状态，以便我们能够了解其工作原理：

1. 点击 FP: Software Simplified Workflow Scheme，如下图所示：

这将带我们到以下屏幕：

1. 任何类型的事项都可以移到 TO DO 一栏。一旦我们创建了任何类型的事项，它就可以自动移到 TO DO，任何类型都可以移到 DONE，任何类型都可以移到 IN PROGRESS。

2. 我们实际上可以通过点击添加状态来将一个状态添加为 Closed。

3. 将 Closed 状态拖到底部，位于 IN PROGRESS 下面，现在我们就有了一个新的状态：

然后，我们可以允许不同的转换发生到这个关闭状态。我们可能会想做的一个例子是，假设我们为某个项目分配了故事点，或者可能是分配了小时数。当我们通过工作流推进该项任务，并且任务从“进行中”转到“完成”时，接着我们将其移至“已关闭”状态，我们可能希望将剩余的小时数自动更新为零。这是我们可能在工作流中希望做的一个例子。

权限

我们想查看权限，因此我们将调出默认软件方案的权限选项，这也是我们在 Scrum 项目中使用的方案，如下图所示：

项目权限

由于我们是唯一访问和控制该内容的人，我们可以访问所有内容，但如果有更多人被分配到该项目，那么我们就可以从项目权限以及问题权限的角度来识别谁能做什么。

通知

我们可以看到在我们的第一个项目下有一个通知选项。我们在上一节中学习了一些关于这个的内容，现在我们将更深入地了解它：

假设我们是报告问题的人，当问题被创建时，我们希望当前的指派人（被分配到该问题的人）能收到通知，同时我们还希望该项目的所有观察者也能收到通知。作为报告者，我们将收到通知。但假设该问题之后被更新，一旦问题更新，我们可能不再希望收到通知。因此，我们可以编辑通知设置。

点击“删除”按钮，位于“问题已更新”部分下方。这将带我们进入下一个界面：

现在，报告者在项目创建时会收到通知，但在项目更新时不会收到通知。项目被指派时，报告者会再次收到通知。

总结

我们已经完成了第一章的内容。在这一章中，我们讨论了 JIRA 是什么、它今天的用途、为什么我们应该使用它，还讨论了项目以及 JIRA 如何将工作组织成项目格式。我们学习了如何创建 Atlassian 帐户以便开始使用 JIRA。我们讨论了如何在 JIRA 中创建和管理不同的项目以及如何处理它们。最后，我们深入了解了项目配置的具体内容，例如屏幕、工作流、权限和通知。

在下一章中，我们将更详细地讨论如何管理所有工作项，以便我们有大量的任务要处理，而 JIRA 将帮助我们实现这一目标。

第二章：管理工作项

在上一章中，我们了解了 JIRA 是什么，如何开始使用它，以及如何在 JIRA 中创建项目。在这一章中，我们将学习如何管理我们拥有的所有工作项。让我们开始吧。

在这一章中，我们将学习史诗、故事、缺陷和任务，它们各自是什么，我们如何在敏捷项目中使用和创建它们。然后，我们将学习问题类型属性，讨论如何添加和移除它们，使它们真正定制化以适应我们在 JIRA 中进行的工作。接下来，我们将学习如何管理待办事项中的条目，然后了解我们的看板（对于那些使用 Scrum 的人来说，我们会对看板非常熟悉），以及如何配置它。

在这一章中，我们将学习以下内容：

• 史诗、故事、缺陷和任务的介绍

• 问题类型属性及其添加与移除

• 管理待办事项中的条目

• 创建和配置我们的看板

史诗、故事、缺陷和任务的介绍

史诗，如你所料，是较大的故事。它们需要有一个明确的开始和结束，就像任何故事一样。我们希望它们能够完成，这意味着它们必须有某种形式的结束。我们倾向于将史诗视为跨越多个 Sprint 的工作，而故事则通常会在一个 Sprint 内完成。史诗不是工作项的集合，我们会深入探讨这一点，因为这是 JIRA 用户界面中人们常见的做法。我们将看看如何使用组件和标签来实现这一点，而不是使用史诗。史诗将包含故事、缺陷和任务，它们实际上是这些项目的集合，也就是一个大故事。

故事比史诗要小。故事、缺陷和任务在层次结构上是同一级别的；它们都是可以在待办事项中互相优先排序的内容。故事也叫做用户故事，之所以这样叫，是因为它们的目标是专注于用户，我们需要考虑这项功能的新增部分，确保我们一直在思考为谁而构建它。因此，它们被称为故事或用户故事。

Bugs 是我们称之为缺陷的东西，当出现问题时，它们就会发生。在 JIRA 中，总是会有一些问题优先于新功能，而我们知道，我们应该考虑我们是否想花时间在这个 Sprint 中修复某些问题，还是想创建一些新功能？我们应该将这两者进行优先排序，并相互对比。

子任务是我们将快速查看的内容。如果我们有多人共同处理一个故事或缺陷，且希望将其分配更细致的工作层级，我们可以使用子任务。

创建史诗、故事、缺陷和任务

要了解史诗，我们可以去查看我们的项目。在上一章中，我们创建了第一个项目（First Project）和第二个项目（Second Project）。

创建一个史诗的必要步骤如下：

1. 点击我们在 JIRA 账户中创建的第一个项目（First Project）。

2. 在我们的项目中，我们可以看到有待办视图。在这个视图中，我们有三个故事。我们可以看到在下方面板的侧面，我们有版本和史诗。点击史诗（EPICS）：

1. 我们可以看到在前面的图中，我们没有任何史诗。我们将创建一个史诗，命名为My Test Epic。在摘要中，我们可以插入关于该史诗的信息。让我们继续创建它。我们需要一个摘要，命名为This is a summary。现在我们有了一个测试史诗：

让我们看一下这个史诗。我们可以看到，如果我们在左侧查看它，可以展开或收起史诗。它有一个 JIRA ID：

我们可以选择想要使用的颜色，并且可以编辑名称、史诗细节，并将其标记为完成：

更重要的是，在史诗下面，我们可以看到有多少个问题、故事、错误或任务包含在这个史诗下。我们还可以看到有多少个已完成、未估算和已估算。在底部，我们可以看到一个状态栏。

我们将创建我们的待办事项，然后将它们拖动到史诗中，这样我们就将它们分配给了史诗。这个史诗是一个故事，是一个大故事，但它是可以开始并完成的。重要的是，这不仅仅是一个分组，因为史诗的目的不是这样。

如果我们想在 JIRA 中对项目进行分组，那是稍有不同的事情，对于这个需求，我们可以使用组件来实现：

1. 从左侧的选项中选择组件（Components）。

2. 我们将创建一个组件，因为我们还没有。我们将其命名为My Test Component，为了避免再次出错，我们将使用描述中相同的值。我们可以选择一个组件负责人，并且选择一个默认分配人，这个人基本上就是默认分配给该项目的人：

我们可以使用我们创建的组件将项目进行分组。

让我们来看一下如何创建一个故事。

我们可以看到我们有三个故事。我们将继续创建一个新的，命名为The newest story。

我们可以看到，在实际创建故事时，我们有创建故事、任务或错误的选项，并且它们在 JIRA 中具有相同的层级排名：

一个故事通常代表一项新功能，任务只是需要完成的事情，而错误是需要修复的损坏问题。

我们将创建一个新的故事，创建最新的任务，然后创建最新的错误，这样我们就有了所有三者。我们可以在下面的截图中查看它们：

待办事项视图

当我们选择这些工作项时，右侧的预览窗格将显示其详细信息。

我们将要查看的另一件事是，当我们在待办事项视图中选择一个项目时，实际上可以按键盘上的E键，它将提示我们进行编辑。这是一个很好的快捷方式。另一个需要注意的点是，如果我们选择了一个未分配的项目，我们实际上可以按键盘上的A键，它会提示我们将该项目分配给某人。

在本节中，我们将讨论的最后一件事是如何创建子任务。如果我们在预览窗格中查看到我们最新的故事，我们可以看到我们有能力添加附件、链接工作项、将多个工作项链接在一起并创建依赖关系，然后我们有这个创建子任务的选项：

再次，我们可能会使用子任务，如果这个故事需要由多个人来处理，并且我们真的希望更具体地了解每个人将要做什么。我们可以点击“创建子任务”，正如我们在下面的截图中看到的，在右下角会有一个提示。我们可以说这是我的子任务，然后创建它：

创建子任务

子任务允许我们使用多个不同的工作项，这些工作项存在于一个故事之下。

在本节中，我们学习了史诗、故事、缺陷和任务。在下一节中，我们将讨论问题类型的属性。我们将详细查看每个问题类型下可用的不同属性，然后讨论如何添加和删除这些属性，以便更好地适应我们的工作。

问题类型属性及其添加和删除

在本节中，我们将讨论问题类型的属性、如何添加它们以及如何删除它们。

首先，我们将学习可以分配给故事、任务和缺陷的不同属性类型。然后，我们将讨论如何自定义这些属性，并调整屏幕显示，以便只显示我们想看到的内容。

不同类型的工作项属性（故事、缺陷和任务）都是 JIRA 工作项。

以下是我们可以使用的属性：

• 受指派人：这是被分配来使用该工作项的人。

• 附件：这些是需要附加到该工作项上以提供更多说明或展示已完成的内容。

• 评论：添加我们的观点。

• 组件/组：这些是分组，用于将项目聚集在一起。

• 描述：这是一个史诗链接。

• 史诗链接：我们在上一节中讨论了史诗实际上是一个大型故事。如果我们查看与史诗相关联的故事时，我们会使用这个。

• 固定版本/版本：这是一次性发布的一大组功能。如果故事、缺陷或任务属于某个版本，那么它会出现在这里。

• 问题类型：这是一个故事、缺陷或任务。

• 标签（Labels）：这些类似于组件，但它们是跨项目分组的方式。

• 链接问题（Linked issues）：这是我们可以在不同问题之间创建依赖关系的方式，如果某个问题依赖于其他问题，或者被其他问题阻塞。

• 优先级（Priority）：这有点显而易见。我们可以选择高、中、低优先级，并且我们将在 JIRA 中使用不同的优先级状态。

• Sprint：该工作项是否包含在一个 Sprint 中，如果是，属于哪个 Sprint？

让我们来看一下 JIRA 和一些工作项属性：

1. 我们有之前创建的最新故事。我们按下键盘上的 E 键，或者可以使用右上角的三个省略号进入编辑模式：

1. 我们正在查看问题 FP1-29。 这是我们最新的故事。我们可以看到以下截图，在我们向下滚动屏幕时，我们有能力将问题类型从故事（Story）更改为任务（Task）、缺陷（Bug）或史诗（Epic）：

问题类型属性及其添加和移除

在上一个部分中，我们创建了一个我们可能会记得的组件。我们实际上可以在这里查找该组件。如果我们想使用这个，我们有了 My test component，它允许我们将这些项分组在一起：

项目的分组

描述区域有一个富文本编辑器，这很不错。我们有 Fix Version/s，它基本上让我们决定这个版本将会在哪个版本中发布。版本是我们最终会发布的东西。这里我们还有一个优先级（Priority），我们之前已经讨论过优先级分为高（High）、中（Medium）、低（Low）等。标签（Labels）是跨项目的分组，我们实际上可以通过选择它们来查找，也可以创建新的标签。如果我们使用 cross-project-label，我们可以看到我们已经有一个标签，并且可以继续为其分配标签。我们可以通过拖拽或浏览的方式使用附件（Attachments）。在链接的问题（Linked Issues）中，我们可以将一个问题与另一个问题链接。我们有多种方式可以链接问题，比如使用 blocks（阻塞）、is blocked by（被阻塞）、clones（克隆）、is cloned by（被克隆）、duplicates（重复）等。然后，我们可以在这里输入问题，并且可以实时搜索。我们可以将问题分配给其他人或自己。我们还可以分配史诗（epic），并且可以分配它应该出现的 Sprint，我们还可以通过拖拽的方式分配史诗和 Sprint：

接下来，我们有了我们的富文本编辑器（再次用于评论），这样我们就可以看到可用的不同字段。这里还需要注意的是右上角的 Configure fields 选项。有时候，我们不会使用很多这些字段，可能会用到全部，但也有可能我们不会使用其中的一些。

1. 如果我们选择“配置字段”选项，我们可以看到我们有能力开启或关闭所有字段，甚至可以选择自定义字段并取消勾选评论字段。当我们保存这些更改时，我们会看到这个设置会影响我们在查看这些项目时所做的更改：

配置字段

1. 让我们更详细地看看这个预览窗格；让我们看看每个项目。我们可以选择观察或取消观察一个项目：

预览窗格

这在我们项目中有多人参与时非常有用，如果我们希望有人在该项目的状态发生变化时接到通知。我们可以看到我们是该项目的观察者，这实际上是因为它被分配给了我们，并且我们也报告了它。我们可以看到它实际上没有被分配，但已由我们报告。这自动使我们成为观察者。如果我们记得在上一节中讨论的通知工作流，我们已经创建了标签，已经为这个待办事项设置了进行中的状态，还有更多功能，例如能够链接项目、附件和子任务。我们还可以进行故事点分配，在这里我们可以查看组件、优先级和报告者。我们还可以显示更多或更少的项目。我们可以看到它实际上包含时间跟踪以及诸如子任务评论之类的内容。

我们通过预览窗格可以轻松完成很多操作，这非常方便，因为我们实际上不需要离开屏幕来进行很多修改。一旦我们将这些项目拉入一个冲刺，这些字段中的一些将无法编辑；一旦这个故事进入冲刺，我们就无法更改其中的一些值。我们稍后会在创建冲刺时看看这个。

在下一节中，我们将讨论如何管理待办事项中的这些项目。我们已经有了这些项目并分配了所有这些属性，因此我们需要能够管理它们、优先排序它们等等。

管理待办事项中的项目

在这一节中，我们将学习如何管理待办事项中的项目。

在这里，我们将学习以下内容：

• 如何创建项目

• 如何优先排序项目

• 如何将项目分配到史诗和版本中

• 如何在看板视图中创建和使用快速筛选器

• 将完全细化并准备好进入冲刺的工作分开

让我们回到我们的待办事项列表。我们可以看到我们已经有了这些项目。在 JIRA 中对这些项目进行优先级排序非常简单。我们所要做的基本上就是拖放它们。这意味着我们可以以任何方式移动这些项目，这让我们的产品负责人可以轻松地将所有这些东西按他们想要的方式进行调整。

我们之前创建了一个史诗，正如我们在下面的截图中看到的那样，我们有“我的测试史诗”。我们希望将一些项目分配给它，可能是所有最新的项目，这样也可以。让我们取第一个故事（即最新的故事），将它拖到我们的史诗中，一旦我们这样做，就会收到一个提示信息。我们还可以看到，在我们的史诗中，分配该项存在问题：

让我们继续进行任务和 bug 的处理。我们还可以将这些项移动过来，以便在我们的史诗中有三个项目。我们只需按住Shift键，就能选择多个项目：

向史诗添加项目

接下来，我们来看一下所谓的版本，我们可以看到，这将是我们发布给客户、市场或类似目标的增值部分。在大多数情况下，我们使用版本来跟踪一个月、一周或一个 Sprint 中已完成的工作量。所以，在这里，我们可以回顾并报告这一点：

管理待办事项中的项目

版本与史诗稍有不同。一个版本中可能包含多个史诗，或者也可能只有一个史诗。我们可以看到，在前面的截图中，有一些问题没有版本关联，也有一些问题没有史诗关联。这两者可能是相关的，但也不一定是层级连接的。版本是我们将工作进行分组的一种方式，正如我们看到的那样，如果我们查看发布内容，最终版本就是我们要发布的内容。我们可以看到，在接下来的截图中，版本 2 和版本 3 都是未发布的：

发布

我们可以选择这些项，然后查看它们下方显示的项目。以下是我们在创建项目时，JIRA 中默认的所有项目项：

发布版本

我们可以看到，这为我们提供了一个清晰的视图，展示了版本中包含的内容，已经完成的工作量以及进行中的工作量。一旦完成，我们可以点击“发布”按钮，实际上就能发布该版本。这就是这个版本强大的地方。

回到我们的待办事项中，我们可以看到，将项目分配到版本中是相当容易的，我们还可以看到这些项目在史诗中有一些可视化的确认。如果我们将它们拖动并放入版本中，我们也能看到这一点。我们可以看到，这些项目被包含在版本 2 中，我们可以对另外两个版本执行相同操作。这些故事在版本 2 中，它们也是这个史诗的一部分：

待办事项视图

接下来，我们要查看的是“快速筛选”。这些筛选器非常强大，尤其是当我们与团队一起合作时，需要快速查看并浏览待办事项清单。JIRA 提供了一些默认的快速筛选器。它们只会显示最近更新的问题和条目。它们还提供了“分配人”，这也很有帮助，但假设我们想查看任何已经分配到先前提到的组件中的条目：

我们有一个组件，它是由一些项目组合而成，叫做“我的测试组件”。为什么我们不回到待办事项清单呢？我们将转到屏幕的右上角，选择看板设置。我们将在下一节中详细查看许多看板设置。

我们将进入“快速筛选”并命名为Test Component。在我们的查询中，JQL 将是component= "My Test Component"。如果需要，我们还可以添加描述。接下来，我们点击“添加”按钮，这样就创建了一个名为Test Component的快速筛选：

如果我们再次回到待办事项清单，我们可以看到我们有一个“测试组件”查询。如果我们选择它，只有那些已经分配了组件的条目会出现。我们之前已经将“我的测试组件”分配给了最新的故事，当时我们在编辑该故事的窗口中：

接下来，我们要查看的是创建一个准备好的迭代周期。点击“清除所有筛选器”，这样我们就可以看到所有条目。我们可以看到“创建迭代周期”按钮，在这里我们可以创建一个迭代周期。我们不会马上运行它，但可以创建一个迭代周期，基本上将其作为一个容器，帮助我们在待办事项清单中的工作准备好时使用。我们将其称为精炼的工作。我们这里的工作已经被精炼过，这意味着它符合即将进入迭代周期的团队的准备定义。这意味着它将有验收标准，大小已经被估算，并且会有所有修复或构建所需的信息：

我们可以取出下面截图中显示的三个最新条目，然后直接将它们拖到迭代周期中。我们可以将这个迭代周期命名为Ready：

然后，我们可以做的是，利用这些完全精炼的工作，不仅在下一个迭代周期中使用，而且随着团队速度的提高，实际从这一部分拉取故事到我们的迭代周期中，这样团队在加速时就有了工作。我们将在运行迭代周期时更详细地讨论这一点。

在下一节中，我们将讨论如何处理和配置看板。我们的待办事项清单已经准备好了，已经创建了问题，并且这些问题已经分配到了史诗和版本中。我们知道这些内容下的所有属性是什么。

接下来，我们将查看看板，它是我们在运行冲刺时将使用的工具，也就是说，我们正在准备运行我们的第一次冲刺。

创建和配置我们的看板

在本节中，我们将讨论如何创建和配置我们的看板。

在本节中，我们将讨论以下内容：

• 虚拟 Scrum 看板和实际 Scrum 看板的区别

• 代表工作流状态的列以及如何修改工作流

• 游泳池线

• 估算选项——时间与故事点

让我们去看看 JIRA。我们可以看到，我们实际上已经把那些不在我们 Ready Sprint 中的事项拿出来了。它们尚未经过完善，我们把它们拉入了 Sprint 0，这是一个测试冲刺。最终，这将成为我们放置在冲刺看板上的 Sprint，但在此期间，我们需要准备好我们的看板。我们可以看到，我们已经为每个故事分配了故事点值。我们将在截图中看到这些值，它们是灰色的，我们也可以在预览窗格中看到它们：

待办事项视图

以下截图代表我们的活跃冲刺，最终这将成为我们的看板。如果我们点击开始冲刺，这些事项将出现在活跃冲刺看板上，但让我们在开始冲刺前先看看这个看板。

物理 Scrum 看板通常是一个白板，上面有多个列。每一列代表我们工作流程中的不同步骤：

我们可以看到，在最简单的形式下，我们有需要完成的任务、正在进行的任务以及已完成的任务。

我们的快速筛选器也可以供我们使用。我们可以看到我们有能力查看这些信息，很多时候我们想要做的其实是设置所有将要参与本次冲刺故事的团队成员，并把他们放在顶部。然后，在我们进行每日 Scrum 时，我们实际上可以点击每个名字，只查看该人员的事项，并尝试找出是否存在任何障碍。这就是 Scrum Master 在 Scrum 冲刺中扮演的角色。

因此，我们需要在工作流中添加一个测试步骤，这样任务应该先进入 TO DO，然后是 DONE，IN PROGRESS。一旦它们被处理过，就需要进行测试，然后才能算完成，这样我们就能保持高质量。我们在 Scrum 团队中有很多测试人员，这样做完全没问题，因为我们实际上可以将一个卡片移到测试列中，让我们的测试人员帮助我们进行测试。如果我们移动到右上角，我们会看到三个省略号（…）。让我们进入看板设置，查看一下这个。在这里我们之前设置了一个用于 Test Component 的快速筛选。查看如下截图中看板的常规设置：

我们可以看到像看板名称这样的内容，我们可以根据是否在此显示来进行更改，管理员，以及位置。我们实际上可以创建查询并从查询生成看板，但我们在此项目中只是使用 JIRA 的默认设置。我们可以看到在前面的截图中，我们有项目，有查询，并且我们可以看到我们实际上可以将多个项目放入一个看板中，但我们将保持这些设置不变。

接下来，我们来看看列：

FP 看板设置

这是我们想要修改的内容。我们希望在我的工作流中添加一个测试步骤。为了添加一个新列，我们需要一个新的状态，好吗？我们在我的工作流中创建了这个 TESTING 状态，如前面的截图所示，添加另一个状态的方法是进入工作流。记得之前我们做的工作流吗？我们可以通过选择编辑图标来查看这些工作流：

Issues

我们可以看到，在这里我们实际上创建了一个 TESTING 步骤。任何步骤都可以过渡到这个步骤。基本上，我们有这个 TESTING 步骤，并且我们允许所有状态过渡到这个步骤；我们在我的工作流中设置了这个。现在让我们回到项目中。我们将返回到 Issues，进入设置，进入项目，然后返回到我们的第一个项目。我们应该回到第一个项目的看板。我们已经在工作流中创建了这个步骤。如果我们返回到看板设置中的列，我们可以添加一个列，并且我们可以说我们要将这个列命名为Testing。我们可以看到这个列在没有状态的情况下不会显示在看板上，但没关系，因为我们在工作流中创建了这个状态。我们可以将这个状态移到我们刚刚创建的列中：

列管理

我们有 To Do、In Progress、Testing 和 Done 列。如果我们返回到看板上，我们会看到有一个 TESTING 列。

接下来，我们可以看看 Swimlanes。

Swimlanes 实际上是横跨整个看板的，我们可以以多种方式使用它们。JIRA 提供了几种选项：

Swimlanes

在大多数情况下，我们可能会做的是针对指派人、史诗或故事，如果我们有带子任务的故事，那么我们的子任务将显示在看板上，并且我们可以在 Swimlanes 中展开和折叠这些故事。我们现在暂时将其保留为故事。

我们已经讨论过快速过滤器。我们有一些功能，可以根据以下截图中显示的选项来修改卡片颜色：

卡片颜色

换句话说，如果我们有一个高优先级的卡片，因为优先级设置为高/关键，我们可以让它改变颜色。我们还可以更改卡片上显示的项目，并且可以显示三个额外的字段。这让我们可以选择这三个额外字段是什么，但现在我们将它们保留为默认设置：

卡片布局

然后，我们有了估算。使用 Scrum 时，我们通过故事点来衡量我的速度。我们并不真正使用时间，因为我们发现相对估算比时间估算更有效。然而，很多团队仍然使用时间来进行估算：

估算

如果我们使用时间并且正在消耗小时数，那么这里就是我们想要进行更改的地方。我们需要选择剩余估算时间和已用时间，然后进行原始时间估算的调整。最后，工作日，如我们所想，实际上是为使用此看板的小组设置工作日：

时区

我们已经配置好了所有这些，准备好了我们的看板，并且我们的 Sprint 中有项目。我们认为我们可能已经准备好开始一个 Sprint 了，接下来的一章就是关于这个的。

摘要

让我们来谈谈我们学到的内容。我们讨论了什么是史诗、故事、缺陷和任务，如何使用它们，以及为什么选择一个而不是另一个。我们了解了可用的不同工作项属性、自由问题类型，然后学习了它们是什么以及如何添加或删除它们，以便我们能够配置 JIRA 以满足团队的需求。接着，我们学习了如何管理积压中的项目，优先级排序、编辑任务分配、将任务分配给史诗和版本等等。最后，我们讨论了什么是看板，如何配置看板，使工作流与我们的工作流匹配，以及如何有效地管理这些项目在 Sprint 中的进展。

在下一章，我们将开始我们的项目。

第三章：在 JIRA 中运行你的项目

在第一章，开始创建你的项目中，我们了解了 JIRA 是什么，以及如何开始创建项目。在第二章，管理工作项中，我们讨论了如何管理工作项，以及不同的工作项是什么，且我们对这些内容进行了深入探讨。

在这一章，我们将讨论我们的项目，以及在项目进行时如何使用 JIRA 来管理它。

在本章中，我们将学习以下主题：

• 创建和启动一个 Sprint

• 每日 Scrum

• 较小的故事或任务

• 结束 Sprint——Sprint 报告

创建和启动一个 Sprint

在上一章，我们详细讨论了史诗、故事、缺陷和任务，如果你想更多地了解这些内容或者深入探讨它们，可以回到第二章，管理工作项，重新查看这些内容。在本节中，我们将讨论如何创建和启动一个 Sprint。

在本节中，我们将涵盖以下内容：

• 待办事项视图，让我们可以优先排序其中的故事、任务、缺陷等项目

• 待办事项的过滤视图

• 创建 Sprint 以容纳工作

• 故事点估算

• 团队承诺的规模

• Sprint 的调整

让我们转到 JIRA，查看这个项目。这是待办事项视图，我们可以看到待办事项中有一些故事，以下截图展示了这一点：

待办事项视图

从前面的截图中我们可以看到，我们有四个故事，一个任务和一个缺陷。我们可以通过拖放的方式优先排序这些项目，按我们喜欢的顺序进行排列。最重要的项目会排在最上面。

从前面的截图中我们可以看到，这些故事有点数值。我们可以在右侧看到第一个故事，它的故事点数为 3，下面的那个为 1，依此类推。记住这些故事点，然后参考其中的疑问、工作量和复杂度。我们可以通过选择一个项目并进入右侧的预览面板来编辑这些值：

创建和启动一个项目

我们可以编辑这些值中的一些，无论是状态、负责人、标签、故事点等等，然后在顶部有一个筛选功能，可以按负责人进行筛选，以及其他一些快速筛选器，包括“仅我的问题”、“最近更新”等。我们可以在下面的截图中看到，只有一个负责人。在实际场景中，我们会看到整个团队的成员列表：

我们有这个待办事项，其中包含一些项目，我们想做几件事。首先，我们有一个叫做“准备定义”的概念，包含所有已经完全精炼的项目，这意味着我们之前的所有问题已经得到解答，关于这个项目的理解已经明确，并且它们符合我们团队的“准备定义”。我们的准备定义中可能包含验收标准。我们知道产品负责人认为该项目完成的标准，并且其他标准也会满足，以确保它可以被认为是“准备好”的。理想情况下，我们希望随时有至少两个 Sprint 的准备工作可以执行。

让我们先来做这个。我们将创建一个 Sprint，称之为 Sprint Ready。通过点击省略号，我们可以编辑这个 Sprint 并将其命名为Ready，并将 Sprint 目标设置为“已完全精炼的工作”，如下所示：

更新后，我们就有了一个Ready Sprint。我们可以看到在我们的待办事项中，前面三个故事看起来已经准备好可以执行了。将它们拖到我们的Ready Sprint 中，该 Sprint 中的项目已经完全精炼并准备好执行：

我们要做的就是创建一个我们实际要执行的 Sprint。

让我们再创建一个 Sprint。我们将其命名为FP1 Sprint 1，并将这是我的第一个 Sprint作为 Sprint 目标：

我们实际上可以将此项移动到列表顶部，正如下面的截图所示。然后，列表下方会有一个“Backlog”部分，表示列表中可能最终会用到的其他项目：

我们将挑选其中的两个项目并将它们拖到我们的 Sprint 中，如下所示：

接下来的问题可能是，我们如何知道 Sprint 中是否已加载足够的故事点？我们如何知道里面的工作量是否足够？ 这是值得问的好问题。

通常，我们希望在第一次迭代中达成团队承诺，然后在第二次迭代中根据第一次迭代的输出做相应调整。我们在迭代中完成的故事点数叫做我们的“速度”。我们使用前一次迭代的速度来帮助确定下一次迭代的速度。我们能够完成它，并根据实际情况进行调整。经过三次迭代后，我们就会有所谓的“昨天的天气”，之所以这么称呼，是因为昨天的天气是已知的。我们知道昨天的天气情况，但明天的天气只是预测，而预测是我们能做的最好的事情。通常，预测结果会很接近，但可能并不完全准确。我们可以使用昨天的天气，也就是过去三次迭代的平均速度，这成为我们计划的最大值。鉴于 FP Sprint 1 作为一个团队还没有前次的速度，我们将承诺完成四个故事点，然后看看我们是否能够完成。

我们已经设置好了迭代；所有的故事点已经分配，所有故事都符合“准备就绪”的标准，甚至还预留了一些额外的任务，以防我们提前完成这些任务。让我们开始我们的迭代吧：

我们可以看到，我们已经具备了命名迭代的能力，迭代的持续时间、开始和结束日期，以及迭代目标。这个迭代中有多少任务正在进行呢？让我们来看一看：

每日 Scrum

我们正在进行一个迭代。在本节中，我们将讨论每日 Scrum。

在本节中，我们将学习以下内容：

• 如何在迭代过程中每日使用 JIRA

• 如何使用看板和燃尽图或小时

• 如何判断迭代是否在进度上

在迭代过程中，我们希望使用 JIRA，并尽量利用这个工具将迭代任务通过工作流推进。我们的看板上有列—待做、进行中、已完成。我们希望用 JIRA 确保我们按计划进行，因为如果我们知道这是一个为期两周的迭代，我们就希望在第二天知道自己是否在进度上，这样我们就能实时做出调整。我们需要能够生成迭代结束时所需的报告数据，而 JIRA 可以自动为我们完成这项工作。我们只需要按照一些日常流程操作。然后，我们将主持每日 Scrum 会议，并帮助 Scrum Master 更好地履行他们的角色。

让我们回到 JIRA。如你所记得，在前一部分中，我们创建了一个叫做 FP Sprint 1 的迭代，已经有了准备工作的队列和其他待办事项。既然该迭代刚刚开始，我们来看一下一个已经进行中的迭代。让我们转到我们的第二个项目。

如下截图所示，我们正处于 SP Sprint 1 的进行中：

我们可以看到 Sprint 中包含的项目。这里有已准备好的 Sprint 项目，以及按优先级排列的其他几个待办事项。当我们进入 Sprint 时，我们将查看活跃的 Sprint 视图，这实际上就是我们的看板视图：

活跃的 Sprint 视图

假设我们正在举行每日 Scrum 会议，并且我们已经将团队召集到一起。我们将能够围绕房间询问团队成员三个我们在每日 Scrum 中要提问的问题：

• 有哪些障碍阻止我们完成 Sprint 承诺？

• 我们是否做了任何会阻止我们的团队或其他团队完成 Sprint 承诺的事情？

• 是否有任何新的依赖关系需要发现，或者是否有办法解决我们在上次每日 Scrum 后发现的依赖关系？

这实际上是我们与团队讨论的三个问题。随着每个人讨论这些问题的答案，并讨论他们遇到的障碍，这些障碍可能会帮助或阻止他们完成 Sprint 承诺，我们会实时更新看板。他们可以在会议前就进行这项操作。

让我们来看一下前面的截图。我们有一个故事，就是 SP-3 故事，可以展开或收起它，下面还有一个子任务。我们可能会有故事，也可能会有子任务的故事。JIRA 会显示最小的工作增量，让我们能够看到它实际上被展示为子任务。在其下方，我们可以看到其他问题，这些问题都是故事级别的，没有子任务。我们可以看到故事编号 3 或 SP-5 已经完成并移至完成列。因此，我们会把子任务移到完成列，当我们这么做时，JIRA 实际上会提示我们，SP-3 下的所有子任务项都完成了，是否也要将 SP-3 项的状态更新为完成？ 我们可以选择“是”：

SP-3 现在已经完成，下面的子任务也已完成。我们将 SP-7 移到进行中，因为我们已经开始了这项工作：

活跃的 Sprint 视图

让我们看一下燃尽图，了解我们是否按计划完成了这个 Sprint。我们将进入报告并查看燃尽图。让我们看看如何读取这个燃尽图：

燃尽图

我们可以在左侧看到我们有故事点数（STORY POINTS），在底部我们有时间（TIME）。这显示给我们的是，在冲刺开始时，我们有 11 个故事点数，我们可以看到，随着我们的推进并更新它们，故事点数减少了。每次我们将一个项目移到“完成”列时，该故事的故事点数会从总故事点数中减去。我们可以看到，前面截图中的灰色线代表理想状态。

在冲刺开始时，我们有 11 个故事点数，冲刺结束时，我们将达到零故事点数，因为所有的任务都完成了。这个故事点数，或者说这个燃尽图，告诉我们的是，在 SP-1（故事点数冲刺 1）时，我们实际上已经提前完成了任务。我们可以看到，部分故事点数已经燃尽，剩下 5 个任务要完成，因此我们实际上在理想线之前。我们将与团队一起审视这个情况。我们会去掉图表，包括燃尽图，并可以说，嘿，团队，看起来我们进展得非常顺利；我们实际上提前完成了任务。我们有很大的机会完成这些项目，到时候我们需要从待办队列中拉取新的工作并添加更多任务。

这就是我们在 JIRA 中进行每日 Scrum 的方式。

更小的故事或任务

在这一部分中，我们将讨论是否应该有更小的故事或任务，或者如何以最有效的方式组织我们的工作以适应团队。

在前面的部分中，我们设置并启动了冲刺，接着我们看到了在每日 Scrum 中如何使用 JIRA。接下来我们将讨论实际的工作内容。我们将讨论如何在 JIRA 中构建工作的最佳方式。我们是否应该为每个人分配一个故事？我们是否应该在一个故事下使用子任务来让事情更具体？

使这件事变得如此具有挑战性，并且我们反复提问的原因是，因为这真的取决于情况。这是一个根据团队不同、工作方式不同而不同的地方，有一些关键点我们需要在构建工作时考虑。实际上，它关乎速度。它关乎在冲刺承诺的时间内交付最多的工作。谈论最快的团队，并思考帮助团队提高速度的概念，可以帮助我们将注意力集中在团队的目标上，而不是个人身上，这也是这件事特别具有挑战性的地方。

我们可以将工作结构化为每个人负责一个故事，但更重要的是确保团队作为一个整体在最佳状态下运作，而不是一群个体。在集体攻克项目中最重要的工作时，团队成员聚集在一起工作，往往会看到最快的速度。无论是 UX、开发、后台开发，还是测试人员，大家共同攻克一个故事，完成后再攻克下一个故事，这实际上是团队最快的工作方式，而不是每个人只做自己分配的任务。通过这种快速高效的协作，我们可以确保承诺保持现实。

我们之前谈到过使用昨天的天气作为 Sprint 中承诺工作量的晴雨表。我们可以承诺更多的工作量，也许我们能完成它，但这实际上关乎团队的动力。如果我们承诺 10 个点，最终完成了 12 个，团队会感到很高兴；但如果他们承诺了 15 个点，却只完成了 12 个，团队会觉得自己做得不够好，这反而会让他们失去动力。我们希望确保团队对他们所做的工作充满动力和热情。如果我们能保持承诺的现实性，这将使团队能够按时完成他们先前承诺的工作，之后再从我们创建的准备工作队列中提取更多的任务。这一点非常重要，因为团队会交付超过 100%的承诺，而团队成员非常喜欢这种感觉。

接下来，我们将讨论相对大小，而不是具体的大小。如果人们承诺说，我们将花八个小时完成这个故事，估计需要八个小时，但实际花了 10 个小时，使用相对大小可以避免我们对这些具体的时间框架负责。如果一个故事有三个点，那么我们就可以将其与 Sprint 中其他故事进行相对大小比较，因此一个三分的故事和另一个三分的故事是相同的。我们不需要知道该项目需要六个半小时还是八个半小时，我们只知道它是三个点。

最后一个概念是关于 T 型人才。这一概念意味着我们可以想象一个人双臂伸展，两边像字母 T。他们在 T 的中间深耕某项技能，而双臂则代表他们可能具备的其他两项技能。我们越是努力让团队具备跨职能能力，就越能提高团队的生产效率。也许那个测试人员也非常擅长处理问题，因此可以为我们提供帮助，甚至充当 Scrum Master。也许我们有一个 UX 设计师，他也能做一些前端编码。这种方式能够在团队攻克一个故事时提高项目的进展速度。

让我们来看一下 JIRA，以及 JIRA 如何支持这些功能。我们将讨论其中的几个概念。回到我们的待办事项中，重要的是要记住，我们之前谈到过，任务板上展示的是最小的工作单位。

如果我们在待办事项中有一个故事，我们会着手处理这个故事。然而，我们真正想做的是为 UX 创建一个任务，为前端开发创建一个任务，为后端开发创建一个任务。我们将有一个人负责整体的故事，然后我们可以创建子任务，允许我将这些任务分别记录在下面。但请记住，这不仅仅是为了个人的最佳利益，而是为了故事和团队的整体利益。

我们已经讨论过，当我们将一个故事移到“完成”状态时，我们会从冲刺中减去那五个故事点，但如果我们希望以小时为单位来跟踪进度，我们也可以这样做。如下面的截图所示，当我们选择任何一项时，会弹出一个对话框；在“显示更多”下，我们可以看到实际上我们也可以进行时间跟踪：

需要注意的是，我们可以这样做。团队应当在相对大小的基础上进行工作。我们可以更有效地进行预测等操作，因为有些团队更倾向于以时间为单位来工作：

如果我们这样做，那么我们可以查看已用时间和剩余时间，然后我们就可以在燃尽图中使用小时数，而不是故事点。在左侧原本显示故事点的位置，我们将改为显示小时数。如果这些小时数是完成我们承诺所需的时间，那么这些小时数将逐渐减少至零，这意味着随着我们完成故事，我们需要更新已用时间和剩余时间。希望这能帮助我们找出最适合我们团队的方式。请尽管尝试；这应该是我们在 JIRA 中处理项目的方式。

关闭冲刺——冲刺报告

在这一部分，我们将讨论如何关闭冲刺。在前面几节中，我们讨论了如何创建和启动冲刺，如何进行每日 Scrum，如何使用 JIRA 来管理我们的每日 Scrum 以及这样做的价值，我们还讨论了如何配置我们的工作，是否应该使用较小的故事，是否需要使用任务？我们应该如何将其拆解到最适合团队的程度？在这一节中，我们将讨论如何关闭冲刺，并学习如何完成一个冲刺。

让我们看看 JIRA。我们正在进行 SP Sprint 1。我们已完成 SP-3 和它下面的子任务。我们已经完成了非常重要的故事 1、3、4 和 6，如以下截图所示。我们可以看到这些都已经完成。然而，故事 5 未完成，这意味着我们没能完成它。也就是说，我们成功将故事 6 拉入 Sprint，并且完成了它。根据以下截图，Sprint 还剩四天，但我们仍然可以继续完成我们的 Sprint：

接下来，我们将点击“完成”按钮，从以下截图中可以看到，五个问题已经完成，一个问题未完成。它提示我并说，我们想把这个未完成的问题放在哪里？我们想把它放回待办事项中，还是想放到准备好的 Sprint 中？我们将把它放回准备好的 Sprint 中，以便将未完成的项目放回准备状态，并完成我们的 Sprint：

在以下截图中，我们看到的是本次 Sprint 的 Sprint 报告：

Sprint 报告

有几点需要注意。首先，我们讨论了这个燃尽图，可以在前面的截图中看到，我们最初有 11 个故事点，并且成功消耗到剩余 1 个。我们在本次 Sprint 中完成了 10 个故事点。我们可以看到已完成的问题，也可以看到这些问题的数量以及完成的故事点数。

然后是 SP-8，这是故事六，如以下截图所示，我们在 Sprint 开始后添加的故事。我们可以看到该问题是在 Sprint 开始后加入的：

我们没有完成问题编号七，SP-7，它是非常重要的故事五，因此我们没有得到这一故事点。

未完成的问题

好消息是，我们在 11 个故事点的承诺下完成了 13 个故事点，坏消息当然是我们没有完成一个故事点。我们确实完成了 13 个，我们的承诺是 11 个，并且交付了超过承诺的部分。希望未完成这一故事点对我们的产品负责人来说是可以接受的。

概要

在本章中，我们学习了如何使用 JIRA 管理我们的项目，如何创建 Sprint，如何引入已细化的待办事项，以便使用符合准备定义的准备好 Sprint。我们确定了 Sprint 承诺的正确大小，参考了昨天的天气。我们还学习了如何启动 Sprint，如何在每日 Scrum 和整个 Sprint 期间使用 JIRA，并通过燃尽图和看板视图来实现这些目标。

我们讨论了如何通过使用 JIRA 工具来最好地帮助 Sprint 成功，介绍了不同的概念来组织工作，以便我们的团队在看板视图中能够高效地推进 Sprint，无论是通过子任务还是较小的故事，最后我们学习了如何完成一个 Sprint。

在下一章中，我们将讨论报告。

第四章：使用报告

在本章中，我们将学习版本和发布的内容——它们是什么以及它们之间的区别。我们还将讨论如何阅读燃尽图、冲刺报告和速度图，以确定团队是否表现良好。我们还将查看发布史诗燃尽图、版本和史诗报告，这些能帮助我们进行预测，这非常强大。

本章将涵盖以下内容：

• 版本和发布

• 燃尽报告

• 冲刺报告

• 速度图

• 发布和史诗燃尽图

• 版本和史诗报告

版本和发布

让我们从版本和发布开始。在本节中，我们将了解版本和发布是什么，以及它们如何相互作用。我们将讨论如何创建和管理这些版本，如何为两个版本分配工作，如何执行发布操作，最后如何查看发布后版本的内容。

当我们谈论版本和发布时，版本来源于软件的概念。我们都熟悉软件的主版本和次版本，例如，版本 2.0 与版本 2.1。它们代表了大量的价值，所以可以这样理解：一个版本代表了正在部署或发布的一部分价值。版本可以被发布，所以一旦我们确定了版本的内容并完成了该版本的开发，我们就可以发布它，这样该版本就变成了发布版本。它们是一样的，只有一个是在部署前，另一个是在部署后。一旦版本被发布，我们就可以查看该版本的内容作为发布说明，所以我们也会查看这个部分。

让我们跳转到 JIRA，查看我们的第二个项目。在待办事项中，我们可以看到有版本。我们实际上可以通过点击这些版本来查看它们：

正如我们在前面的截图中看到的，这是所有机器人版本存储的地方。我们之前提到过，版本是指在发布之前的状态；它们是相同的概念。让我们进入“发布”部分，看看下面的截图：

我们可以从前面的截图中看到，版本名称、开始日期、发布日期和描述都已列出。我们将创建一个版本，命名为测试版本。我们的开始日期和发布日期是可选的，但我们可以在描述中填写测试版本，如下截图所示。然后，我们点击添加：

我们可以查看已发布、未发布和归档的版本。我们还有测试版本。如果需要，我们也可以创建另一个版本。在下方的截图中，我们可以看到我们可以发布、归档等操作：

如果我们回到待办事项列表，可以看到，如果我们点击左侧的版本标签，就如下面的截图所示，我们实际上有了我们的测试版本。我们可以看到问题的数量、已完成、未估算等：

我们实际上可以将两个故事拖入。如果这样做，我们可以在下面的截图中看到这些故事现在是测试版本的一部分：

如果我们再次进入发布部分，我们可以查看版本。我们可以在下面的截图中看到，这个版本中有 2 个问题，这两个问题是我们添加的，并且在已完成的问题数为 0，正在进行的问题数为 0，待办事项中有 2 个问题。完成后，我们可以点击发布，发布这个项目：

我们将返回待办事项列表，并将其他三个故事放入版本中。这意味着我们现在有五个问题。我们会返回发布部分，然后继续发布我们的版本：

如前面的截图所示，我们已经发布了这些项目，我们可以看到正在进行中的项目，也可以看到一些在待办事项列表中。如果我们进入我们的发布说明，就可以看到版本中包含了哪些内容：

发布说明

燃尽图报告

接下来我们要谈论的是燃尽图报告。我们之前花了一些时间讨论了在运行 Sprint 迭代过程中如何使用燃尽图报告，以及如何与团队一起使用它。但在本节中，我们将更具体地讨论报告本身以及如何读取报告，然后讨论我们可以为燃尽图报告使用哪些数据。

正如我们已经知道的，燃尽图用于衡量迭代中的进展，并帮助我们理解我们是否在理想状态下按计划进行。在燃尽图中，纵轴表示该迭代中存在的工作总量，横轴表示时间。

燃尽图讲述了故事。我们越是查看它们，就越能理解迭代过程中可能发生或没有发生的事情，通过查看这些燃尽图，我们能相当擅长讲述故事。在燃尽图中，我们可以燃尽各种内容，我们可以燃尽点数，我们可以燃尽小时数，我们可以燃尽风险，还有其他内容。

燃尽图示例 1

现在我们来看一下如何在 JIRA 中设置这些内容。让我们先看这个第一个示例：

燃尽图示例 1

首先，我们可以看到纵轴上标注的是故事点（STORY POINTS）。在这个迭代中，我们在本次 Sprint 开始时有大约 36 个故事点。我们可以看到，最终我们希望将故事点燃尽为零，因此理想情况下，我们会处理本次迭代中所有承诺的工作。底部显示的是时间（TIME）。如图所示，这是一个为期两周的 Sprint，随着时间的推移，我们燃尽的任务使得故事点数减少到零。灰色线代表理想（Ideal）情况，因此假设工作进展顺利，我们希望接近这条灰色线，这样可以显示我们期望的模式。前面图表中的灰色条形图则代表周末，即团队没有工作的时间，因此我们看到它们是平的，因为理想情况下我们周末不工作。我们还可以看到右上角有一个蓝色复选框，显示的是显示非工作日（Show Non-Working Days）。如果我们不想查看周末，可以取消勾选，去掉周末的显示。

燃尽示例 2

我们将讨论燃尽图如何讲述 Sprint 的故事。让我们来看一下以下的燃尽示例：

燃尽示例 2

我们要特别留意的事情之一是，如图所示，在本次 Sprint 的开始时，我们从 25 个故事点开始，最终并没有燃尽到零。如前面截图所示，有一个红色的小峰值，这个峰值是由于 Sprint 开始后又增加了工作量。

燃尽报告

让我们来看一下 JIRA——我们想要查看几个方面。首先，获取燃尽图的方法是进入报告（Reports）。燃尽图是我们首先会看到的项目，这里就是我们可以查看燃尽图的地方：

所有报告

我们接下来想讨论的是燃尽其他值。如果我们回到右上角的待办事项列表（Backlog），可以看到我们的看板设置（Board settings），点击它后，在设置（SETTINGS）中我们会看到估算（Estimation）：

在前面的截图中，我们是以故事点为单位进行估算的，但我们也有能力按原始时间进行估算。然后，我们可以使用时间跟踪，这样我们在纵轴上看到的就不是故事点，而是小时数，因此我们可以燃尽小时数。当我们在 Sprint 中推进时，假设某个任务的初始时间为 10 小时，我们可以将该值更新为例如 8 小时或 6 小时，它将随着 Sprint 的进行而减少相应的小时数。

Sprint 报告

在这一部分，我们将讨论 Sprint 报告。我们会讲解它是什么，以及如何解读它。在 Sprint 报告中，会有 Sprint 迭代的总结。它会展示我们的燃尽图、已完成的工作、未完成的工作，以及在迭代过程中新增和移除的任务。

让我们来看一下 JIRA，获取更多 Sprint 报告的信息。还记得我们使用的演示项目吗？要进入报告，我们可以点击左侧的 Reports，然后查看我们的 Sprint 报告：

Sprint 报告

请记住，我们的燃尽图不会很完美，因为这是一个为期一天的 Sprint。通常，燃尽图会根据我们 Sprint 的迭代长度更为合适。但让我们关注底部。正如前面截图所示，我们有已完成的事项（在此 Sprint 中完成的任务）。如果我们查看在 Sprint 开始后新增的任务，会注意到它们旁边有一个星号，这样我们就可以看到那些不属于原始承诺的任务。我们还可以看到未完成的任务，因此 SP-7 在本次 Sprint 中没有完成。我们还可以看到从 Sprint 中移除的任务。总的来说，我们有已完成的任务、有新增的任务、有移除的任务，以及任何未完成的任务。当然，我们还可以看到 Sprint 的名称以及该 Sprint 的日期范围。

速度图

在这一部分，我们将讨论速度图。速度图非常有价值。首先，我们会讲解它是什么，如何解读它，然后我们将讨论如何利用我们过去的速度来规划未来的承诺。

速度图示例

让我们来看一个速度图的例子：

速度图

为了让我们理解前面的图表，我们来看看不同的元素。灰色的条形表示我们在 Sprint 中承诺的内容，可以看到这是以故事点（Story Points）为单位来衡量的。在这个例子中，我们可以看到在Sprint 3中，我们实际承诺了25个故事点。绿色的条形表示团队实际完成的工作，因此我们完成了25个故事点，达成了100%的承诺。这太棒了！我们还可以看到一些例子，其中灰色条形低于绿色条形，这意味着我们承诺了某些任务，但实际上完成的比承诺的还要多，这更好。

如果我们看第 5 个冲刺，它没有承诺，因此可能存在某种数据问题，或者没有承诺而冲刺在没有承诺的情况下开始，这意味着在冲刺工作在迭代开始后添加时，我们可能会看到一个燃起图。我们已经谈过报告讲述一个故事；这个报告讲述了一个不同的故事，这很有趣。我们可以看到我们的速度实际上在下降，这无疑会引起警觉，如果我们在查看这个报告时，这将是需要和我们的 Scrum Master 或团队讨论的事情。了解正在发生的事情并利用此来获取项目的相关信息是非常重要的。这是速度图。

发布和史诗燃尽图

在本节中，我们将讨论发布和史诗燃尽图，它们的重要性，以及我们如何使用它们来深入了解事情的进展。我们将了解发布和史诗燃尽图是什么，如何阅读这些燃尽报告，以及如何使用这些报告进行预测。

发布燃尽图示例

我们将展示一个发布燃尽图的示例。

请记住，它发布的是一个版本。本质上，它是一个已经部署的版本。一个史诗也是一个工作容器。

回顾我们的待办事项。发布通常比史诗大，因此一个史诗是一个跨越多个冲刺的大故事，但相同的概念适用，所以当我们查看史诗燃尽图报告时，它将与发布燃尽图报告相同，但可能会更小。然而，它将帮助我们预测这个史诗可能完成的时间。

让我们来看一下这个发布燃尽图。我们希望熟悉报告中的不同元素：

发布燃尽图示例

首先，我们在第一列中看到的是我们对该版本中包含的工作的估算，这最终将成为我们的发布版本。我们可以看到它有184个点。这个报告中有趣的地方在于，在这个具体的示例中，我们有28%的工作是未估算的，这意味着它是隐藏的。报告中有20%的问题没有故事点估算，这意味着我们的原始范围实际上大于184，但我们没有对这些工作进行大小估算，因此确保所有工作都被估算并包含在我们的预测中是非常重要的。如前所述，184个点代表了我们的原始范围，因此那个中蓝色的条形图代表了在创建版本时的原始范围。前面的深蓝色部分，再加上32个点来自Sprint 2，代表了新的范围。这是本次迭代中新增的工作，现在是该发布的一部分。我们可以看到绿色的条形图代表了已完成的工作，因此在Sprint 2中，我们完成了原始范围中的46个点，并新增了32个点。我们仍然剩下128个原始范围的点。根据这一点，我们可以看到我们开始建立一个速度指标。我们知道该团队的速度是每个 Sprint45个点，基于此，我们可以看到虚线和当前所在的位置。我们知道我们在该版本的范围内还有50个故事点剩余。这告诉我们，我们大约还有一个 Sprint 的工作量，基本上剩下两个 Sprint。如果每个 Sprint 是两周的话，那么我们可以看到在这个版本可以发布之前，我们大约还有一个月的时间，这让我们能够进行预测。

版本和史诗报告

在本节关于报告的内容中，我们将讨论版本报告和史诗报告。在前一节中，我们讨论了发布和史诗燃尽图，而在本节报告中我们将获得类似的视角，但它有所不同，包含稍有不同的信息。在这一节中，我们将了解版本报告和史诗报告是什么。再次强调，它们非常相似。

版本报告是较大的，包含更多的价值，而史诗（epic）则较小。它基本上是相同类型的报告，但它允许我们查看特定的版本或特定的史诗，然后我们可以获得某种预测，了解该项目何时完成。我们将学习如何阅读版本报告，并且还会学习如何利用这些报告进行预测。

版本报告示例

我们将看一个版本报告的示例，如下所示：

版本报告

如前图所示，我们可以看到纵轴上表示的是故事点（STORY POINTS）。从报告中可以看到，实际有相当多的故事点，因为通常一个版本会有很多功能。我们还可以看到横轴表示的是时间（TIME）。报告中有一条红线，表示未估算的工作量，随着版本的进展它会上下波动。我们可以从蓝线上看到，这个版本从一月开始，看到今天的日期（由虚线表示），同时还可以看到预计的完成日期。值得注意的是，完成日期呈锥形分布，乐观日期位于预计完成日期的左侧，而悲观日期则位于其右侧。

我们实际上有一个乐观和悲观的发布日期，基于团队的实际速度和该版本中包含的工作来预测。这个值实际上是动态生成的，随着时间的推移不断更新。如果我们从这个版本中移除一些范围，它会把日期提前，实际交付时间会更早；如果团队的进度放缓，或者我们增加了更多的工作范围，那么发布日期就会推迟。随着我们越来越接近实际的发布日期（预计完成日期），这个范围会变得越来越窄，直到完全没有范围可言。当我们在二月或三月刚开始时，由于有很多变量可能影响完成日期，我们的预测范围会更宽一些。这让我们能够有用地观察这个版本的进展，并推测完成日期会是什么样子，同时做出一些提前的决策，从而影响进度。比如，我们是否应该将团队聚集到一个房间里，是否需要增加更多人员或资源，是否需要改变工作范围等等，我们有很多选择，前提是我们对未来的进展有清晰的认识。

总结

本章结束了。在本章中，我们了解了版本和发布的概念，了解了迭代发布的史诗燃尽报告以及如何阅读它们，了解了冲刺报告的内容以及如何解读，了解了速度报告是什么以及为什么它对未来冲刺的规划至关重要，还讨论了版本和史诗报告并使用它们来预测版本完成的时间。

在下一章中，我们将讨论如何进行搜索和过滤。

第五章：在问题上进行搜索和筛选

在本章中，我们将讨论在 JIRA 中进行问题搜索和筛选，这是一项非常强大的功能。

我们还将讨论 JQL，它是什么，如何使用简单和高级编辑器在 JIRA 中编写查询，以及如何导出 WER 结果。

在本章中，我们将覆盖以下主题：

• 使用 JQL 进行问题搜索

• 保存和管理筛选器

• 执行批量更改

• 从保存的筛选器创建新看板

使用 JQL 进行问题搜索

在本节中，我们将讨论使用 JQL 进行问题搜索。我们将讲解 JQL 是什么，如何在简单编辑器和高级编辑器中编写查询以返回结果，以及如何将这些结果导出以便用于其他方式。

首先，我们来谈谈 JQL。我们不想把它与 Java 查询语言混淆，后者是另一回事——我们要关注的是JIRA 查询语言。它的格式与 SQL 非常相似，因此如果我们曾经使用过 SQL 并理解其查询语法，我们会在 JQL 中感到非常舒适。它使用字段、值、运算符和关键字。接下来我们来讨论这些内容。

字段本身是系统中包含的不同类型的信息；这些是工作类型等的不同属性。值实际上是这些字段中包含的内容，因此它们是我们要查找的实际值。运算符基本上是查询的核心——它们是智能部分——例如等于、不等于、小于、大于等，我们可以用它们在字段和值之间创建智能查询。然后，我们有关键字，这些是我们在查询语言中使用的保留字，用来将这些不同的运算符连接在一起。

这里有一个链接，指向 Atlassian 网站上的一篇文章，深入讲解了如何搜索 JIRA：confluence.atlassian.com/jiracore/blog/2015/07/search-jira-like-a-boss-with-jql。

JIRA 中的简单和高级 JQL 编辑器

让我们来看看 JIRA 中的简单和高级 JQL 编辑器。

在我们的 JIRA 实例中，有两个项目，分别是第一个项目和第二个项目。我们要做的是对这些项目运行一些查询。请点击左上角的问题链接：

包含 WER 项目的仪表盘

我们搜索的默认屏幕基本上是我们能够做的最通用的查询，实际上我们是在高级编辑器中。让我们切换到屏幕右上角的基本编辑器：

正如在前面的截图中所示，它将提供下拉菜单，允许我们构建查询。我们知道可以选择这些项目。例如，如果我们只想查看第一个项目，或者只查看第二个项目，在这样操作时，我们可以看到下面的结果发生变化。我们还可以选择要查看的缺陷类型、要查看的状态、缺陷的负责人等。这是基本编辑器，我们只需点击并搜索缺陷，即可运行查询。

如果我们进入高级编辑器，我们可以看到可以查找一些特定的内容：

我最喜欢的查询之一涉及打开的冲刺：

在这里，我们可以说，显示我 FP-1 项目中的所有开放冲刺。我们可以看到它实际上为我们编写了一个查询，这使得我们更容易运行它。我们可以说第一个项目，问题类型等于 Story，然后我们想要搜索它。我们可以看到它是如何工作的；我们可以使用高级编辑器来编写我们的查询。

我们还有一个已经编写的查询，如下图所示。这是第一个项目的查询，问题类型是 Story，查询内容是显示所有在开放冲刺中的内容，并按创建日期降序排序：

返回的结果是两个故事。这是目前在第一个项目中并且处于开放冲刺中的两个故事。

在本节中，我们看了如何在基本查询编辑器和高级查询编辑器中编写查询，还为打开的冲刺提供了一个非常有用的表格。

保存和管理筛选器

在本节中，我们将讨论如何保存和管理筛选器。这意味着我们将学习如何保存创建的筛选器，如何设置保存筛选器的权限，以及如何查看和管理所有保存的筛选器。

让我们继续前往 JIRA，看看我们的缺陷搜索界面。我们有一个查询，所以让我们切换到基本编辑器并说显示我第二个项目中的所有内容。保存这个筛选器非常简单，我们只需要点击“另存为”，然后会跳转到以下屏幕，写上Second Project Work Items作为我们的筛选器名称：

保存筛选器对话框

如果我们点击提交，现在我们已经有了一个保存的筛选器。我们所做的是将查询转化为筛选器，并保存它，这样我们就可以反复运行它。如果我们在左侧的“管理筛选器”下查看，我们可以看到刚刚保存的筛选器——第二项目工作项：

我们还可以看到，右侧有三个省略号，提供了如“管理订阅”、“复制过滤器”和“编辑过滤器详细信息”等选项，我们甚至可以点击“共享给”查看这些内容是与谁共享的。如果我们点击“第二项目工作项”，将看到该查询的内容。我们还可以点击“高级”，查看我们使用的查询语言：

第二项目工作项

在前面截图的右上角，我们可以看到可以通过提供链接、插入 JIRA 中某个人的用户名或电子邮件来共享该项内容，然后我们可以添加备注并点击“共享”。我们还可以查看我们创建的项目的详细信息：

这允许我们设置权限和订阅，并查看谁应该拥有访问权限，能够查看此过滤器的内容。我们可以看到，我们有能力与一个组、特定项目、任何登录用户共享，或者直接公开共享。这就是我们如何保存和管理查询并将其转换为过滤器。

执行批量更改

在这一部分，我们将讨论如何执行批量更改。当我们需要对许多项目进行大量更改时，这种方法非常有效，尤其是当我们不想逐一进行这些更改时。我们通过找出是否有某种模式或方法，能够对多个项目进行更改，从而执行所谓的批量更改。我们将学习如何使用过滤器的结果来执行批量更改。

让我们回到 JIRA，查看我们的一些过滤器，如下图所示。在我们的“第一个项目开放冲刺工作项”过滤器中，我们可以看到它显示的是项目 FP1，并且，如果问题类型是故事，我们将查看我们的开放冲刺并按创建日期降序排列返回所有内容。它返回了两个故事，FP1-24 和 FP1-25。

我们还希望将这两个故事转换为任务。最好的方法是进行批量更改，所以我们继续操作。我们将前往右上角的省略号，点击“批量更改所有 2 个问题”：

执行批量更改

这将带我们进入以下屏幕：

批量操作

我们将选择要更改的每个问题，在这种情况下，我们只需选择第一个，它将自动勾选所有问题，接着我们可以点击“下一步”。这将带我们进入以下屏幕：

我们将选择要执行的操作。我们想编辑这些问题，但我们也可以将它们从一个项目移到另一个项目，过渡到工作流等。我们点击“编辑问题”，然后点击“下一步”，接着我们将把问题类型更改为任务：

正如我们在前面的截图中看到的，我们还可以更改许多其他条目。我们点击下一步，然后可以点击确认，如以下截图所示：

它将自动为我们执行该更改，如下所示：

在它运行时，我们让它运行一会儿，等它完成后，我们可以点击确认。如果我们回到这个项目问题类型故事的查询，我们将没有结果：

如果我们将故事更改为任务并再次运行此查询，我们可以看到这些条目现在已经从故事更改为任务：

运行查询

这就是我们如何执行批量更改。

从保存的筛选器创建新看板

在这一部分，我们将讨论如何从保存的筛选器中创建新的看板。在这里，我们将使用一个保存的筛选器来创建一个新的 JIRA 看板。在之前的部分中，我们谈到了 JQL 是什么，如何从查询创建筛选器，以及批量更改，现在我们将使用这些相同的筛选器来创建一个 JIRA 看板。实际上，JIRA 中有很多强大的功能。

正如我们在下图中看到的，我们有一个查询。我们实际上已经将这个查询保存为一个筛选器。让我们来看一下这个查询的作用：

保存的筛选器

正如我们在前面的截图中看到的，它基本上返回了第一个项目和第二个项目中的所有条目，并按创建日期降序排列。这很简单；它基本上是在说，展示这两个项目中的所有工作项。

让我们用这个来创建一个新的看板。假设我们想把这两个项目合并成一个更大的计划，并且我们想创建一个看板来在单一看板视图中查看所有内容。我们现在要做的是转到搜索界面，进入最近的看板。我们可以在以下截图中看到我们有一个查看所有看板选项：

我们可能记得，当我们创建一个新项目时，系统会自动创建一个看板。这里，我们可以看到我们已经有了两个看板；我们有第一个项目和第二个项目的看板，如下所示：

现在我们要创建一个新项目，所以如果我们去右上角，我们可以看到有一个创建看板选项，我们点击它。接下来会弹出一个提示，给我们一些关于要创建哪种看板的选择：

第一个是敏捷看板，这是 JIRA 创建的看板，用于以更简化的方式查看项目内容。我们已经有了带有看板的项目，因此我们尝试从查询中创建看板。我们还可以看到有一个 Scrum 看板，它会包含像迭代等内容。我们的目标是将两个项目的所有内容整合到一个看板视图中。Kanban 看板是我们在这种情况下希望使用的。Kanban 主要是将工作项及有限数量的工作项通过工作流推进，每一列代表一个工作流。让我们创建一个 Kanban 看板。我们可以在以下截图中看到，我们有更多的选项，例如，我们是想创建一个新的软件项目、一个现有项目，还是从现有的保存筛选器创建一个看板？

让我们通过点击“从现有保存的筛选器中选择看板”并点击“下一步”来创建一个看板。我们将这个看板命名为所有项目，并使用“第一个”和“第二个项目”的保存筛选器。我们现在不会分享它，但我们将把我设置为所有者，然后，作为位置，我们可以将其保存为第一个或第二个项目下的另一个看板，或者直接将其附加到我们的个人资料中，如下图所示：

让我们继续创建看板。我们可以看到我们有一个包含三列的看板，分别是“待办”、“进行中”和“已完成”，以及两个项目的所有内容：

我们可以在前面的截图中看到，这显示了第一个和第二个项目的所有内容现在都包含在这个看板中，并且我们正在这个工作流中操作。如果你觉得这个过程很简单，那么我们现在将看几个选项，让我们能够将这两个项目合并在一起。

总结

在这一章中，我们了解了什么是 JIRA 查询语言，也就是 JQL——这不是 Java 查询语言，而是 JIRA 查询语言。我们学习了如何使用 JQL 编写简单和高级查询，如何导出查询结果，如何保存查询并将其转换为筛选器。最后，我们学习了如何使用这些保存的筛选器执行批量更改，并学习了如何使用保存的筛选器创建新的 JIRA 看板。

在我们接下来的最后一章中，我们将讨论仪表板和小部件。

第六章：仪表板和小工具

在本章中，我们将讨论 JIRA 中的仪表板和小工具。我们将介绍如何创建和管理仪表板、如何向仪表板添加小工具以及如何共享仪表板。

仪表板的作用是广播项目进展情况，并能够在高级别上分享，确保项目结果的可见性和透明度。

在本章中，我们将涵盖以下主题：

• 创建和管理仪表板

• 向仪表板添加小工具

• 共享我们的仪表板

创建和管理仪表板

在这一节中，我们将讨论如何创建和管理仪表板。我们将学习什么是仪表板以及如何创建仪表板。

让我们跳转到 JIRA，查看一些仪表板。

在我们的项目中，我们有第一个项目和第二个项目，在左侧，我们可以看到仪表板。JIRA 默认会提供一个系统仪表板，我们可以在以下截图中查看它：

系统仪表板

我们看到的是一个活动流和其他标签页，但我们要做的是创建自己的仪表板。因此，在右上角点击“创建仪表板”。我们将看到一些选项，在这里可以命名仪表板为我的伟大仪表板，并为其添加描述所有美好的事物。我们可以从空白仪表板、系统仪表板或现有仪表板开始。我们有一个收藏列表，如果有多个仪表板时，可以将这个仪表板标记为收藏。我们还可以选择共享选项，其中包括项目、任何登录用户或公开共享。然而，目前我们就保留默认设置：

如下截图所示，我们已经创建了仪表板，在这里我们可以添加新的小工具：

但在当前时刻，更重要的是，让我们来看一下布局：

从上面的截图中我们可以看到，我们可以有一个页面，类似于一个大块区域，其中可以包含多个列：我们可以有一列小列和一列大列，也可以是相反的排列，或者我们可以有三列；选择权在我们自己。这一切取决于我们的选择。我们现在保持默认设置，但我们认为了解这些选项非常重要，这样当我们开始将这些小工具组合起来时，就能分享一个视觉上令人愉悦的仪表板。这就是我们如何创建仪表板。

向仪表板添加小工具

在这一节中，我们将讨论如何向仪表板添加小工具。我们将学习如何将过滤器结果小工具添加到仪表板中、饼图小工具以及二维过滤器统计信息。实际上，小工具有很多很多种。

现在让我们开始添加一些小工具。返回到 JIRA；记得我们之前在上一节中创建了我的伟大仪表板。

关于小工具，有些事情我们需要知道。首先，它们有很多种，所以 JIRA 预先加载了相当多的小工具。此外，当我们查看 Atlassian 市场时，我们发现那里有大约 95 个不同的小工具，可以加载到我们的仪表盘中。那里甚至有一个小工具可以帮助我们在创建自己的小工具时使用，所以除了这些，我们还可以做很多事情，比如报告。这意味着我们可以极大地扩展仪表盘，用来可视化各种不同的内容。

让我们来看看我们想要添加的小工具。在我们的仪表盘上，我们有两栏布局，因此让我们点击添加一个新的小工具。这将带我们进入下一个屏幕：

添加小工具

今天我们要讨论的第一个是用来过滤结果的。我们可以看到左侧有很多不同的内容可供选择；我们有墙板、JIRA、图表、小工具等等。我们将寻找过滤结果，因此我们将通过filter进行搜索。现在，添加小工具：

添加小工具

我们还将寻找饼图，因此我们输入pie，并从结果中添加以下小工具：

接着我们还将获取二维过滤器统计信息小工具，让我们来看看这个：

添加二维过滤器统计信息小工具

这些是我们要查看的三个小工具，正如我们所看到的，我们可以将它们不断添加到我们的仪表盘中。我们要做的第一件事是给它添加一个过滤器，它将是二维过滤器，我们希望说，我们想查看第一个和第二个项目的内容。还记得上一节的过滤器吗？这将显示我们第一个和第二个项目的所有内容。在我们的 X 轴上，我们希望将状态作为水平轴，因此这将显示所有工作项的状态，而在 Y 轴上，我们希望显示分配人。我们可以更改排序、排序方向、结果数量等等。我们甚至可以设置每 15 分钟更新一次，如果我们想的话。现在我们先保持这些为默认设置，然后点击保存：

我们将看到的是第一个和第二个项目的内容。在这里，我们可以看到分配人或未分配的项目，进行中的项目有多少，待办的项目有多少，已完成的有多少，我们还会看到总数。另一个有趣的事情是，我们实际上可以点击链接，这会带我们去搜索这些问题，并显示出 18 个已完成的项目。如果我们有一个大团队，这是一种非常好的方式来查看每个人的任务及其状态。这就是为什么我们可以经常使用这个：

让我们来看看饼图。我们在这里也可以做相同的事情：我们可以查看一些过滤器和我们拥有的项目：

让我们看看我们拥有的内容。我们将查看第一个项目，并将统计类型保持为状态。点击保存，我们可以看到现在有一个饼图：

这张图表展示了已完成的工作和待完成的工作。例如，如果我们有一个大团队，我们可以查看每个人有多少工作项，或者他们的工作项状态如何，或者其他任何事情，但我们将能够通过饼图来可视化这些内容。

接下来，我们将看看我们最喜欢的筛选器。我们选择一个筛选器。我们可以选择我们已有的开放 Sprint 工作项选项。再次，我们将使用已经开放的第一个项目工作项。在这里，我们最多可以显示 10 个结果；这里有展示的列，我们可以配置或删除它们。我们继续保存：

我们继续进入编辑模式。在这里，我们可以查看第二个项目板。我们可以选择一个筛选器，然后显示该筛选器的内容，如下所示：

我们可以看到内容，因为我们选择了 10 个项目，我们仅看到 10 个中的 12 个，但我们也可以将其设置为任意数量，并配置显示哪些列。

我们可以在仪表板上使用这三个小部件示例，但我们可以选择许多其他不同的小部件。在接下来的部分，我们将讨论如何共享我们的仪表板。

共享仪表板

在本部分中，我们将学习如何共享我们的仪表板。记住，仪表板本身以及其背后的整个概念是关于广播结果并使工作成果变得可见和透明，这正是我们想要做的：确保每个人都能访问这些信息。

让我们跳转到 JIRA，查看仪表板的共享设置。在上一部分中，我们创建了一个迁移的仪表板，并给它添加了可以在以下截图中看到的内容。我们希望共享它，以便每个人都能看到它。点击右上角的省略号，点击它并选择共享仪表板：

我们还有许多其他选项，但在这里，我们将关注共享。我们可以看到，当初设置时我们所拥有的设置：

我们可以选择谁可以查看该仪表板，我们甚至可以将其设为公开。我们可以看到该页面显示，共享给公众将使每个人都能看到，包括那些未登录的用户。如果我们希望我们的客户或某些人能够查看该仪表板，这是一个不错的选项，我们也可以点击更新并以这种方式与他们共享。否则，我们可以选择项目中的任何人，然后选择哪个项目等等。这基本上就是我们如何共享仪表板。

摘要

在本章中，我们讨论了如何创建仪表板，如何使用我们在前面章节中创建的筛选器将小工具添加到仪表板中，以及如何与他人共享仪表板并使这些结果透明可见。

这带我们来到了我们与 JIRA 一起度过的时光的尾声。