jira 新手使用入门2

Posted 2023-03-22

参考技术A 需要注意的是我们在业务中出现的每一个任务 问题都可以抽象的看做是某一个项目中的一个子问题，一个项目也是因为这些问题的组合，不断丰满起来，问题 任务 故障 隶属于项目，所以在 新建问题 的时候 ，首先要确认这个问题属于哪个项目，如果存在则在这个项目中创建问题，如果不存在则需要通知管理员来首先创建项目 来管理这些问题 任务故障

新建项目

选择合适的 项目种类 比如第一种 分软件和商业两大类，软件主要涉及软件的开发周期 中的bug 问题，商业主要是项目管理 流程管理 任务管理

点击下一步

为项目命名 填写完毕后 点击提交 ，创建人则是负责人，拥有对该项目的所有权限

项目创建完毕后 就会生成一个面板， 点击【新建】可以创建问题 任务 流程等等

新建问题 每一个问题 会有很多属性 需要选择和填写

它属于哪个项目

她是什么类型的问题

简述问题标题

这个问题是谁提出来的

这个问题 是哪个模块出现的问题

这个问题具体的描述信息

这个问题严重不严重 需不需要优先处理

这个问题要反馈给谁，要分配给谁处理

这个问题张什么样子 报错内容是什么 添加图片截图 输出文本附件 佐证

这个问题要不要限定处理时间

这个问题和哪些问题是关联问题

这个问题 关键字 标签是什么

当这个问题被创建后，会分配给经办人，经办人可以是多人，那么经办人 的【分配给我未完成的问题】 列表 就会出现 刚刚问题报告人分配的任务，

当你确认这个问题是属于你的职责的话，可以开始处理他，并更新状态

当你确认这个问题不属于你，可以驳回 并返回给报告人，告知你重新分配，或者 主动分配给下一个人

当你处理完成后 选择 点击【完成】，这个时候 状态会更新给报告人，报告人会去前往 项目验证结果，

如果问题验证通过，报告人关闭【完成】问题，那么经办人的问题 执行完毕 ，如果问题依旧存在，问题会重新被打开【重启】 经办人会重新看到此问题，如果问题 不存在 可以【停止进行】

Jira入门教程 敏捷开发管理

拖了那么久，感觉不能再拖了。正好最近2018年Q1季度结束，对Q1季度的敏捷开发实践做了系统性的回顾，总结了一下经验教训，那就接着上次提到的，这次来介绍一下敏捷开发的基本概念吧。Jira只是敏捷开发的管理工具，使用前需要至少得具备基础的理论知识。

 

瀑布流模型

开始介绍敏捷开发之前，先介绍一下敏捷开发方式提出之前的开发方式：瀑布流模型。

瀑布流模型将软件开发和交付划分为几个相互独立的阶段：

1. 需求收集

2. 设计

3. 编码

4. 测试

其中每一步都需要等前一步完成之后才能进行，必须从上向下，也因此得名“瀑布”。瀑布流模型的理念有点“人定胜天”的意思，意图在开发之前就确定好一切细节——有经验的开发者都知道这是不可能的。在传统行业如建筑业中，受限于交付物的体量以及改动成本，而不得不采用瀑布方式，毕竟房子盖好了只能简单改改格局，其他想改只能推到重建。而对于软件开发特别是互联网软件开发来说，对已经交付的软件进行改动简直不能再简单了。

敏捷开发

2001年，十几位很厉害的开发者们聚在一起，经过一翻交流之后，发起了敏捷运动，还撰写了一份宣言——《敏捷宣言》。现在这份敏捷宣言还托管在GitHub Pages上，有兴趣的可以去http://agilemanifesto.org看一看：

图中靠下的位置就是当时的十几位开发者。搜一下会发现他们各自写了很多软件开发领域的教科书级书目。

敏捷宣言的主要内容，翻译一下是：

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，
我们更重视左项的价值。

敏捷开发也存在需求、设计、编码、测试4种职能，不过敏捷开发并不是小型瀑布流，4种职能之间是紧密结合、彼此交融、相互依赖的，不存在瀑布流的“职能筒仓”问题。文档、开发、测试往往是同步进行的。基于敏捷开发的理念，衍生出来精益开发、极限编程、测试驱动开发（TDD）等等具体方法，而Jira所支持的Scrum就是其中的方法之一。

Scrum在英语是橄榄球运动中列阵争球的意思。就我看过为数不多的球赛里面，2012年欧洲杯决赛西班牙队4：0血虐意大利队的战术，也有不少scrum的意思，小步快传，全队皆锋。

Scrum角色

在Scrum团队中有3种角色：

1、产品负责人Product Owner，定义需求列表及优先级、验收标准，代表业务需求方，也就是我们常说的产品经理。不过产品经理往往身兼更多职责如项目管理、交互设计、用户调研等。

2、敏捷教练Scrum Master，保证团队按Scrum的方式良好运转下去，在没有专职人员的情况下，一般由研发经理担任比较合适。如果由产品经理负责，需要对软件开发技术有一定的了解，并且能够清晰剥离出自己Product Owner与Scrum Master的职责，在正确的时机做正确的事，因为这两个角色之间的关系基本是相互对抗的。

3、团队成员Team Member，真正做编码和测试的人员，对故事和任务工作量做估算，并交付最终可用的产品。

