Jira的道在于构建了整个环境和思维模式，也赢得了市场的认可，成了一种势。无数的厂家便成了Jira的海洋生态当中的重要组成部分。有些厂家的插件是提升了Jira的体验，有些则是强化了特定功能。这里只推荐三个算得上 必须 使用的插件。
围绕这三个插件，我们能够搭建起研发管理的整体路线和迭代管控视图，简化流程，完善管理制度。接下来就介绍每个插件的场景和使用方式。
我们通过一张图形成一个大概的印象
我们当时选择这个插件期望满足的场景有下面几个：
我们项目管理常用的软件就是微软的Project，所以我们选项目标也是按照这样的思路来挑选的。最简化的概念就是 甘特图 。
当中有设置的必要的应该是Working schedule了
设置放假和周末，这样在计算任务起止的时候能够在甘特图中正确的显示，其他我没有做过多的设置。
从上图可以看出甘特图的组织形式分为4层。
1 项目（Project）
2 版本（fixVersion）：注意是根据父任务的修复版本确定的
3 父任务（Story/Task）
4 子任务（Sub-Task）
在甘特图的界面可以进行任务的管理。
可以拖动任务的两端进行开始和截止日期的调整，也可以直接拖动整个任务进行任务的调整。
任务的进度是通过下面的三角标识进度，这个计算是使用实际投入的工时与预计工时直接的比例。
蓝色的线是在日期栏直接左击，就可以设置一个时间线，默认是设置在选择日期的开始。可以用于设置迭代里程碑。
显示内容的设置界面如下：
可以看到有四种方式可以混合使用：
1 面板
2 过滤器
3 项目
4 JQL查询语句
任务列表界面上元素都是可以根据实际系统中设置的字段进行调整的，如下图所示：
绿色的是自定义字段，灰色的是系统字段。自定义字段基本都是单纯的显示，系统字段会有一些其他的效果。
这个插件在前端没有任何感知，知道Jira系统中存在这个插件的基本也只有管理员了。但是对于管理员来说，这是流程推进、串联的最重要的工具了。
它的作用是在工作流的流转过程中可以附加其他的 *** 作，列表如下：
可以看到主要有赋值、分配人员、评论、触发其他流转环节、自定义脚本等等，而且可以针对问题本身、父问题、关联问题。基本能够涵盖日常应用的场景了。
我讲一下我实践过程中，比较常用的几种场景：
使用到 Assign to last role member 或者Assign to role member 。场景例如bug，当测试发现一个bug时，可能并不直接指定具体研发，而是 提交给研发管理小组 确认之后再分配给具体研发，具体研发人员修改完成后，点击 修改完毕 按钮，转发给测试。测试若发现bug没有完全修复，点击 退回研发 按钮，直接退回对应研发（而且可以累积退回次数）。
这里面的几个步骤：
1 修改完毕，会追溯到测试角色的最后一个经办人，并且将问题分配给他
1 退回研发，会追溯到研发角色的最后一个经办人，并且将问题分配给他
为何要追溯某角色的最后一个经办人？因为内部可能还存在多次指派，甚至对bug进行分析后发现不是后端bug要指定给前端研发。测试不用自己分析要退回给谁，让流程来判断。
使用到 Transition linked issues 和Transition parent issue 。我们最早就讲过，整个系统是子任务驱动的，具体人员只用关心和管理自己的子任务（子任务只有开始和结束两个简单状态），但是父任务涉及多人合作和角色含义，状态和节点可能会有几十个，无论让谁来管理都是很困难的。场景，一个父任务需要UI、产品、前端、后端、测试共同完成。其中可能产品先行，完成之后交付给UI，完成就可以前后端介入，研发全部完成后才能交付给测试执行。
这里面思想其实很简单，就是子任务工作流+角色。首先对于不同角色要区分出合理的用户组，当每个人完成任务时，判断他自身的角色从而触发父任务的状态流转。比如产品完成任务时，转至 方案设计完成 ，研发完成时可以判断当前父任务下是否存在测试子任务，若存在转至 研发完成待测 ，若不存在说明不需要测试转至 研发完成无需测试 。
这里给大家一个小小的建议
当你添加自动化工作流时，这里时可以选择名称或者id的，id就是一串唯一数字，当你需要精确触发工作流时可以指定。但是像上面描述的那种情况，其实并不能完全判定当前的状态是什么。比如需要产品协助时，产品会先完成任务之后研发才开始，这时候研发介入的上一环节是 设计方案完成 ，但是也存在不需要产品研发直接开始比如研发内部优化，这种情况下研发介入的上一环节是 待办 。如果这时候指定的具体的工作流，起始状态不正确就无法执行。所以建议是使用名称，而且建议规范是 转至+下一环节名称 ，比如到研发这个环节，无论从待办或者方案涉及完成，甚至测试退回，都成为 转至研发 ，这样我们只要写一次post function就可以满足多种情况了。
注意 ：即使使用名称流转，也必须满足该流转的起始和中止状态满足当前情况。例如如果我 方案设计中 如果没有指向 研发进行中 节点，即使我尝试触发该流转也是无法执行的。
研发在质问我，已经9012年了我们还要使用工时这种low爆的形式来做绩效管理么？每天凑满8小时工作时间对于管理层就这么重要么？你们的能力仅仅就是看着这个人工时有没有记录好么？
如果你这么想，说明你没有想过研发管理到底该做什么。研发管理控制三要素：时间、成本、质量。控制的目的是提升，如何提升？必然是发现问题，改进才能提升。最简单发现问题的地方是 工时分配 ，而不是某个员工8小时工时本身。某个迭代中，那个story投入的工时超出成本，哪些人的bug工时投入超出正常比例、哪些人的线上问题投入工时较高、整体研发部门投入在非研发工作上的比例是多少，要不要优化。这些才是我们应当去关注并改进的。当所有人员只有3-5个人，可能这个数据受个人影响比较大，但是当人员超过30-50人时，个人少报或者没有正确填写的影响就已经比较小了，我们要观察的是趋势，大项的时间投入正常都是有记录的，这样基本就能够反应真实情况了。
所以Tempo作为目前时间管理最好的工具，在研发管理中重要性相信各位管理人员都有认知了。
tempo当前最新是942版本，我使用的是8153 。我尝试升级过一次插件，结果大家都不习惯新的界面，我不得不退回老版本。
全局配置中有几点说明，我们是子任务驱动所以工时不允许记录在父任务。但是只有一个任务下有子任务的时候才是父任务，否则就可以记录工时。
Work Attributes是设置工时填写面板的自定义字段
注意 ：这里的字段只有通过记录工时按钮呼出的界面才有，比如完成任务时填报工时的界面是没有自定义字段的。
v9去掉的就是这个工时表，这个基本上是我们最常用的功能了。所以去掉之后大家都不知道怎么用了。
用户这个地方的下拉框可以选择如下几种选项。其中比较难理解的是账户这个概念，tempo里面实际上是有成本概念的，就是通过账户当中的金额来管理，不过我们没有使用过。
常用的几个是用户（分析单个用户的工时分布），团队（每个小组整体任务工时分布），高级（指定过滤器查看任务工时分布），问题（查看单个问题的人员工时分布）
时间区间可以任意指定，查询出的结果可以直接导出excel用于做透视图之类的。
v9主推的就是Reports *** 作的内容和界面形式应该是更加优化，上面的时间区间、过滤器设置（可以多选），分组可以多选和排序。
这个我们用的比较少，主要会针对某个具体问题、或者较大的Epic相关的项目站会、总结会时，分析人员工作进度和使用。
上述三个插件加入到Jira之后，我们完成了迭代整体控制、工作流实施、研发管理规范与提升三方面配置，基本已经可以开始组织一个研发团队为了同一个既定目标按照统一规范流程进行开发，而且尽量简化过程降低研发非研发类工作的占比。但是我们还是可以使用一些其他的插件来提高研发管理整体效率。另外必须说一句，这些插件的仪表盘可用插件没一个能用的。
首先，贴一下官方报表的说明文档的链接： 跳转
最近读了一本书，书中有一句话，大致意思是：文章太长时，大部分人其实都不会读完它。
觉得很有道理，但是这篇JIRA还是没办法的写了很长。
希望这是本人最后一篇JIRA的博文。耶。
该报表会在对应sprint complete之后生成出对应的sprint velocity总值。
主要的作用是统计历史sprint velocity，用以对将来的sprint plan提供velocity上的指导和参考。
以及在velocity趋势波动的时候，结合数据和实际情况进行分析 —— 波动产生的原因，用以调整团队在将来sprint中的工作。
注意：velocity本身基于的估算，本身并不能作为一个sprint工作量的承诺。
Commitment（柱） : 代表sprint start的时候，sprint plan的所有issues估算值的总值。
Completed（柱） ：代表sprint complete的时候，实际完成的issues估算值的总值。
当单次Commitment比Completed高时 ，代表未完成计划的issues scope。
当单次Completed比Commitment高时 ，代表sprint中issues scope发生了变化。
ps：当然如果你的团队总是无法在sprint开启的时候，确定好issues scope，那Commitment柱基本上是帮不了你了。
velocity chart是board-specific–的，意思是说 —— 如果有两个board使用同一个sprint，当前board的velocity chart只会计算当前board scope（根据board configure Filter）。
Burndown Chart也是board-specific–的，基于当前board filter：
Scope change - Issue added to sprint（具体原因） : 一个issue加入了此active sprint。具体原因有多种，比如“Estimate of 1 has been added"添加估算，“Estimate changed from 3 to 2”修改估算，等等其他。
Burndown - Issue completed : 一个issue被完成。“完成”的定义是基于board column的，当issue被挪到active board最右的column，即认为complete。
主要作用是来查看项目的cycle time（or lead time）。
cycle time代表issues在具体的column对应的状态上耗费的时间。
lead time代表整个团队对issues —— 从对应的需求提出到实现完成耗费的时间。
先从图上按顺序来看一下：
①指向的绿色空心点，代表一个issue。如果是一个大的绿实心点，代表一堆很接近的issues。
②指向的是，可自定义的报表x横轴时间区间。
③表示，在报表上使用鼠标悬浮滑动，可以查看固定时间点的值信息。
④ 指向的是，Refine report，此报表最重要的一块 —— 针对issues scope的选择。
报表最上面是统计信息 cycle time 、 issues count 。
Refine report
Columns / Swimlanes / Quick Filter 三个过滤条件是 "与&" 的关系。
Columns ：基于board columns，提供多选。勾选上的columns，报表会计算出issues处于被勾选的columns的总cycle time，并进行显示。
而报表图上的issue绿点的横向坐标，代表该issue“终止”该组columns的时间点。纵坐标代表该issue的cycle time。
Swimlanes : 基于board configure Swimlanes设置的JQL filter进行issues scope过滤。
Quick filter : 基于board configure Quick Filters设置的JQL filter进行issues scope过滤。
Swimlanes一般是基于board计算的，变动不会太大和频繁。因此，可以通过随时定制Quick filter，来进行Control chart报表分析时的过滤。
比如添加一个Quick filter —— 为了过滤出某一个sprint或者release的issues；还比如官方推荐了一个去除 没有参考价值的异常issue 的方法，就是通过在具体的异常issue label上进行标记，然后定制Quick filter进行过滤的方式，在Control Chart统计时排除异常issues。
Include non-working days in calculations
报表右下角有一个viewing option， Include non-working days in calculations 不勾选时，cycle time的计算不会包含非工作日。
至于Control Chart上统计数据 cycle time ，包括average\median\min\max的时间显示，单位w/d/h中， 1w = 7 working days ，仅是一种简单的单位换算，不要产生误区。
查看lead time
如果项目设定issue从 ready for dev 到 In dev 到 Dev Done 到 In QA 到 QA Done ，是一个需求从提出到完成实现的整个流程的话，将columns勾选上 ready for dev \ In dev \ Dev Done \ In QA 4个状态，则可以统计和绘制出lead time和相关issues。
如果想分析 —— 到开发们完成卡的这段cycle time，可以仅勾选 ready for dev \ In dev 2个状态，即可查看。注意，不要将最后的缓冲队列 Dev Done 误勾选进去。
rolling cycle time
rolling cycle time是根据 当前issue + 前面x个issue + 后面x个issue 的平均cycle time。x 是基于时间轴上的issue总数的一个取值。
目的是为了展示cycle time的一个具体范围趋势 —— average cycle time就是一条水平线。
报表上的蓝色阴影区，代表issue cycle time和rolling cycle time的标准偏差值，蓝色区域越窄，代表issue cycle time更接近周边的issues cycle time，这段rolling cycle time置信值越高；越宽的区域，issue异常情况越多，rolling cycle time置信值越低。rolling cycle time置信值越低，代表该时间段附近issue异常越多。
另类使用小tips：columns单选之后，比如In Dev，计算出来的Average cycle issues count，可以看到在此column内对应issues的时间投入程度（前提，团队有按真实情况及时挪卡）。
比如：
在某一个时间段内，Dev done色带在纵向上逐渐变宽，代表等待QA测试的issues堆积越来越多，QA存在瓶颈；
在某一个时间点，In Dev色带上边界值有下降趋势，代表有部分issues从In dev状态被重置回上游column，代表issue内容可能被返工；
在某一个时间点，In Dev色带在纵向上的宽度比正常时窄，说明在制品在减少，如果开发人员并没有减少时，代表部分开发人员在空转；
在一个sprint时间段内，Preparing高度仍然在上升，说明sprint scope在增加；
所有in progress的columns色带，在横向宽度上变宽，说明lead time在逐渐变长。
Refine report
与Control Chart相同，对issues scope进行过滤。参照Control Chart Refine report。
2我测试了好几个邮箱,qq,163,阿里邮箱,感觉就163没出错,不用配置什么,其他的好像都要配置一些设置的,所有我选择用163网易的;
3大体设置如下
4配置好之后,点击测试,一般用户名密码正确都能测试通过;
5一般在用户邀请哪里,可以发邮件,我刚刚开始配置的时候,就是测试通过,但是这里用户邀请发邮件却发不出去,后面百度了一下,这里还有一个设置,
那就是上面配置的账户名,必须跟你默认的管理员账户里面那个邮件地址一样,刚刚开始装jira,那就是admin账户里面的邮箱跟你这里这个用户名要一样,
才能正确的发邮件Jira字段配置最佳实践
最佳实践 | "拯救"Jira — 规模化团队敏控创变之路 | IDCF
JIra配置权限方案
JIRA笔记（二）：用户、组、角色、权限方案
Jira 用户权限设置
jira权限设置-各个项目组查看不同项目
在JIRA的一个项目中，如何设置让项目中的问题可以设置不同的权限让不同的人看到。
JIRA项目权限分配 *** 作手册（详细详细详细）
本文的配置目标为“实现不同角色的项目组成员仅可访问指定权限资源”。
Jira中权限分为应用程序权限、全局权限和项目权限方案。应用程序权限为访问jira应用或者其他一些购买的应用的权限，为最高层次的权限，决定了用户可以访问的应用程序的范围。全局权限为某个用户组可以访问或者控制的应用内系统资源的权限。这些权限包括报表、对象创建访问管理等。而项目权限方案是从项目视角看，不同角色的用户具有的访问项目资源的权限方案。
当前配置中配置为所有组用户均可访问jira-software。
这里简单地将用户分为管理员和jira系统用户。管理员组中用户具有管理所有资源的权限。而普通用户组成员仅仅具有参与项目的权限。
针对自己的组织特点（公司项目架构），梳理出项目中所有参与的角色，并在项目权限方案中配置每个项目角色所具有的权限。
分为基础用户组（调整修改jira-software-users），系统管理组（使用默认jira-administrators）。
项目权限方案的配置原则为“项目参与者角色具有对应角色权限”。在“系统-安全-项目角色”功能中添加一系列的项目角色。包括项目经理、产品经理、研发工程师、测试工程师、设计师、用户等角色。
在问题-权限方案中调整权限方案。调整默认的方案模型，进行如下的权限配置。项目创建之初，只需要指定不同的角色即可实现项目权限的管理。
项目管理权限配置如下。保证了仅仅项目组成员可以查看项目信息。
编辑权限方案，配置相应角色的权限项目。对应的问题权限配置示例如下。
编辑决策人和观察者相关权限。
配置问题评论权限。
编辑附件权限。
在项目设置中修改权限方案。
之后将人员添加到项目，并配置其角色即可。一个人员在项目中可以具有多种角色。
JIRA在默认情况下,创建问题时是将问题直接分配给项目负责人,因为项目负责人在默认情况下就是默认经办人 那有没有办法可以选择经办人呢
强大的JIRA告诉你, 这完全没有问题 下面我们就来看看如何进行设置
首先进入管理员界面,选择"系统">"通用设置">"允许使用未分配的问题", 将其开启, 如下图:
这样子设置了之后就可以在角色设置中选择默认经办人时, 可以选择未分配, 否则只能选择项目负责人, 如下图:
将默认经办人设置为未分配之后, 在创建问题时, 就可以自己选择经办人或者未分配, 当然只有那些拥有被分配权限的人才能够被选择为经办人, 如下图:
经办人为"自动"的意思就是角色设置中的值,要么是未分配,要么是项目负责人
回到标题提出的问题, 如何设置默认经办人为报告人呢 我们先看看这个有什么实际意义, 那些地方会用到这种功能 JIRA为我们提供了一个高可定制性的流程管理系统, 我们就可以利用JIRA来进行个人日志记录, 个人任务管理
当然我们不可能为每一个人都创建一个项目来进行管理, 我们要达到的效果就是, 我们只需要创建一个项目,比如就叫"个人任务管理", 那么每个人都可以使用这个项目录入自己的个人任务计划, 但是这个个人任务 计划又只想分配给自己,而不让别人看到 当然我们可以选择经办人为自己, 但是如果系统能够为我们自动选择,那多好啊, 所以也就有了这个需求, 设置如下:
打开个人任务计划的工作流, 点击工作流动作"Create", 在d出的菜单中选择"View Post Functions", 如下图:
d出设置对话框:
点击"添加", d出"为工作流动作添加处理结果"对话框:
到这里, 设置全部完成, JIRA的工作流动作可以设置动作的"触发条件", 也就是谁可以触发这个动作, 还可以设置动作的"校验规则", 还可以设置"结果处理", 也就是触发动作完成之后可以做那些事情
字段设置的菜单区域字段设置主要在实在这个菜单区域里面，但是有一些 *** 作需要到其他菜单进行是设置才能完成。下面斜体字的都是说的菜单、按钮、链接等。
增加Start
Date到Task中
1增加字段
首先肯定得增加字段了
1)Custom
Fields-》Add
Custom
Field
2)选择Date
Time，其实有很多字段类型可供选择，这里Start
Date是日期类型，所以选择Date
Time
3)Field
Name填写“Start
Date”，在Choose
application
context的Issue
Type中选择Task。
4)Associate
field
Start
Date
to
screens。如果你定义了很多Screen，则可以在这里选择更新到Screen中。如果你没有定义，则忽略。
2字段配置
字段配置是和Issue
Type需要关联的，最好根据各种不同的IssueType建立各种Field
Configuration，因为有些字段Bug需要，但是Task不需要，Field
Configuration的主要目的是设置字段是必填和可选，以及设置字段是否隐藏。
1Field
Configurations-》Task
Field
Configuration（没有自己建一个）
2设置Start
Date为Required（必须填写）
3增加界面
Screen和Field
Configuration没有直接的联系，但是他们都和Issue
Type有关系。因此有人说Screen上我明明有这个字段，但是为何看不见？那是因为你的Field
Configuration中把这个字段给隐藏了。因此需要注意一下。
1）Screens-》Add
Screen或者找到Screen并点击Configuration
如果你用了系统默认的Screen，没有定义Screen，那你需要定义各种Screen，因为你要增加字段嘛。
这里我建三个Screen，如Task
Create
Screen，Task
Edit
Screen，Task
Default
Screen。一个是创建的，一个是编辑的，一个是默认的。
2）调整Screen的现实字段和顺序
4这样就设置好了
前面设置了Create，Edit的Screen，所以创建和编辑都能看见。但是怎么解决解决时填写的问题呢。
在Workflow过程中的界面设置
解决时的界面是workflow的界面，和前面说的Create
Task，Edit
Task的界面是不一样的，需要在workflow的步骤中设置。
1因此先按照上面写的第3步骤增加界面，比如Task
Terminate
Screen。
只有两个字段，如下
Resolution
Description
2workflows-》选中一个流程Task
workflow的steps-》Transition下面选择Terminal
Task-》Edit
Terminal
3选择Transition
View为Task
Terminate
Screen就可以了。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）