今第五章に書かれており、実際には、のJIRAシステムからの公式がますます遠くなってきた、この章の内容は、基本的には完全にのJIRAシステム自体の外にあったのではなく、開発されたのJIRA APIインターフェースとデータベースに依存しています。主に以下の機能が含まれています。
- 人事管理タスクスケジュール
- 過去のミッション要員の飛行検査
- BIレポート
注意：
私たちは基本的に使用を容易にするために、二次静的なページの開発が、広範な使用のJIRA APIインタフェースで作られているので。だから我々は、ディレクトリの中に設立のJIRAコンテナの中でこれらのページを配置します。これは、限りのJIRAシステムのログインなど、アクセスインタフェースは、追加の認証されていない、それが可能JIRAと同じドメイン名になります。
人事管理タスクスケジュール
背景
これは非常に強力なプラグインの反復タスク管理のためには非常に有用であるである前に、このページのニーズが実際にBigGanttこのプラグインに由来し、我々は述べています。
しかし、経営者が使用中に徐々にシーンがあった：キープロジェクトはR＆Dの一部を占領し、ミッションの手配のこの部分を理解する必要があります。R＆D資源があるかどうかをすぐに見つけることを使命時間の変更があるときに調整するように構成することができます。
分析の後、我々は実際には、二つの重要なニーズがあることを、タスクリストは、（通常はマスタータスクリストJQL文をスクリーニング）していると、人的資源とサブタスクは、2つの関与しているリスト、ということを学びました。BigGanttが満足かどうか？それはJQLタスクリストに基づいてフィルタリングすることができますが、このリストには、タスクの視点を拡大することができるだけです。私たちはどのように人事のスケジュール、または調整を挿入することができるかどうかを評価する必要がある場合は、表示をクリアするためには良いインタフェースがありません。
実現
だから我々は、次の機能を設計しました：
このインタフェースは、3つの部分に分かれている見ることができる
最初の部分のことJQLステートメントを実行するために、テキスト入力ボックスです。
第二部は、メインタスクリストです。
第3の部分は、人的資源ガントチャートです。
によってタスクリスト
https://jira.yourdomain.com/rest/api/2/search?jql=' + jqlstr + '&maxResults=9999インターフェースは、JSONデータのタスクを取得することができます。
人的資源ガントチャートは、基礎となるデータベースJIRAからデータを読み取るために、Webコンテナを起動するPythonスクリプトを書くことで、組織は、JSONを返しました。すべてのサブタスクR＆Dセンターのスタッフが未完成取得することです。なぜのpythonを使うのか？あなたはあまりにも多くの問題が、また、書き込みまたは直接JSPのようなものを行うためのMVCフレームワーク、あまりにも多くの問題のようにTomcatをインストールする場合はJiraに他の容器、このサーバーは、ありませんので。
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_name
when '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 nums
from jiraissue a
join app_user ab on ab.user_key = a.ASSIGNEE
join cwd_user ac on ac.lower_user_name = ab.lower_user_name
join 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.issuestatus
left 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_ID
left join customfield c on c.cfname = '修正状态'
left join customfieldvalue d on d.CUSTOMFIELD = c.id and d.ISSUE = a.ID
left join customfieldoption e on e.CUSTOMFIELD = c.ID and e.id = d.STRINGVALUE
left join customfieldvalue dd on dd.CUSTOMFIELD = 10400 and dd.ISSUE = a.ID
left join customfieldoption de on de.CUSTOMFIELD = 10400 and de.id = dd.STRINGVALUE
left join customfield cc on cc.cfname = '开始日'
left join customfieldvalue cd on cd.CUSTOMFIELD = cc.id and cd.ISSUE = a.ID
left join issuelink j on j.DESTINATION = a.ID
left join jiraissue k on k.ID = j.SOURCE
where a.issuetype = 10003
and a.PROJECT = 10000
and a.issuestatus != 10001
and a.PRIORITY<=5
order by ad.lower_parent_name,ac.last_name,cd.DATEVALUE
これは、Jiraのためのデータベースの内部を知る必要、jiraissueは、APP_USERライブラリは人員のライブラリの問題であるが、cwd_membershipは、パケットライブラリ、たCustomField、customfieldoptionで、customfieldvalueはスリーピースのカスタムフィールドです。設定をカスタマイズするために複数のルールがあるので、この文は、直接、任意ののJIRAシステムではありません。
たとえば、私たちは、開始日、改正状態の2つのカスタムフィールドを増加し、無視され、現在の管理パネル（これだけPRIORITY <= 5この状態）に優先順位を定義します。
タスクリストと人的資源のリストで、我々は一緒に2を入れました。
まず、我々はプラグインを使用しているガントJSGanttを、このプラグインは非常に簡単です。私たちのガントチャートを3層である、第1層は、第2層は、第3層は仕事で、スタッフである、部門です。ガントチャートでの順序関係で明確に実証し、作業することができ、サブタスク我々サイクルのすべての関係者、第二のセクションのタスクリスト内の親タスク、アスタリスクを再生する第一層のタイトルは、第2層の戦い2つのアスタリスクは、第三のアスタリスクをヒットし、ガントチャートタスクは赤で示されています。ドラッグに加えて、タスクのスケジュールを変更することはできません、我々は基本的に上記のニーズを満たすことができます。この図は、私が現在の反復と飛行の人員をチェックするために使用される最も重要なツールとなっています。
過去のミッション要員の飛行検査
背景
すべてのタスクは常に誰もが少なくとも4つの毎日の仕事に直面している、ローリングされています。
- 計画タスク（長期）
- タスクを挿入します（長期または短期、緊急）
- オンラインの問題（重要かつ緊急の短期）
- バグの問題（重要緊急ではありません）
だから、R＆D資源必要なタスクの適切な調整のための取り決めが、また、状況の変化を分析するためのタスクのための時間を管理するための管理者として、社内スタッフや外部ユニットの需要は改善の必要性を提案しました。
実現
これは、人員や、分析の範囲内の期間にわたって変更されたミッションを観察する人材の視点に基づく管理のための需要が、です。
間隔の観測が不確実であるため、私たちは誰も未完成のサブタスクが毎日をキャッシュして、ページに応じてサブタスク指定された時間間隔に必要な重合を取得します。
最終的な結果を与えるために：
我々は実行する必要があります。
- 定期的なタスクは、一日あたりのサブタスクを保存するためのタイミングを完了していません
- バックグラウンドサービスのフロントエンドのクエリと入ってくるジョブ情報の集約の条件
- 前面表示
スケジュールされたタスク、使用のcrontab早朝の実行、テーブル名の新しい日付がテーブルを保存するたびとしてPythonスクリプトを使用して、スクリプトが実際に使用して人事管理タスクのスケジュールを、SQLでOKに包ま）（表z_subtask_％の日付を作成し使用しますA。
サーバまたは上記開始PythonのWebサービスの利用には、インターフェイスを追加します。
要員のための最終的なメインインターフェースの視点、フィールドが含まれます。
- マスタタスクとサブタスク
- （タスクを受信したときに確認）を作成するとき
- 日付が日付変更がなかったされている場合、日付範囲を調整することがある場合は、日付を開始と終了
- 数日間、このタスクは新後何日も続いたライブラリーの日数、内にキャッシュされたことを意味
- 最終状態は、このタスクが完了すると、クエリの締切日を指し、
このように、我々は彼の基本的なミッションプランを分析し、スタッフを遅らせ、かつ適切なコミュニケーションと最適化の原因を理解することを開発することができます。
WITH
背景
各団体提示し、完全なデータチャートとテーブルを持つように、内部またはが全体のレポートを改善するかどうか、分析ニーズを持っている必要がありますが、基本的な要件です。この需要はまず、我々は唯一のサードパーティBIフレームワーク、自分自身を整理するための基礎となるデータソースの使用を転送することができ、見つけることが、所望の効果を達成していないプラグインの多くを見つけようとするのJIRAプラグインにしようとしました。
実現
アリ雲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 a
join issuestatus b on b.ID = a.issuestatus
left 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_ID
left join customfield c on c.cfname = '修正状态'
left join customfieldvalue d on d.CUSTOMFIELD = c.id and d.ISSUE = a.ID
left join customfieldoption e on e.CUSTOMFIELD = c.ID and e.id = d.STRINGVALUE
left join issuelink g on g.SOURCE = a.ID and g.LINKTYPE = 10100
left join jiraissue j on j.ID = g.DESTINATION
join issuetype k on k.id = a.issuetype
left join (select l.issueid, sum(ifnull(l.timeworked, 0)) as timeworked
from worklog l
where 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_name
when 'org-pd-qa' then 10
when 'org-pd-frontside-h5' then 9
when 'org-pd-frontside-native' then 5
when 'org-pd-serverside-b' then 12
when 'org-pd-serverside-a' then 7
when 'org-pd-product' then 9
else '' 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_name
when '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,
(case
when
(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 '版本为空'
when
a.issueid = 10752
then '日常事务'
when
a.issueid = 18019
then '规划外事务'
else i.vname end) as cord
from worklog a
join app_user b on b.user_key = a.AUTHOR
join cwd_user c on c.lower_user_name = b.lower_user_name
join 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.issueid
left 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_ID
join issuetype j on j.id = e.issuetype
join project h on h.ID = e.PROJECT
left join issuelink n on n.DESTINATION = e.ID and n.LINKTYPE = 10100
join issuestatus k on k.ID = e.issuestatus
left join customfieldvalue l on l.CUSTOMFIELD = 10025 and l.ISSUE = n.SOURCE
left join customfieldoption m on m.CUSTOMFIELD = 10025 and m.id = l.STRINGVALUE
left join customfieldvalue ll on ll.CUSTOMFIELD = 10025 and ll.ISSUE = e.ID
left 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进行知识积累。