目录

1. 创建Project(项目)

1.1 选择Project的类型

1.2 填写项目名、关键词、项目负责人

2. 界面布局

2.1 顶部导航栏

2.2 左侧导航栏

2.3 中央操作界面

3. 添加项目成员

3.1 在系统中增加用户

3.2 在项目中添加成员

4. Issue的使用

4.1 Issue的基本类型

4.2 创建Issue

4.3 查看Issue

4.4 修改Issue

4.4.1 在Issues界面中修改 

4.4.2 在Backlog界面中修改

4.5 删除Issue

4.6 复制Issue

4.7 将Issue分配给经办人

5. 开始一个完整Scrum软件开发项目

5.1 Scrum敏捷开发的主要流程和活动

5.2 记录需求(构建Backlog)

5.2.1 创建Scrum项目

5.2.2 创建Story

5.2.3 使用Story Point

5.3 制订版本计划 (构建Backlog)

5.4 冲刺(Sprint迭代)

5.4.1 创建Sprint

5.4.2 工作量估算与子任务

5.4.3 启动 Sprint 并查看

5.4.4 执行Sprint

5.5 评审(Sprint Review)

5.6 回顾复盘(Sprint Retrospective)

5.7 发布版本(Release Version)

6. 总结


1. 创建Project(项目)

1.1 选择Project的类型

Jira提供了预制的项目模板,主要分为Software和Business两大类,在创建项目时可以根据项目需求选择对应的类型。

本文以Scrum软件开发模板为例:

Tips:可自行向AI咨询Scrum开发方法含义

1.2 填写项目名、关键词、项目负责人

        项目名用来简单描述该项目的内容,关键词相当于项目的简称,便于在项目管理时用来指代该项目,填写项目名后会自动生成关键词(如果内容是英文的话),也可自己定义关键词,必须全为大写字母。

填写完毕后点击Submit提交。

进入该页面表示创建成功:

2. 界面布局

        Jira软件界面主要分为3个部分:顶部导航栏、左侧导航栏、中央操作界面。

2.1 顶部导航栏

        顶部导航栏主要是一些全局功能,即当前项目外的一些设置与功能,如创建项目、切换项目、Jira软件设置、软件帮助等。

2.2 左侧导航栏

        左侧导航栏主要是当前项目的功能,可以展开显示:

          

2.3 中央操作界面

        空间最大的地方是各个功能的操作界面,比如当前的Backlog界面,就是当前项目的代办列表,也就是所有未完成的任务都被记录在这(back+log)。

3. 添加项目成员

        创建好项目后需要给项目添加成员才能让同一个项目的成员互相协作,项目成员必须是Jira系统的用户,如果还不是用户则需要先创建用户(user)。

3.1 在系统中增加用户

找到顶部导航栏右侧的齿轮图标,在菜单中找到User management(用户管理)

填写管理员密码:

这里会显示当前Jira系统中的所有用户(user),目前只有我自己(我是本地的Jira系统)。

点击右上角Create user(创建用户)

填写信息创建一个新用户

创建成功会显示新的用户信息

3.2 在项目中添加成员

先在顶部导航栏Projects(项目)按钮菜单中选择我们的项目,回到项目界面。

然后在左侧导航栏中点击Project settings(项目设置)

也可以不展开直接点齿轮图标

中央操作界面的左侧目录,向下滑,找到Users and roles(用户与角色)

user是这个Jira系统的用户,role是这个项目中的成员

The user has a role in the project.(用户在项目中是某种角色,比如项目负责人、程序员等)

点击Add users to a role,添加一些系统用户到项目中对应的角色。

官方翻译:为角色添加用户。我觉得有点奇怪,能用英文原版最好。

填写用户名(user name)或真名(full name)查找目标用户(user)

选择一个角色,这里目前只能选管理员

可以看到新添加的role

