Atlassian In Action-Jira之二次开发（五）
到现在已经写到了第五章节，实际上离Jira的官方系统已经越来越远，本章节的内容基本上已经完全脱离了Jira这个系统本身，而是依赖Jira的API接口和数据库进行开发了。主要包含如下几个功能：
- 人员任务排期管理
- 历史人员任务排期检查
- BI报表
注意：
由于我们的二次开发基本都是做成静态页面，但是大量使用了Jira的API接口，为了能够方便的使用。所以我们将这些页面放到Jira的容器当中，在其中建立了一个目录。这样就能够和Jira在同一个域名下，只要Jira系统有登录，访问接口都是不需要额外进行认证的。
人员任务排期管理
背景
这个页面的需求实际上是源自于BigGantt这个插件，我们前面讲过这是一个非常强大的插件，对于迭代的任务管理有很大的帮助。
但是在慢慢的使用过程中产生了一个管理的场景：有一个重点项目占用了一部分的研发力量，需要了解这部分的任务安排情况。并且当任务有变更的时候，能够快速了解是否还有研发资源可以安排调整。
分析之后我们了解到，实际上这个需求有两个重点，一要有一个任务列表（通常是一个JQL语句筛选出的主任务列表），二要有涉及的人力资源和子任务清单。BigGantt是否满足呢？它可以根据JQL筛选出任务列表，但是这个列表只能够以任务为视角展开。当我们需要评估某个人员排期如何，是否能够插入或者调整时，没有太好的界面来清晰的展示。
实现
所以我们设计了如下的功能：
可以看到这个界面分为三部分
第一部分是文本输入框，用于执行JQL语句。
第二部分是主任务列表。
第三部分是人力资源甘特图。
任务列表通过
https://jira.yourdomain.com/rest/api/2/search?jql=' + jqlstr + '&maxResults=9999
接口就可以获取任务的json数据。
人力资源甘特图是写了一个python脚本启动了一个web容器，从jira的底层数据库读取数据，组织返回json。获取的就是所有研发中心人员未完成的子任务。为什么要用python？因为Jira这台服务器上没有其他容器，如果要安装tomcat之类的太麻烦，还要做一个mvc框架之类的东西或者直接写jsp，太麻烦了。
下面给出获取数据的sql：
select concat(a.id) as pissueId,ifnull(concat("EXEPD-", k.issuenum),"无父任务") as pikey,k.SUMMARY as pisummary,concat("EXEPD-", a.issuenum) as ikey,'子任务' as itype,a.SUMMARY,b.pname,ifnull(ifnull(i.vname, e.customvalue), '版本为空') as vname,ac.last_name,ad.lower_parent_name,(case ad.lower_parent_namewhen 'org-pd-qa' then '测试'when 'org-pd-frontside-h5' then '前端h5'when 'org-pd-frontside-native' then '原生'when 'org-pd-serverside-b' then '业务'when 'org-pd-serverside-a' then '架构'when 'org-pd-product' then '产品UI'else '' end) as deptname,DATE_FORMAT(a.CREATED,'%Y-%m-%d') as creatdate,DATE_FORMAT(a.DUEDATE,'%m/%d/%Y') as enddate,DATE_FORMAT(cd.DATEVALUE,'%m/%d/%Y') as startdate,concat(ab.ID) as asid,concat(ad.parent_id) as dpid,concat(ROUND(ifnull(a.TIMESPENT,0) / 3600, 1)) as timespent,ab.lower_user_name asname,1 as numsfrom jiraissue ajoin app_user ab on ab.user_key = a.ASSIGNEEjoin cwd_user ac on ac.lower_user_name = ab.lower_user_namejoin cwd_membership ad on ad.lower_child_name = ab.lower_user_name and ad.lower_parent_name in('org-pd-frontside-h5','org-pd-frontside-native','org-pd-serverside-a','org-pd-serverside-b','org-pd-qa','org-pd-product')join issuestatus b on b.ID = a.issuestatusleft join nodeassociation f on f.SOURCE_NODE_ID = a.ID and f.ASSOCIATION_TYPE = 'IssueFixVersion'left join projectversion i on i.ID = f.SINK_NODE_IDleft join customfield c on c.cfname = '修正状态'left join customfieldvalue d on d.CUSTOMFIELD = c.id and d.ISSUE = a.IDleft join customfieldoption e on e.CUSTOMFIELD = c.ID and e.id = d.STRINGVALUEleft join customfieldvalue dd on dd.CUSTOMFIELD = 10400 and dd.ISSUE = a.IDleft join customfieldoption de on de.CUSTOMFIELD = 10400 and de.id = dd.STRINGVALUEleft join customfield cc on cc.cfname = '开始日'left join customfieldvalue cd on cd.CUSTOMFIELD = cc.id and cd.ISSUE = a.IDleft join issuelink j on j.DESTINATION = a.IDleft join jiraissue k on k.ID = j.SOURCEwhere a.issuetype = 10003and a.PROJECT = 10000and a.issuestatus != 10001and a.PRIORITY<=5order by ad.lower_parent_name,ac.last_name,cd.DATEVALUE这里面就涉及到对于Jira数据库的了解了，jiraissue 是issue的库，app_user 是人员库，cwd_membership是分组库，customfield 、customfieldoption 、customfieldvalue 是自定义字段的三件套。这个语句并不能直接在任何Jira系统上使用，因为里面有较多的自定义设置规则。
比如我们增加了开始日、修正状态两个自定义字段，而且定义了一种优先级是在当前的管理面板忽略的（所以才有 PRIORITY<=5 这个条件）。
有了任务列表和人力资源列表，我们就要把两者结合起来了。
首先我们使用的Gantt插件是JSGantt，这个插件还是很简单的。我们的甘特图是三层的，第一层是部门，第二层是人员，第三层是任务。为了在甘特图能够清晰的展示和任务的关系，我们循环所有人员的子任务，当父任务在第二部分的任务列表中时，在第一层的标题打一个星号，第二层打两个星号，第三次打三个星号，并且任务的甘特图显示为红色。除了无法拖拽修改任务排期，基本能够满足我们上述的需求了。这个图也变成目前我用于检查迭代和人员排期的最重要的工具。
历史人员任务排期检查
背景
所有人的任务都是在不断滚动的，每个人每天都面临至少四种任务：
- 计划性任务（长期）
- 插入性任务（长期或短期，紧急）
- 线上问题（重要紧急短期）
- Bug问题（重要不紧急）
所以作为管理人员要管理好研发资源就要妥善的协调任务安排，而且时候还要针对任务变更情况进行分析，对内部人员或者外部需求单位提出改进需求。
实现
这是一个管理需求，基于人员视角，观察一段时间区间内某个人员的任务变化情况并进行分析。
由于观察的区间并不确定，所以我们要将每个人每天的未完成子任务缓存，并且根据页面需要获取指定时间区间的子任务聚合。
先给出最终效果：
我们要做的事情：
- 定时任务用于每天定时保存未完成子任务
- 后台服务根据前端传入条件查询并且聚合任务信息
- 前端展示
定时任务使用python作为脚本，使用crontab凌晨执行，每次都以日期作为表名新保存一个表，脚本实际上使用人员任务排期管理中的sql，用 create table z_subtask_%date () 包起来就OK了。
服务端还是使用上面的python启动的web服务，增加一个接口。
最终界面主要视角为人员，字段包括：
- 主任务和子任务的信息
- 何时创建（确认何时接收到任务）
- 开始日期和结束日期，如果日期从未变化过则是一个日期，如果有调整则是日期区间
- 持续天数，是指这个任务有缓存在多少天的库中，即新建之后持续了多少天
- 最终状态，是指到查询截止日期这天，这个任务是否完成
这样我们能够基本来分析某个人员他的任务计划性和延迟性，沟通了解原因并且制定相应的优化方案。
BI
背景
每个组织一定会有分析需求，无论是内部改进或者整体汇报，能够有图表和数据表的完整呈现是最基本的要求。这个需求最早是尝试在Jira的插件中来寻找的，但是尝试了不少插件发现都达不到预期的效果，最终只能转入了使用第三方BI框架，底层数据源自己组织。
实现
选定的就是阿里云的QuickBI。
展示一部分效果图：
工时维度BI报表
迭代任务分析
有了BI工具，实际上报表制作成什么样就没有太大约束了。基本主要还是针对工时、迭代任务两部分的分析。
我提供给大家两份sql参考Jira的底层数据库组织数据的示例：
迭代任务组织：
select concat('C_', a.id) as pissueId,concat("EXEPD-", a.issuenum) as ikey,k.pname as itype,a.SUMMARY,sum((ifnull(a.TIMESPENT, 0) + ifnull(j.TIMESPENT, 0)) / 3600) as allTimeSpent,sum(ifnull(ll.timeworked, 0)) / 3600 as cuMonthTimeSpent,b.pname,ifnull(ifnull((case when i.vname='hotfix' then null else i.vname end) , e.customvalue), '版本为空') as vname,1 as nums
from jiraissue ajoin issuestatus b on b.ID = a.issuestatusleft join nodeassociation f on f.SOURCE_NODE_ID = a.ID and f.ASSOCIATION_TYPE = 'IssueFixVersion'left join projectversion i on i.ID = f.SINK_NODE_IDleft join customfield c on c.cfname = '修正状态'left join customfieldvalue d on d.CUSTOMFIELD = c.id and d.ISSUE = a.IDleft join customfieldoption e on e.CUSTOMFIELD = c.ID and e.id = d.STRINGVALUEleft join issuelink g on g.SOURCE = a.ID and g.LINKTYPE = 10100left join jiraissue j on j.ID = g.DESTINATIONjoin issuetype k on k.id = a.issuetypeleft join (select l.issueid, sum(ifnull(l.timeworked, 0)) as timeworkedfrom worklog lwhere date_format(l.STARTDATE, '%Y-%m') = '2019-06'group by l.issueid) ll on ll.issueid = j.ID
where a.issuenum in (1,2,3,4)and a.PROJECT = 10000
group by a.ID
工时分析：
select a.id,a.issueid,concat('C_', ifnull(n.SOURCE, a.id)) as pissueId,a.worklogbody,(a.timeworked / 3600) as wmin,(a.timeworked / 3600 / (case d.lower_parent_namewhen 'org-pd-qa' then 10when 'org-pd-frontside-h5' then 9when 'org-pd-frontside-native' then 5when 'org-pd-serverside-b' then 12when 'org-pd-serverside-a' then 7when 'org-pd-product' then 9else '' end)) as wminperm,date_format(a.STARTDATE, '%Y-%m-%d') as sdate,date_format(a.STARTDATE, '%Y-%m') as sdm,c.last_name,(case d.lower_parent_namewhen 'org-pd-qa' then '测试'when 'org-pd-frontside-h5' then '前端h5'when 'org-pd-frontside-native' then '原生'when 'org-pd-serverside-b' then '业务'when 'org-pd-serverside-a' then '架构'when 'org-pd-product' then '产品UI'else '' end) as deptname,k.pname,concat(h.pkey, '-', e.issuenum) as issuekey,concat('https://jira.exexm.com/browse/', h.pkey, '-', e.issuenum) as issueurl,(case j.pname when 'Sub-task' then '任务与子任务' when 'Task' then '任务与子任务' else j.pname end) as issuetypename,-- (case j.pname when 'Sub-task' then '子任务' when 'Task' then '任务' else j.pname end) as issuetypename,e.SUMMARY,-- ifnull(ifnull(i.vname, ifnull(m.customvalue,mm.customvalue)), '版本为空') as vname,i.vname,(casewhen(i.vname is null and (l.STRINGVALUE is not null or ll.STRINGVALUE is not null))then 'hotfix'when(i.vname is null or i.vname='')then '版本为空'whena.issueid = 10752then '日常事务'whena.issueid = 18019then '规划外事务'else i.vname end) as cord
from worklog ajoin app_user b on b.user_key = a.AUTHORjoin cwd_user c on c.lower_user_name = b.lower_user_namejoin cwd_membership d on d.lower_child_name = b.lower_user_name and d.lower_parent_name in('org-pd-frontside-h5','org-pd-frontside-native','org-pd-serverside-a','org-pd-serverside-b','org-pd-qa','org-pd-product')join jiraissue e on e.ID = a.issueidleft join nodeassociation f on f.SOURCE_NODE_ID = e.ID and f.ASSOCIATION_TYPE = 'IssueFixVersion'left join projectversion i on i.ID = f.SINK_NODE_IDjoin issuetype j on j.id = e.issuetypejoin project h on h.ID = e.PROJECTleft join issuelink n on n.DESTINATION = e.ID and n.LINKTYPE = 10100join issuestatus k on k.ID = e.issuestatusleft join customfieldvalue l on l.CUSTOMFIELD = 10025 and l.ISSUE = n.SOURCEleft join customfieldoption m on m.CUSTOMFIELD = 10025 and m.id = l.STRINGVALUEleft join customfieldvalue ll on ll.CUSTOMFIELD = 10025 and ll.ISSUE = e.IDleft join customfieldoption mm on mm.CUSTOMFIELD = 10025 and mm.id = ll.STRINGVALUE
where a.STARTDATE >= '2019-1-1'
order by a.STARTDATE asc
总结
写到这里，所有关于Jira的使用的整理目前告一段落了。但是这应该还只是一个阶段性里程碑而已，我们的组织架构在进步，过程管理方法在进步，Atlassian也在进步，所以我们也不能停下自己的脚步。Jira还只是完整生态当中的一个环节，我们要更好的组织我们的研发团队，后面还有一些伙伴给大家介绍。一个企业、研发团队要能长久的生存和提高，就需要积累，但是不能口口相传，还要能进行阶段性的梳理和提高。下一章就是企业如何使用Confluence进行知识积累。
Atlassian In Action-Jira之二次开发（五）相关推荐
- Atlassian In Action - （Atlassian成长之路）
Atlassian In Action - (Atlassian成长之路) Atlassian是我工作过程中,使用过的最满意的研发团队管理套装.使用的主要软件包括Jira Software,Confl ...
- 哪个项目管理工具好用到哭？JIRA VS 华为软件开发云
一.产品介绍 JIRA是Atlassian公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪.客户服务.需求收集.流程审批.任务跟踪.项目跟踪和敏捷管理等工作领域. 华为软件开发云 (DevCloud ...
- Saiku二次开发获取源代码在本地编译（五）
关于Saiku的二次开发,在本地编译然后启动自己编译好的Saiku服务 Saiku是开源的,从github上能下载源代码,本例中的saiku源码也是从github上找的,然后自己改了一些pom.xml ...
- 二次开发photoshop_Photoshop 101：Web开发人员简介
二次开发photoshop 介绍 (Introduction) Often, when working as web developer, we need to integrate templates ...
- 最土团购系统数据结构数据字典二次开发宝典
1 card 代金券 ID 代金券 id 识别码 code ID 商户 partner_id ID 商品 team_id ID 订单 order_id 代金券金额 credit 是否使用过 consu ...
- JMeter进阶系列01--JMeter二次开发
JMeter二次开发--实现配置和运行UI自动化测试 JMeter版本:3.3 JMeter下载地址: https://archive.apache.org/dist/jmeter/binaries/ ...
- phpcms v9二次开发之模型类的应用(1)
在<phpcms二次开发之模型类model.class.php>中讲到了模型类的建立方法,接下来我讲一下模型类的应用. 前段时间我基于phpcms v9开发了一个足球网.足球网 ...
- phpcms v9二次开发及使用中各种问题解决方案(一)
phpcms v9二次开发及使用中各种问题解决方案(一)模板调用1.内容标签,序号123456789的调用?{pc:contentaction="lists"catid=" ...
- DZ各个数据表详解（DZ论坛各表详细说明，二次开发用）
DZ各个数据表详解(DZ论坛各表详细说明,二次开发用) DZ默认库的53个数据表 cdb_access (用户权限表) uid 用户id fid 论坛id allowview 允许浏览 allowpo ...
最新文章
- 神经网络压缩方法：模型量化的概念简介
- 2021年高考，26地公布高考出分时间
- 抗震求灾捐款,我们公司总额为:14222
- 第2章 网页基础知识
- python实现ai聊天机器人_AI人工智能Python实现简单人机对话：你好，人类！
- Mac OSX上安装Python的方法
- double类型字符串转换成一个纯数字字符串和一个小数点位数的c++代码
- java底层 文件操作,java底层是怎的对文件操作的
- Rocket - decode - 最小项与最大项
- STM32程序中使用printf打印中文字符乱码
- mysql没有makefile_编译安装mysql，找不到makefile
- 怎样用计算机编码出文字,计算机汉字编码主要有哪些方式
- 驿路梅花处处开 --- 梅语
- Detecting Photoshopped Faces by Scripting Photoshop笔记
- CSS / 清除浮动+切图+属性书写顺序+页面布局思路
- python中格式化字符串的使用_Python中的格式化字符串
- 重复率30%可以通过论文查重吗？
- 数据挖掘经典十大算法_对基本概念的理解
- PAT甲级 1151 LCA in a Binary Tree (30分) LCA算法/C++
- 毕业设计-基于 MATLAB 的图像分割算法研究及实现