工作中遇到Jira使用细节，在这里记录探讨和明确Jira使用过程中的两个问题
问题如何结束
问题包括人物，技术改造，BUG等细项。发起者是系统开发人员，产品经理，测试人员等所有的项目参与人员。执行者是对应的执行者，可以责任到人，指定唯一。
这里的问题结束指 不显示在登录者的面板中
主要关系到问题的两个属性 1）状态 2）解决结果
如果你的“分配给我的” 问题并没有上边这个图片这么清净的话那么：
1. 你该及时处理你头上分配的问题了。
2. 你的问题虽然已经关闭但是还是显示在这里，这时候请编辑对应的问题的“解决结果” 将其设置完成。对应的问题就不会再你的dashboard中显示了。
长期运行的jira项目中，会出现很多难于关闭的问题，主要原因有几个
首先是责任问题，每次版本上线偶尔会遗留一些看似很重要，但是不会被继续跟踪或者修复的bug，产品缺陷，久而久之形成脏数据，没有人愿意跟踪，并为这个问题的关闭负责任。一个研发团队过度强调责任规定，就会遇到脏数据原来越多的困扰。
这时候，不妨使用敏捷开发的box模型理论，敏捷开发中把发布周期定位2到3周，认为是一个box，而box内的既定工作，时间一到，就应该结束，或者说都应该有定论。要么关闭不处理要么转为下个版本强行处理，不然就是越拖越没有人管。
工作工时的计算及价值
测试人员提交的问题的开发工时，最后是计入问题解决者，还是计入测试人员。总之来说，计算工时这个事是不靠谱的，各个操作者的能力不同，认知不同，造成的时间评估就是不确定的，再加上不可控因素太多，在一个团队中的推行成本很大。
之前不理解不靠谱的事情为什么还要去做，或许是站的思考维度不一样，对于普通工程师来说，认为录入工时是费事且不准确的，但是对于管理层的管理者来说，需要依据这样的数据来评估整个部分的工作时间和投入产出，或者人员成本投入的大致趋势。可以允许不准确和偏差，确不允许完成没有这项指标。
是不是可以用【If you can’t measureit ，you can’t improve it】来解释？