4. Issue的使用

        Issue可以翻译为工单 / 事项 / 问题,最好能直接理解Issue的含义,我暂时没有看到特别贴切的翻译。(issue,首字母是i,这里大写i和小写L长得一样,我真服了Il)

        Issue是Jira的核心功能,Issue是信息管理的基本单位,本质上我们在软件里管理的是不同类型的Issue。

4.1 Issue的基本类型

Jira默认的Issue类型有5种:EpicStoryTaskBugSub-task

这5种类型的层级关系大致如下:

想要深入了解这5种Issue类型的相关知识可以自行询问AI。

下图为AI生成,不一定百分百正确,大家最好自己去好好学习一下这5种类型的关系

比如:Story和Task为平级关系,Story下不可在分Task

同一个问题不同时间问AI可能会有不同答案(我感觉AI就是在“哄”用户😂),大家自行甄别吧

4.2 创建Issue

点击顶部导航栏中的Create(新建)

以新用户注册为例,填写信息:

Issue归属于哪个Project、Issue类型、总结概要、报告人

附件、具体描述、相关的其它Issue

经办人、优先级、标签、相关的Epic、归属的Sprint

有*号的为必填项,其它选项可以空着或者保持默认

点击Create创建当前设置的Issue,如果想要连续创建可以勾选Create another

刚刚我们创建了一个“新用户注册”,再创建一个“新用户登录”,并让这两个Issue互相“阻塞”。

填写信息:

由于我们刚刚已经创建了一个“新用户注册”的Issue,所以在创建第二个Issue时,可以在Create阶段就设置好相关的Issue以及两者的关系:

必须先“注册”再“登录”。也就是说注册会挡登录的道。

“注册” blocks “登录”,“登录” is blocked by “注册”

想象一下,你去某个机构办理业务,你想要登录,但是工作人员要你先注册:

剩下的保持默认,点击Create,不需要继续创建Issue可以取消勾选“创建另一个”。

4.3 查看Issue

点击左侧导航栏中的Issues

可以看到我们刚刚新建的2个Issue:

4.4 修改Issue

        刚刚我们在“登录”中设置了与“注册”的阻塞关系,但是在“注册”中没有设置(因为那个时候还没有登录这个Issue)

4.4.1 在Issues界面中修改 

可以点击Edit(编辑)按钮,或者在选中对应Issue的情况下,按下“E”快速打开编辑界面。

其实之前我们设置“登录” is blocked by “注册”时,系统会隐式的帮我们设置好两者的正确关系,但是这里为了学习如何修改Issue,我们还是手动显式设置一下“注册” blocks “登录”

修改好后点击右下角Update(更新)。

在英语语境中,数据相关领域,常说修改的意思应该就是update,强调是新的内容,而不强调改了某些东西,所以不用modify。

可以自己查看一些更新后的两个Issue

4.4.2 在Backlog界面中修改

也可以在Backlog中点击对应Issue进行快速修改

有铅笔✏️图标的都可以修改

4.5 删除Issue

点击右上角三个点,可以打开更多菜单,进行更多操作,比如编辑、删除等

删除操作在Issues界面无法进行,得在Backlog界面完成。

4.6 复制Issue

点击More Actions...,可以在下拉菜单中找到Clone,或者直接在输入框中输入想要执行的操作名,快速查找。

可以看到我们复制(克隆)的新问题。

在英语里把1个对象一模一样的变成2个,叫做Clone(克隆),而Copy(复制/拷贝)表示的是把1个对象“抄”一份模板,每次使用的时候可以用这个模板Paste(粘贴)。

其实复制应该是Duplicate(和克隆类似,把1个文件变成2份),拷贝是Copy,克隆是Clone(克隆更强调的是一个有很多属性的复杂的对象,而不是单一的文件)。

但是中文语境里已经把这些概念全部搅在一起了,Windows系统里只有复制,所以苹果系统里的拷贝和复制才会让大家一头雾水,其实Windows系统里的复制是Copy,对应苹果系统的拷贝。

Jira中的很多翻译我也是看的一头雾水 😂

