目录前端
道生之,德畜之,物形之,势成之。 --《道德经》后端
Jira的道在于构建了整个环境和思惟模式,也赢得了市场的承认,成了一种势。无数的厂家便成了Jira的海洋生态当中的重要组成部分。有些厂家的插件是提高了Jira的体验,有些则是强化了特定功能。这里只推荐三个算得上必须使用的插件。工具
围绕这三个插件,咱们可以搭建起研发管理的总体路线和迭代管控视图,简化流程,完善管理制度。接下来就介绍每一个插件的场景和使用方式。post
咱们经过一张图造成一个大概的印象测试
咱们当时选择这个插件指望知足的场景有下面几个:优化
咱们项目管理经常使用的软件就是微软的Project,因此咱们选项目标也是按照这样的思路来挑选的。最简化的概念就是甘特图。插件
当中有设置的必要的应该是Working schedule了
设计
设置放假和周末,这样在计算任务起止的时候可以在甘特图中正确的显示,其余我没有作过多的设置。3d
从上图能够看出甘特图的组织形式分为4层。excel
在甘特图的界面能够进行任务的管理。
能够拖动任务的两端进行开始和截止日期的调整,也能够直接拖动整个任务进行任务的调整。
任务的进度是经过下面的三角标识进度,这个计算是使用实际投入的工时与预计工时直接的比例。
蓝色的线是在日期栏直接左击,就能够设置一个时间线,默认是设置在选择日期的开始。能够用于设置迭代里程碑。
显示内容的设置界面以下:
能够看到有四种方式能够混合使用:
任务列表界面上元素都是能够根据实际系统中设置的字段进行调整的,以下图所示:
绿色的是自定义字段,灰色的是系统字段。自定义字段基本都是单纯的显示,系统字段会有一些其余的效果。
这个插件在前端没有任何感知,知道Jira系统中存在这个插件的基本也只有管理员了。可是对于管理员来讲,这是流程推动、串联的最重要的工具了。
它的做用是在工做流的流转过程当中能够附加其余的操做,列表以下:
能够看到主要有赋值、分配人员、评论、触发其余流转环节、自定义脚本等等,并且能够针对问题自己、父问题、关联问题。基本可以涵盖平常应用的场景了。
我讲一下我实践过程当中,比较经常使用的几种场景:
使用到 Assign to last role member 或者 Assign to role member 。场景例如bug,当测试发现一个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当前最新是9.4.2版本,我使用的是8.15.3 。我尝试升级过一次插件,结果你们都不习惯新的界面,我不得不退回老版本。
全局配置中有几点说明,咱们是子任务驱动因此工时不容许记录在父任务。可是只有一个任务下有子任务的时候才是父任务,不然就能够记录工时。
Work Attributes是设置工时填写面板的自定义字段
注意:这里的字段只有经过记录工时按钮呼出的界面才有,好比完成任务时填报工时的界面是没有自定义字段的。
v9去掉的就是这个工时表,这个基本上是咱们最经常使用的功能了。因此去掉以后你们都不知道怎么用了。
用户这个地方的下拉框能够选择以下几种选项。其中比较难理解的是帐户这个概念,tempo里面其实是有成本概念的,就是经过帐户当中的金额来管理,不过咱们没有使用过。
经常使用的几个是用户(分析单个用户的工时分布),团队(每一个小组总体任务工时分布),高级(指定过滤器查看任务工时分布),问题(查看单个问题的人员工时分布)
时间区间能够任意指定,查询出的结果能够直接导出excel用于作透视图之类的。
v9主推的就是Reports操做的内容和界面形式应该是更加优化,上面的时间区间、过滤器设置(能够多选),分组能够多选和排序。
这个咱们用的比较少,主要会针对某个具体问题、或者较大的Epic相关的项目站会、总结会时,分析人员工做进度和使用。
上述三个插件加入到Jira以后,咱们完成了迭代总体控制、工做流实施、研发管理规范与提高三方面配置,基本已经能够开始组织一个研发团队为了同一个既定目标按照统一规范流程进行开发,并且尽可能简化过程下降研发非研发类工做的占比。可是咱们仍是可使用一些其余的插件来提升研发管理总体效率。另外必须说一句,这些插件的仪表盘可用插件没一个能用的。