【项目管理】在Jira中关闭问题

工作中遇到Jira使用细节,在这里记录探讨和明确Jira使用过程中的两个问题

问题如何结束

问题包括人物,技术改造,BUG等细项。发起者是系统开发人员,产品经理,测试人员等所有的项目参与人员。执行者是对应的执行者,可以责任到人,指定唯一。

这里的问题结束指 不显示在登录者的面板中

【项目管理】在Jira中关闭问题_第1张图片

主要关系到问题的两个属性 1)状态 2)解决结果

如果你的“分配给我的” 问题并没有上边这个图片这么清净的话那么:

1. 你该及时处理你头上分配的问题了。

2. 你的问题虽然已经关闭但是还是显示在这里,这时候请编辑对应的问题的“解决结果” 将其设置完成。对应的问题就不会再你的dashboard中显示了。

长期运行的jira项目中,会出现很多难于关闭的问题,主要原因有几个

首先是责任问题,每次版本上线偶尔会遗留一些看似很重要,但是不会被继续跟踪或者修复的bug,产品缺陷,久而久之形成脏数据,没有人愿意跟踪,并为这个问题的关闭负责任。一个研发团队过度强调责任规定,就会遇到脏数据原来越多的困扰。

这时候,不妨使用敏捷开发的box模型理论,敏捷开发中把发布周期定位2到3周,认为是一个box,而box内的既定工作,时间一到,就应该结束,或者说都应该有定论。要么关闭不处理要么转为下个版本强行处理,不然就是越拖越没有人管。


工作工时的计算及价值

测试人员提交的问题的开发工时,最后是计入问题解决者,还是计入测试人员。总之来说,计算工时这个事是不靠谱的,各个操作者的能力不同,认知不同,造成的时间评估就是不确定的,再加上不可控因素太多,在一个团队中的推行成本很大。

之前不理解不靠谱的事情为什么还要去做,或许是站的思考维度不一样,对于普通工程师来说,认为录入工时是费事且不准确的,但是对于管理层的管理者来说,需要依据这样的数据来评估整个部分的工作时间和投入产出,或者人员成本投入的大致趋势。可以允许不准确和偏差,确不允许完成没有这项指标。

是不是可以用【If you can’t measureit ,you can’t improve it】来解释?

你可能感兴趣的:(【项目管理】在Jira中关闭问题)