4.7 将Issue分配给经办人

        如果多个Issue的处理流程需要多人协作,那么就要将不同的Issue合理的分配给对应的经办人处理。

例如,在软件开发中测试部门与开发部门常见的协作流程:

1)测试人员创建一个“Bug”(类型的Issue),将其分配给开发人员修复。

2)开发人员修复后,把这个“Bug”(类型的Issue)分配给测试人员。

3)测试人员重新测试,测试通过后,关闭这个“Bug”(类型的Issue)。

假设我是测试人员,我之前添加到这个项目的另一个role是开发人员。

我先创建一个“Bug”类型的Issue(参考上文创建Issue部分的内容)

设置优先级

把这个Issue分配给其它role

创建成功后可以看到这个新Issue和它的信息。

Reporter(汇报人)也就是创建这个Issue的人,相当于测试人员发现了这个Issue并汇报,Assignee(经办人)也就是被Reporter分配来解决这个Issue的人,在许多地方会显示对应role的头像,所以头像最好特别一点,能够一一对应到具体的人员,以免管理出现差错。

在Jira中,每个Project中的Issue并不会根据优先级自动排序,也没有这个按钮。(大概是因为相同优先级的不同Issue可能有不同的“优先级”,比如吃饭和喝水优先级相同,但你可能更想先喝口水润一润😄)。

所以项目管理人,需要根据项目优先级和实际情况,在Backlog界面中手动拖拽排序。

如果我(测试人员)分配完以后发现我分配的开发人员今天请假了,那么可以重新分配给其它role,或者暂时先分配给自己。

Assign在编程中还有赋值的意思,即给变量分配某个值,在Jira中可以理解为给某个role分配某个Issue。

可以看到重新分配后,Issue旁边经办人的头像变成了我自己的头像:

注意:当一个Issue被解决后,应该是关闭而不是删除

当你尝试delete某个Issue时你会看到提示:

比如可以在More actions...中选择Done操作

可以看到虽然Backlog中已经没有了刚刚新建的“Bug”,但是它显示的是updated而不是deleted。

可以在Issue界面找到已经Done的Issue(如果是delete就找不到了)

5. 开始一个完整Scrum软件开发项目

接下来通过模拟使用Jira管理一个采用Scrum开发流程的项目,熟悉Scrum软件开发方法的全过程

大家可以自行向AI咨询Scrum开发方法的具体含义。(我暂时没有看到特别贴切的中文翻译,敏捷开发这个翻译我感觉很奇怪😂)

5.1 Scrum敏捷开发的主要流程和活动

Scrum开发的大致流程如下:

这里主要讲一下Scrum和Sprint,其它概念大家可以咨询AI

Scrum 比作一场激烈的篮球赛:我们团队的目标是赢下比赛(交付产品价值),为此有一堆待办事项(Product Backlog)。这些任务会被分配到不同的 “比赛小节”(版本计划)里,每一节都由多次快速的攻防(Sprint)组成。

一次 Sprint 就是一次完整的进攻回合:

  1. Sprint Planning:赛前制定战术,明确这次要怎么推进、要拿到几分。
  2. Sprint Execution:上场执行,每天通过 Daily Scrum 对齐进度 —— 昨天跑了哪几个战术?今天要怎么打?遇到了什么阻碍?
  3. 产出 Increment:回合结束时,我们拿到了分数(完成了可工作的产品增量)。
  4. Sprint Review:赛后复盘成果 —— 这次进攻有没有得分?战术有效吗?观众(用户 / 业务方)满意吗?
  5. Sprint Retrospective:再深入复盘过程 —— 我们的配合好不好?传球快不快?下次怎么改进?

一节比赛(一个版本)包含多次这样的攻防(Sprint),当所有任务都完成后,就可以发布版本(小节结束,休息总结),然后根据情况制定下一节的计划,继续迭代。

