この記事は、前の記事「ApacheNiFiを使用したJiraAnalyticsの自動化」の拡張です。ここで、Jira Softwareに関するレポートの見方と、Rを使用した実装の経験について詳しく説明したいと思います。もちろん、ここでの言語は教義ではありません。今日、私たちのすべては概念です。 写真はここで借りています。
タスクトラッカーを想像してみましょう。アナリストとして、そこからどのようなデータを抽出できますか？または、既製の分析プラットフォームはありますか？期間中のタスクの数、ログの統計、プロジェクトへの基本的な内訳、従業員の生産性に関するいくつかの写真...そしてそれだけです。
しかし、行われることはすべて太ります。したがって、おそらくもっとグローバルなもの、つまりチームが何をしていて、どの方向に進んでいるのかを特定することができます。
はい、やりました。しかし、それは最初に首相の助けなしではありませんでした。
タスクトラッカーの再編成
もちろん、それぞれの特定のジラは他のものとは大きく異なります。そして、私たちのソリューションはあなたにとって最も効果的ではないかもしれませんし、まったく適用できないかもしれません。
私たちのアウトソーシング会社の例を使用して、これをタスクトラッカーを編成するというアイデアとしてのみ見なしてください。
私たちはたった2つの動きをしました。
最初で最も単純です。もちろん、彼らは一方向のすべてのタスクが叙事詩に結び付けられるべきであることを受け入れました。エピックはジラで最大のオブジェクトであり、複数の問題を表しています。それらは階層と構造を構築するのに役立ち、複数のスプリントとバージョンにまたがることもできます。
2番目についてもう少し。全体像を見て、戦略的な質問に答えることができます。ワークフローは、各従業員が貢献する一種のフローとして提示されます。このため、私たちの場合、IT4ITの概念は理想的に適しており、その運用モデルは4つのストリームのバリューチェーンに基づいています。 実際、私たちは何をしましたか。IT4ITを活用して、タスクコンポーネントなどをJiraに追加しました。次のものがあります。
- ポートフォリオへのサービス（需要と選択） -「カット」、検索、サービスの選択、テクノロジーの段階。
- 展開のリクエスト（計画と設計） -ディスカッション、開発の計画、サービスの開発、サービス。
- 展開のリクエスト（開発） -サービスの開発、何かのサービス。
- デプロイのリクエスト（デプロイ） -何かのデプロイ。
- デプロイのリクエスト（テスト） -サービス、サービスをテストします。
- 履行の要求-開発されたサービスを運用し、サービスを提供する段階。
- Detect to Correct（Correct） -内部サービスおよびサービスの修正、改良。
- 検出して修正（監視とフィードバック） -同じことですが、+クライアントとの通信のみです。
この段階でおそらく最も難しいのは、トラッカーの余分なアイテムは無料ではなく、正しく入力する必要があることを従業員に納得させることです。
Rでのデータ分析
これで、レポートの実装に支障はないはずです。 TKの類似性を定式化します。
毎週の初めにチームは計画のためのミットのために集まるので、レポートは毎週でなければなりません。タスクの外観と進行状況、従業員のログ記録、および全体像に対する各従業員の貢献度に関する統計を確認することが重要です。質問に答えてください：エピックとコンポーネントの観点から、チームは何をしていますか。
何を取得する必要があるかを知って、データをアンロードします。 Jira APIを通じて、先週更新されたすべての問題（問題）をリクエストします。それらからキーを抽出し、各タスクのログ履歴（worklog）と変更履歴（changelog）をロードします。アピッシュの制限を回避するには、オーバーロードを伴う倒錯が必要です。
次に、受信したデータの前処理がレポート生成スクリプトのコンポーネントであるため、責任Rの領域が始まります。
賢いものは何もありません。apiから取得したJSONを解析し、必要なプロパティ（Jiraのアイテム）のみを残す必要があります。唯一の瞬間、変更ログを処理するとき、タスクステータスの変更のみに関心があり、残りは安全に削除できます。
そして最後に、分析に取り掛かりました。
過去1週間に開始、進行中、終了、延期されたタスクの数を確認します。 Rコードを見てください：
#
this_week_opened <- jira_changelog_data %>%
filter(issue_type != "Epic") %>%
filter(as.Date(issue_created) >= start_date) %>%
filter(as.Date(issue_created) <= end_date) %>%
select(key, issue_created) %>% unique() %>% nrow()
#
this_week_processed <- jira_worklog_data %>%
filter(as.Date(started) >= start_date) %>%
filter(as.Date(started) <= end_date) %>%
select(key) %>% unique() %>% nrow()
#
this_week_closed <- jira_changelog_data %>%
filter(issue_type != "Epic") %>%
filter(as.Date(issue_resolutiondate) >= start_date) %>%
filter(as.Date(issue_resolutiondate) <= end_date) %>%
select(key, issue_created) %>% unique() %>% nrow()
# /
this_week_holded <- issue_history %>%
filter(change_date >= start_date) %>%
filter(change_date <= end_date) %>%
filter(toString == "Hold" | toString == "Backlog") %>%
select(key) %>% unique() %>% nrow()これは疑似コードを思い出させますか？そして、演算子 ' ％>％ 'が前の関数から次の関数にデータを転送すると言うと、そして、チェーン全体の最後の変更は変数に保存されます。想像してみてください、私たちはちょうどRへの参入のしきい値に達しました！
あなたはもう彼と恋に落ちましたか？次に、必要に応じて、さらに情報を追加します。
ウィキペディアからの言葉：
一般に、プログラミング言語として、Rは非常に単純で原始的ですらあります。その最大の強みは、パッケージによる無制限の拡張です。
基本的なR配信には、基本的なパッケージセットが含まれており、2019年の時点で、合計で15,316を超えるパッケージが利用可能です。
そして今日の最後のこと。今年、Rは世界で最も人気のあるトップ10の言語に突入しました（証拠）。私は彼を誇りに思っています。
この後退を許してください。私はRについて何時間も話すことができます。彼が神話に完全に包まれているというだけで、私はそれらを破壊するのが大好きです-趣味です。
レポートに戻りましょう。必要な数があれば、それらを視覚化します。その後、従業員のログを作成します。これは、この部分が私たちにどのように見えるか です。同じ実際のレポートからの最終的な画像を引き続き表示します。 私たちの事業は次のグラフに反映されています。また、運用活動を行っている従業員の作業負荷を評価することもできます。 そして、これがコンポーネントごとのすべてのタスクの内訳です。彼は私たちが何をしているのかという質問に答えます。写真を数字で補足します。
さて、上記の全体像に対する各従業員の約束された貢献。
私たちの開発者がどこにいて、管理者がどこにいるのかすぐにわかると思います。私たちはこの明快さを目指して努力していました。 実際のレポートには、タスクの動きの要約も補足されています。これは、最初に投稿された一般的な統計への追加であり、タスクの名前と責任者の名前が含まれています。
レポートの生成
たとえば、月曜日にRスクリプトから自動レポート生成を設定するには、cronRパッケージを使用できます。これは非常に簡単です。
私たちの場合、すべてがより複雑でエレガントです。ApacheNiFiを使用して毎週JiraAPIからデータをダウンロードし、レポート生成スクリプトを実行して、すべての従業員に電子メールでレポートを送信しました。このトピックは非常に広範囲にわたるため、別の記事に値します。
結論
Jira Softwareの実装の数、およびそれが使用されている企業の数はたくさんあります。同時に、各ボスは、戦術的に正しい管理のために独自のメトリックベースを必要とします。はい、Jira分析用のeazyBIやその他のプラグインがありますが、その結果は、カスタムのビスポークではなく、ストアでスーツを購入するようなものです。
検討対象のレポートは、テンプレートに従って縫製されます。上司によると、それはユニットまたはチームが何をしているかの戦略的なビューを提供します。この記事が、自宅で同様のことを実装するのに役立つことを願っています。
ありがとう。