Sprint周期

Sprint（冲刺）周期是执行Scrum的基本节奏。每一个Sprint周期都是一个固定的时间盒。在这个时间盒内，要做的故事和任务（也就是产品需求）是确定的。当周期结束时，不管需求有没有全部完成，这个时间盒都会结束，并准备启动下一个时间盒。如此循环，通过快节奏的迭代冲刺，不断交付有价值的产品并且不断修正产品。

在一个Sprint周期中，有几个主要会议：

1、Sprint规划会议，在会上产品负责人、敏捷教练、团队成员会坐在一起，共同决定这次的Sprint要完成哪些用户故事，并将故事分拆为任务，然后对任务进行估算。

2、Scrum日会/站会，找一个每天固定的时间，团队成员站在一起，每个人轮流陈述上一次日会之后已完成的内容、下一次日会之前期望完成的内容，然后对比前一次日会的“期望”与本次例会的“完成”，如果不符合，可以立即发现并寻找原因加以解决。

3、Sprint评审/演示，在Sprint结束的时候对完成的内容进行演示，或者叫验收。团队成员从用户的角度演示本期Sprint交付的故事如何被使用。这里有个经验，对于无法演示的内容，比如提高页面的平均加载速度至3s以内，拿出相应的证据进行“演示”即可。

4、回顾总结，可能都觉得没什么用，甚至团队成员在会上不知道说什么。我拿实际经验告诉你，坚持下去，很有用！对团队来讲长期收益巨大！团队会慢慢变得更有干劲、更有效率，输出的代码质量也会提高。如果没人发言，一定要逼着他们说。

Story & Task

说了这么多，终于到了跟Jira高度相关的部分了。在（一）中我们只简单提了Story是用户故事，现在是时候详细说明一下了。

用户故事，是从业务及用户角度出发，描述产品可以完成哪些事情的简要说明，每一条用户故事都应具备用户价值。书写正确的用户故事，是进行敏捷开发的重要一步。缺乏经验的产品负责人往往把用户故事当成团队成员要做的事情，而不是用户要做的事情。

举个例子，一个不合格的用户故事：

“在数据库中增加一个卖家联系方式字段并展示在前台页面上”

这个做了给谁用的？怎么用？有什么用？

对比一下合格的写法：

“卖家可以在管理后台填写联系方式，让使用App的买家在遇到问题时能及时联系专家”。

在这个合格的用户故事中，包含了3个要素：用户、行为、目标/价值。“某人可以做某事以达到某种目标”，或者“某人可以做某事以创造某种价值”。

用户故事言简意赅、目标清晰即可，不需要、也不应该写得非常详细。只要能达到目标/创建价值，在细节上采取什么方式都不重要，团队成员要做的是以用户故事作为指引，协力找出投入产出比最高的解决方案。太详细的用户故事，只会限制团队的创造力，并把团队的注意力吸引到“执行命令”而非“创造用户价值"上。

Task则是将用户故事分解之后得出的任务。比如刚刚举的用户故事的例子，就可以分拆成以下几个任务：

1. 后端增加联系方式字段，并提供API供前端读写

2. Web前端增加填写联系方式的表单

3. App中显示相应卖家的联系方式

一些不涉及用户故事，但对团队有价值的工作，也可以列为“技术”任务。如“编写测试环境部署脚本，让测试人员可以主动选择测试分支”。

估算

把估算单独拿出来说，是因为在通过Jira实践Scrum敏捷开发时，估算是相当重要却又很容易被误用的一环。

对任务做估算的目的是为了对工作量有大致的预判，从而在有限的时间内交付尽可能多的用户价值（而不是开发工作量），更不是为了对项目的时间节点进行精确的控制。团队的生产速率基本是固定的，而具体到每个开发任务的工作量也都是基本固定的，所以只要团队都在持续且高效的输出价值就足够了。妄图以强制的deadline让团队成员持续加班，结果只能是幸福感降低，然后是效率降低，然后要么是交付物的质量下降要么是交付物的范围缩减，最后团队分崩离析。

估算一般有3种方法：小时数，点数，任务数。小时数过于精细，而且容易陷入精打细算的误区；任务数过于笼统，对任务分拆的粒度有较高的要求；点数即Jira中的Story Points，也是实践下来比较推荐的估算方法。

点数的是为了比较出开发任务之间的相对大小。随便选一个看起来工作量比较小的任务作为1，然后看其他任务是这个任务的几倍，遇到比这个任务还要小的就算0.5。在估算点数的时候，只能在0.5/1/2/3/5/8/15/20/30中选择，甚至30都不应该被使用，当一个任务的工作量是另一个任务的30倍的时候，这个任务一定可以被分解成更具体的任务。这么规定的原因还是因为我们要比的是相对大小，在估算时一个任务是18点还是19点，没有什么区别。

可以看到点数只是一个相对值，没有单位。在实践中，团队成员刚开始进行估算时很容易陷入1点 = xx小时的误区，先估计小时数，然后再把小时数换算成点数。作为Scrum Master，要么努力纠正这种误区并引导建立正确的观念，要么就让团队成员用人天当单位估算吧。

关于敏捷开发的基本概念和基础知识介绍的差不多了，其他一些像燃尽图、控制图、任务板之类的等用到再说吧。