在软件开发里,一个项目会不断发布新版本,就像一场篮球赛由多个小节组成,每一节都让我们离最终胜利更近一步。

        在Sprint中,首先要制订当前Sprint的计划(Sprint Planning)。

        制订好计划之后进入计划执行阶段(Sprint Execution),在计划执行阶段,每天都要进行每日站会(Daily Scrum),也就是今天做什么、怎么做,根据Daily Scrum完成今天的工作。

        当所有计划都实现以后就会产生本次Sprint计划想要的结果,如果是一个比较庞大的项目,那么可能只是完成了一个小模块,所以可以统一理解为增量(Increment)。

        对增量(工作结果)要进行评审(Sprint Review),大家一起看看本次Sprint我们产出了什么,这个东西值不值。

        评审过后要对本次Sprint的工作过程进行回顾(Sprint Retrospective),一起看看产出的过程好不好、快不快、效率如何、质量如何。

        回顾以后,本次Sprint全部结束,准备计划下一个Sprint,如果已经是最后一个Sprint那么接下来就要发布版本(产品)。

5.2 记录需求(构建Backlog)

在所有项目中,第一步往往是弄清楚,我们要什么,只有目标明确,才能不迷路。

PO(Product Owner,产品负责人)需要把产品/用户需求用Story(类型的Issue)记录到当前项目的Backlog中。

Story 概念来自于 User Story 用户故事,也就是一个顾客/用户来到你的商店,和你巴拉巴拉说了一大堆,一个Story,然后你要理解他说的Story,满足他的需求,这样你才能和他达成交易,赚到他的钱🤪

每个Story都应该填写 Description 和 Priority ,为后续的Backlog管理和Sprint计划提供信息。

除了Story,产品需求还可以用Epic(类型的Issue)记录,Epic概念更庞大,Epic下面可以包含多个Story、Task,可以对Story / Task进行组织概括,便于大型项目中不同 role 之间进行交流。

Story 的 Description 可以按照某种模板编写,例如:“作为一个<角色>,我想要<功能>,以便于<商业价值>”,要突出提醒Story的三要素——角色、功能、商业价值。

5.2.1 创建Scrum项目

创建一个Scrum类型的软件开发项目,命名为Project B,关键词为PB。

5.2.2 创建Story

创建一个Story类型的Issue:

5.2.3 使用Story Point

Story Point(故事点)是Jira中用来衡量(评估)工作量的一种工具,它用一个数字来表示。

为了较明显的区分出不同Issue的工作量,一般用改良过的斐波那契数列来填写(0、0.5、1、2、3、5、8、13......),如果用1、2、3......来写的话就分的太细了,比如10和11的工作量就感觉不出来差了多少。

其中1个Story Point代表多少工作量一般由团队内一起协商,确定参照物(例如0代表修改一个按钮的颜色、1代表添加一个按钮并绑定功能)

在使用Story Point之前需要:

1、把Story Point添加到我们本项目的Screen中(启动显示)

2、指定哪些类型的Issue可以使用Story Point(控制范围)

点击顶部导航栏中的设置⚙️,点击Issues

填写管理员密码进入设置

在这里可以看一下自己有哪些类型的Issue:

我这边由于是中文默认语言改为英文的,导致我有些类型有两个重复的(相同作用,不同中英文名),这应该是个Jira软件的bug,我试过重装的时候选择英语也没用,可能是因为我的系统是中文Windows系统。并且在软件的其它地方也会出现有些单词不翻译为英文,保持为中文的情况。

我这里把重复的中文类型都删了,后面统一用原版英文概念讲解:

接下来,在左侧导航栏目录里找到Custom fields

在搜索栏里填写故事点或Story Point

(我前面提到过,我这里只有中文的😂,不知道你们有没有英文的)

点击右侧的“更多”按钮,选择Associate with screens

1、把Story Point添加到我们本项目的Screen中(启动显示)

可以全勾上,如果能看懂的可以根据自己需求选择勾哪些(可以问AI在Jira中Screen什么意思)

重复刚刚的操作,这次选择Configure contexts

