DevOps ダッシュボードでデータ パイプラインを最大限に活用する
DevOps ダッシュボード テンプレートでは、データ パイプラインで可能な操作を簡単に確認できます。このテンプレートは、エンジニアリング チームの健全性に関する有用なインサイトを提供します。また、独自のダッシュボードやレポートを作成する際に最適な出発点となることを想定されています。
次のテンプレートをダウンロードします。
On this page:
データ パイプラインにおける人、プロジェクト、課題に関する包括的なデータによって、マネージャーとビジネス リーダーは作業の生産性、品質、応答性、予測可能性の傾向を識別できます。Jira UI は作業の完了に重点を置いていますが、このようなダッシュボードやレポートからはマクロ レベルのインサイトが得られます。
このガイドでは、含まれているメトリック、その計算方法、チームについて意味することについて一部説明します。
テンプレートを独自のデータ ソースにすぐに接続する場合は、次をご参照ください。
DevOps ダッシュボードの概要
Tableau の DevOps ダッシュボードには、次のように、テンプレートに含まれているサンプル データが入力されています。
- プロジェクトの要約には、ダッシュボードで取り上げられているプロジェクト (またはカテゴリ別の集計を選択した場合はプロジェクト カテゴリ) がリストされて、プロジェクトに割り振られているリソースの割合 (チーム メンバーによってクローズされた課題で測定) が表示されます。また、このリストは、特定のプロジェクトまたはプロジェクト カテゴリのデータをドリル ダウンして表示する場合に、レポートのフィルターとして機能します。
- 割り当てメトリックでは、レポート期間中にプロジェクトまたはプロジェクト カテゴリに毎週割り当てられた、各プロジェクト宛てのリソースの割合 (チーム メンバーによってクローズされた課題によって測定される) を示します。
- 品質メトリックには、すべてのプロジェクトまたはプロジェクト カテゴリの品質、応答性、生産性、予測可能性のメトリックがグラフで表示されます。
- ダッシュボード設定では、日付範囲、プロジェクトまたはプロジェクト カテゴリの集計、課題タイプなど、ダッシュボードに含めるデータを構成します。
- 品質の要約には、4 つの品質メトリックの値のプロジェクトごとの集約値が表示されるため、外れ値やシステムの問題 (あるいは成功) の特定に役立ちます。
DevOps メトリックの詳細
以下の説明では、ダッシュボードのデータがプロジェクト別に集計されていると仮定しています。ただし、プロジェクト カテゴリ別にも集計できます。概念はどちらのオプションでも同じです。
割り当て
DevOps ダッシュボードのプロジェクト割り当てセクションには、プロジェクトに振り分けられている自分のチームの割合が表示されます。このデータは、最も重要なプロジェクトのカバレッジを確保する際に役立ちます。
計算方法
Data Center アプリには「チーム」の概念がないため、ユーザーによってクローズされた課題をプロキシとして使用しています。プロジェクト内の課題をクローズしたユーザーを、そのプロジェクトの目的上「チーム メンバー」として扱います。レポートをフィルタリングして、チームや部署の特定のユーザーのみを含められます。
割り当てが労力や消費時間を示すものではないことにご注目ください。割り当ての測定方法を説明する最良の方法として、いくつかの例を挙げます。
指標は何を示しているのですか?
この指標はトレンドを特定して、ビジネスにとってより重要度の高いプロジェクトに人員を再配置できる場所を確認する際に役立ちます。
また、このデータは、他のダッシュボード データと組み合わせて使用して、割り当てレベルの上げた場合と下げた場合の他のメトリックに対する影響を確認できます。
2 つのプロジェクトの割り当てメトリックを示すスクリーンショット
品質 (欠陥)
DevOps ダッシュボードでは、エンジニアリングの健全性の観点から品質にアプローチしています。チェックしないままにすると、技術的負債によって、高品質のソフトウェアを提供するチームの能力に影響が及びます。新機能に関する作業よりも不具合の修正を優先する方法を調べることによって、エンジニアリングの健全性の問題を示している可能性がある傾向を特定できます。
計算方法
品質 = 解決済みの不具合 / 解決済み課題の合計 x 100
簡単に言えば、特定の週に解決されたすべての課題のうち、バグやその他の「不具合」課題タイプの割合を計算します。私たちは製品またはエンドユーザー エクスペリエンスの品質ではなく、エンジニアリングの健全性指標に重点を置いています。
ダッシュボードの設定で、「不具合」として扱う課題タイプを定義できます。たとえば、バグ、アーキテクチャ技術負債、テストの失敗などのさまざまな課題タイプがある場合は、ダッシュボードですべてを「不具合」として分類できます。
指標は何を示しているのですか?
安定した線は、チームが技術的負債と新機能に関する作業のバランスを取っていることを示しています。これは、エンジニアリングの健全性が良好な安定したシステムの指標です。
(以下の例のように) 線が上昇傾向になり始めた場合は、開発者がプロジェクトの終わりまで不具合に関する作業を遅らせているか、チームの焦点が新機能に関する作業に移行したことを示している可能性があります。
ラインが下降し始めると、開発者が十分な注意を払っていないバグが存在している場合があり、将来的に品質の問題が発生する可能性があります。
鋭い山や谷がたくさんある場合は、精査してそれらの週に何が起こっていたのかを調べることをお勧めします。インシデントやリリースの締め切りなど、チーム固有のコンテキストを見逃している場合があります。また、特定のプロジェクトでダッシュボードをフィルタリングして、傾向がすべてのプロジェクトの集計と著しく異なっていないかどうかを確認することをお勧めします。
すべてのプロジェクトと比較したあるプロジェクトの品質 (不具合) チャートを示すスクリーンショット
応答性
DevOps ダッシュボードの応答性チャートは、完了までの時間を測定することによって、チームが作業を完了する速度を示します。
応答性の高いチームはビジネスにとって非常に価値があり、ユーザーにとって意味のある価値を定期的にすばやく提供できます。スマートな投資によって仕事にやりがいを持った強力で応答性の高いチームを構築できて、他の長期的な側面を犠牲にすることなく顧客とビジネスの満足感を維持できます。
計算方法
応答性 = 解決日 - 作成日
値は日数で表されます。指定された時間枠内に完了した課題のみが含まれます。
指標は何を示しているのですか?
実線は実際の完了時間を、点線は傾向の方向を示しています。
安定した線は、顧客にとって意味のある価値をチームが迅速に提供できることを示しています。これは、作業が似たようなサイズの管理可能なチャンクに分割されているため、見積方法が優れていることを示している可能性があります。
ラインが上昇している場合は、チームが課題を完了して価値を提供するのに時間がかかっていることを示します。これは、チーム内に課題のサイジングと見積の問題があることを示している可能性があります。
線が下降傾向の場合、チームは短い時間で課題を完了しています。一般的にこれは良い傾向ですが、やはり課題のサイズや見積の問題を示している可能性があります。
鋭い山は、課題を完了するまでの平均時間が通常よりも長かったことを示しています。その期間に完了した課題を調査して、問題が単一の課題によるものなのか、課題のリソース配分の問題なのかを調べることをお勧めします。
このスクリーンショットでは、すべてのプロジェクトと比較した 1 つのプロジェクトの応答性チャートを示しています。
生産性
DevOps ダッシュボードの生産性チャートは、デリバリーされている作業の量を示しています。
計算方法
生産性 = 完了した課題の数
これは、指定された期間におけるチームの完了の定義を満たしている作業量を示す単純なメトリックです。
指標は何を示しているのですか?
ラインが安定している場合は、チームが特定の期間において同等数の課題に取り組んでいることを示します。適切な見積とスプリント計画の結果として、安定したワークロードの指標になるでしょう。
鋭い山と谷は、作業負荷または見積に問題があることを示している可能性があります。深く掘り下げた上で、それらの週に何が起こっていたかを調べることをお勧めします。このデータを同じ期間の割り当てデータと比較することをお勧めします。
単一のプロジェクトとすべてのプロジェクトを比較するのは困難な場合がありますが、課題の数の違いではなく線の形状に焦点を当てます。
すべてのプロジェクトと比較した 1 つのプロジェクトの生産性チャートを示すスクリーンショット
予測可能性
DevOps ダッシュボードの予測可能性チャートでは、開始された (「進行中」ステータスに移行した) 課題の数と、一定期間に完了した課題の数を比較することによって、作業のペースの一貫性を示しています。
計算方法
予測可能性 = 完了した課題 - 開始された課題
応答性は時間 (日) で測定されますが、予測可能性は作業の流れ、具体的には開始された作業量と同じ時間枠内に完了した作業量の比較に焦点を合わせています。
指標は何を示しているのですか?
理想的には、特定の期間に開始して完了した課題の数がほぼ同じになる必要があります。つまり、チャート上では 100% 前後です。
値が 100% より大きい場合は、開始された課題よりも完了した課題が多いことを示しています。これは良い傾向ですが、タスクを完了した後に新しいタスクがピックアップされていないことを示している可能性があります。
値が 100% より小さい場合は、完了した課題よりも開始された課題が多いことを示しています。これは、作業項目が多すぎて時間枠内に完了できないことや、チームが開始している作業が多すぎることを示している可能性があります。進行中の作業に制限を設けるといい可能性があります。
すべてのプロジェクトと比較したプロジェクトの予測可能性を示すスクリーンショット。
品質の要約
品質、応答性、生産性、予測可能性に関する個別チャートを使用して、1 つのプロジェクトとすべてのプロジェクトを比較できることに加えて、各プロジェクトの集計値を個別に表示する要約ビューを表示できます。
表示内容
プロジェクトごとの集計
たとえば、応答性チャートには、レポート期間における個々のプロジェクトの完了までの合計時間が表示されます。
このチャートを読むときは、X 軸だけが重要であることにご注意ください。Y 軸ではプロジェクトの間隔がランダムに空くため、ドットは重なりません。各ドットにカーソルを合わせると、プロジェクト名と値が表示されます。
指標は何を示しているのですか?
これは、外れ値となっているため、さらに調査が推奨されるプロジェクトを特定するのに役立ちます。
また、エンジニアリングの健全性またはアジャイル作成のより大きな問題を示している可能性がある、組織全体の傾向を観察できます。
他のチャートと同様に、データを割り当てデータと対比すると役立ちます。生産性と応答性が低いのは、プロジェクトに関与しているチーム メンバーが少なすぎることが理由である可能性があります。
ダッシュボード スコープにあるすべてのプロジェクトに関する品質サマリーを示すスクリーンショット
ダッシュボードの設定を構成する
接続したら、特定のプロジェクト、チーム メンバー、期間を表示するようにダッシュボードを設定できます。
ダッシュボードを設定するには、次の手順に従います。
- ダッシュボードの [設定] アイコンを選択します。
- 任意の日付、プロジェクト、チーム、課題を設定します。各設定の詳細については、以下の表をご参照ください。
- [閉じる] アイコンを選択して、設定ペインを閉じます。
利用可能な設定の要約は次のとおりです。
設定 | 説明 |
|---|---|
日付範囲 | スライダをドラッグして、レポートする開始日と終了日を設定します。ダッシュボードには、データ パイプライン エクスポートに含まれる日付範囲のデータのみを表示できます。 |
時間の単位 | チャートを週、月、四半期、または年のいずれの単位で表示するかを選択します。 |
ダッシュボード集計 | レポートを、プロジェクト別にするかプロジェクト カテゴリ別にするかを選択します。 |
プロジェクト/プロジェクト カテゴリ | プロジェクト別に集計する場合は、レポートする特定のプロジェクトを選択します。プロジェクト カテゴリ別に集計する場合は、レポートする特定のプロジェクト カテゴリを選択します。 リストには、データ パイプラインのエクスポートに含まれるすべてのプロジェクトまたはプロジェクト カテゴリが含まれます。 |
チーム メンバー | レポートするユーザーのサブセットを選択します。初期設定では、このフィールドはユーザー ID を返します。データがある場合は、ユーザー名またはフル ネームで選択するようにクエリを変更できる場合があります。 |
課題タイプ | ダッシュボードに含める課題タイプを選択します。たとえば、エピックまたはサービス リクエストを除外できます。 |
不具合のある課題タイプ | ダッシュボードで「不具合」として扱う課題タイプを選択します。これは、バグやその他の不具合の修正に費やされた労力を示すために、品質メトリックで使用されます。 |
データを自分のために活用する
DevOps テンプレートでは、チームの現在のエンジニアリングの健全性に関する貴重なインサイトを示すことを目的としており、より優れたビジネス上の意思決定をもたらすデータ パイプラインのデータを使用する方法に関するいくつかのアイデアを生み出しました。
このテンプレートは開始点として扱ってください。アトラシアンが選んだメトリックの計算方法は、お客様のチームの作業方法に合わない場合があります。応答性と生産性のチャートを例に挙げます。課題を測定の基本単位として使用しました。これは、課題のサイズが似ていることが予想されるカンバン チームに最適です。一方でスクラム チームの場合は、ストーリー ポイントを測定単位として使用する方がいい可能性があるため、課題ごとではなくストーリー ポイントごとの平均完了時間を測定できます。
準備はよろしいですか?