2、指定哪些类型的Issue可以使用Story Point(控制范围)

点击Edit Configuration

滑到页面下方可以看到,使用范围里目前并没有Story类型

可以根据需要,添加或移除目标类型:

这时候,我们点击顶部导航栏中的Create(新建),再新建一个Story:

这一次我们可以把 Summary 和 Description 都写的更详细一点

Summary:<买家>要<将商品加入购物车时能选择规格>

Description:

作为<商城买家>,我希望<将商品加入购物车时能选择规格>,方便<后续统一结算>

需求描述:

  1. 商品详情页点击「加入购物车」,弹出规格选择弹窗
  2. 可选择商品的颜色、尺寸、数量(默认 1 件,最小 1 件,最大不超过库存)
  3. 选择后展示所选规格 + 单价,确认后加入购物车
  4. 购物车中展示该商品的规格、数量、小计金额

滑到最下面,现在可以看到“故事点”(我真服了😂,就跟这个相关的全都保持中文不变)

Story创建完毕后,点击顶部导航栏 Projects 回到我们的项目PB:

可以看到我们设置的Story Point:

第一个Story我们在创建时没有设置Story Point,也可以修改。

点击Backlog中的Issue,可以在右侧看到Estimate(评估、估算)

5.3 制订版本计划 (构建Backlog)

项目负责人(PO,Project Owner)根据产品需求、市场、团队的情况,指定发布版本的计划,规划具体工作,例如准备在什么时间,优先完成哪些功能,后续版本依次完成哪些功能,发布周期是多久等。

在这一阶段,至少要构建完当前版本的Backlog,也可以提前规划下一个版本,开始干活之前要做好分析与规划。

把所有事情通过不同类型的Issue保存到Backlog中。

在Jira中可以通过将Issue与某一版本号关联起来,实现记录版本计划。

在创建版本之前是无法给Issue绑定版本的:

点击左侧导航栏中的Releases(发布版本)

填写版本号(名),版本发布起止时间,版本描述等信息,点击Add添加版本:

可以在左侧导航栏中点击 Backlog 或 Issues ,找到对应的Issue,编辑它关联的版本

5.4 冲刺(Sprint迭代)

(版本发布)计划好之后就要开始执行计划了,将计划拆成一个个Sprint来分步完成。

5.4.1 创建Sprint

添加Sprint名称,Sprint目标,Sprint起止时间(可快速选择或自定义)

Backlog中拖拽相关的Issue,放到对应的Sprint中。

5.4.2 工作量估算与子任务

项目负责人(PO,Project Owner)要在Sprint计划会议中向团队介绍本次 Sprint 中涉及到的Issue。

团队根据实际情况对 Issue 进行工作量估算(Estimate by Story Point)

如果一个 Story 工作量太大,可以把这个 Story 分成多个 Sub-Task,然后对每个Sub-Task进行工作量估算,也可以不估算子任务,下文中估算子任务的部分可以自己选择是否跳过。

豆包说的:

正确的做法(推荐)

  1. 只给 Story 分配故事点:这是对整个功能的复杂度估算。
  2. 给 Sub-task 分配小时数:这是对具体开发步骤的工时预估,用于跟踪进度。
  3. 工时总和不要求等于故事点:故事点是相对估算,小时是绝对时间,两者没有精确换算关系。

Sub-Task和Story的关系应该是:所有相关的Sub-Task组成了这个Story。

也就是说所有Sub-Task完成后这个Story就完成了,因此在划分Sub-Task的时候不要遗漏。

创建子任务:

在Backlog界面中点击目标Issue,在右侧编辑界面的最下方

填写信息:

勾选Create another快速创建多个子任务:

之前我们设置Story Point(故事点)的使用范围时只设置了Story、Epic,所以现在Sub-Task是无法估算工作量的,大家可以参考前面的教程,去设置里添加一下Sub-Task类型:

其实如果我们一开始就添加了子任务类型的话,我们在创建子任务的时候就可以填写工作量估算了,我也是写到这才发现这个问题,不好意思😭

5.4.3 启动 Sprint 并查看

Sprint所有内容都规划好之后,点击Start Sprint

可以清晰的看到 Sprint 中的 Story 及其 Sub-Task

5.4.4 执行Sprint

5.4.1、5.4.2、5.4.3这3个部分相当于 Sprint Planning,接下来我们要进入Sprint Executing

Sprint Execution阶段,敏捷教练(SM,Scrum Master)每天需要召开每日站会Daily Scrum)快速同步本次Sprint团队昨天的工作完成情况、今天的计划、工作中遇到的问题等。

在召开每日站会Daily Scrum)之前,团队成员需要在自己的 Active Sprint 看板中更新自己负责的 Issue 的状态:

在左侧导航栏中点击 Reports,可以查看燃耗图、燃尽图等报表来查看当前Sprint工作进展。

比如,燃尽图(Burndown Chart)可以清晰的看到理想工作线,当前工作线:

目前一个也没完成,所以实际工作线比计划工作线高。

5.5 评审(Sprint Review)

Sprint Planning 阶段,我们填写了Sprint起止日期(应该合理计划),在迭代(计划)的最后一天召开Sprint评审会议(Sprint Review),在会上演示当前Sprint完成的功能(工作结果),项目负责人(Project Owner,PO)对产出的结果(或者说增量Increment)进行验收,最后更新各个Issue的状态(Sprint中可能有的Issue完成了、有的未完成)

如果有未完成的Issue,把它移动回Backlog中,或者移动到下一个Sprint中。

假设Sprint Review那天,Sprint状态如下,点击 Complete sprint

由于我们只完成了Story中的一个Sub-Task,还有一个未完成,所以这个Issue属于为完成状态。

可以选择未完成的Issue移动到哪里:

Complete Sprint之后自动跳转到Sprint Report:

5.6 回顾复盘(Sprint Retrospective)

每次Sprint迭代的最后一个会议是Sprint回顾会议。

Sprint Review 主要是验收工作的结果,而 Sprint Retrospective 主要是验收工作的过程

在Sprint回顾会议中,团队需要回顾本次Sprint工作中做的好的地方、做的不好的地方、值得改进优化的地方、存在什么问题等,涉及工作流程、团队协作、工作效率、产品质量、工具等,根据会议总结结果,在后续Sprint中实施(可以在Sprint Planning阶段提前计划、备注提醒),不断优化,持续改进。

5.7 发布版本(Release Version)

按照我们制订的版本计划,通过完成多个Sprint,直到满足了版本计划要求的各项功能和验收指标后,发布版本。

我把所有未完成的Issue再通过一个Sprint完成:

把所有Issue都分配给我自己:

更新Sprint中Issue状态:

所有子任务完成后完成Story,更新状态:

完成所有Issue:

Complete Sprint:

由于我第一天就完成了所有计划的任务,可以看到实际完成线是低于计划完成线的:

发布版本:

左侧导航栏中点击Releases,查看进度条满的版本

点击更多按钮,点击菜单中的发布(Release)

填写发布日期:

可以在 Reports 界面查看版本报告(Version Report)

6. 总结

其实Jira只是一个工具,理论上来说,这些工作模式,你用纸笔记录结合线下会议也可以实现,但是用Jira管理更方便,且能线上协作,自动生成报表。

最后复习一下Scrum软件开发模式工作流程,还有其它开发方式,大家可以自行学习:


最后,本文内容基于《Jira实战:项目管理与精益看板》ISBN 978-7-111-71270-1

和自己的学习经验总结,另外Jira官方计划全面转为线上云服务,官方强推在线使用Jira(但是我注册时一直由于网络问题没成功😭),本地Jira大家自己找找资料安装一下,用于学习的话本地Jira还是蛮方便的。

Logo

腾讯云面向开发者汇聚海量精品云计算使用和开发经验,营造开放的云计算技术生态圈。

更多推荐