キラー ダッシュボードを構築するための 5 つのステップ : 必要な情報を必要なときに

2012-10-10 (Wed)  •  By 伊藤  •  活用のヒント  •  JIRA 翻訳

今回の記事は、「5 steps to a killer JIRA dashboard: the information you need, when you need it 」の弊社翻訳版です。原文と差異がある場合は、原文の内容が優先されます。

想像してみてください。ステータス ミーティングに参加したが、誰かが言葉を発する前に作業がすべて順調に進んでいるのを把握済みであることを。または、休暇から帰ってきてメールをチェックしなくても一目でプロジェクトの進行状況が把握できることを。それがあなたにも起こるかもしれません!

予期せず何か問題が発生した場合はどうでしょう? バグが積み上がって現状の作業速度を遅らせる瞬間を把握できます。他のプロジェクトに駆り出される 前に、作業進行上どのチーム メンバーが重要かを明示できます。

キラー ダッシュボードを作成してみましょう。進捗に目を光らせ、事前にボトルネックを特定しましょう。

キラー ダッシュボードの例

ステップ 0 : ダッシュボードを新規作成

簡単です。ダッシュボードに移動し、[ダッシュボードの作成 (Create Dashboard)] を選択します。お好きな名前を付けてください。

ステップ 1 : 5 つのガジェットを追加

まず、最小限必要なものを揃えましょう。全体の進捗、人やサブセクションごとに分割した作業、中心となる高リスク課題などです。以下を追加します。

新規ガジェットの追加
  • フィルター結果
  • 作成済み課題 vs 解決済み課題グラフ
  • 課題統計 : これは 2 回追加します
  • ロードマップ

上記 5 つを追加したら、ダイアログを閉じます。

ステップ 2 : 進捗を一目で確認

ロードマップ ガジェット

毎朝、作業状況はどうなっているかについてある程度の ‘感触’ を持って出社していると思います。ロードマップ ガジェットを使用して、ダッシュボードをざっと見るたびにその直感を再確認できます。

ロードマップ ガジェットを使用すると、次のリリースに割り当てられた課題数 と、そのうちいくつが解決されたかを確認できます。

  • 状況をシンプルにするため、プロジェクトを 1 つだけ表示するようこのガジェットを設定し (ダッシュボード全体でこのプロジェクを利用します)、その他のフィールドで既定値を選択します。
  • [保存 (Save)] をクリックすると、選択した修正バージョンに基づいて課題進捗の集計が表示されます。なお、修正バージョンなしの課題のステータスはここには反映されません。

ステップ 3 : 事前にボトルネックと問題を把握

誰に重みがあるか

チームのメンバーが病欠の電話をかけてきたとしたら、どの程度作業の遅れが出るでしょうか? また、別のプロジェクトで誰かが駆り出された場合はどうでしょうか? リリースするにあたって重要なメンバーは誰か、またその理由 を明確にできるように、どのチーム メンバーに作業負荷が多くかかっているかを把握して代替策を講じる必要があります。

1 人あたりの作業負荷を視覚的に示すことは、チームの進捗を管理する上で重要です。

  • 1 つ目の課題統計ガジェットでは上記と同じプロジェクトを選択し、担当者ごとに統計を比較するよう選択します。
  • [解決した課題の統計を表示 (Show Resolved Issue Statistics)] を [いいえ (No)] に設定します。解決した課題は今後の進捗に影響を与えないためです。

プロジェクトのどの分野で一層の努力が必要か

当然ながら、プロジェクトには重要な面とそれほど重要ではない面があります。チームを適切な分野に注力させるのはあなたに委ねられています。社内の他の人たちが初心者ユーザーの教育に精を出している一方で、あなたの現在の作業として大規模なデータ セットのパフォーマンス向上に重きが置かれている場合、問題が生じます。

ガジェット コンポーネント統計

チームがプロジェクトのサブセクション (JIRA コンポーネント)  を分類するような形で作業負荷を視覚的に表示するとチームがどこにエネルギーを注いでいるかが把握でき、自分のプロジェクトが組織の大目標の範囲内にあるかどうかを確認できます。

  • 2 つ目の課題統計ガジェットで、再度同じプロジェクトを選択します。
  • コンポーネントごとに統計を比較します (ここでも、[解決した課題の統計を表示 (Show Resolved Issue Statistics)] を [いいえ (No)] に設定します)。

たとえば残りの作業に対するバグ修正の相対的割合などを確認するために課題タイプを監視したい場合など、上記の設定は後で変更できます。

ステップ 4 : 現在のマイルストーンに向けて作業

予定に狂いが生じたらすぐに分かるようにしたいため、次のリリースに向けた進捗 に目を光らせておくことが重要です。通常よりも高い確率でバグが積み上がっている場合や、スコープの変更によりリリース日の設定後に新規機能が追加された場合、プロジェクトのマイルストーンを再評価する必要があります。

JQL の初期バージョン

どの程度の量の作業が追加 されたかを確認することで、目標の完了日が現実的なものかを判断できます。

上記で説明したとおり、JIRA ダッシュボード ガジェットはプロジェクトごとの情報を表示できます。また、フィルターと呼ばれる保存済み検索を構築することでより具体的に詳細を掘り下げて調べることができます。

  • JIRA ヘッダーの課題タブに移動し、詳細モードに切り替えます。入力を開始すると JIRA は検索オプションをオートコンプリートで表示してくれます。
  • プロジェクトを選択し、修正バージョンのパラメーターを追加します。動的演算子 earliestUnreleasedVersion() はプロジェクト バージョンでセットアップしたリリース日に基づいて課題を表示します。
  • このフィルターを保存し、”次の修正バージョンの課題” などの分かりやすい名前を付けます。
  • ダッシュボードに戻って、作成済み課題 vs 解決済み課題グラフ ガジェットで新しいフィルター “次の修正バージョンの課題” を選択します。他のフィールドはこの時点では既定値のままにします。

目標の完了日に間に合うか?

作成済み課題 vs 解決済み課題のグラフ

目標に向かって作業が進んでいる場合、解決済み課題数 (完了した作業) は作成された課題数 (追加された新規作業) を超えているはずです。予期しない課題が次々と現れ、リリース日を遅らせるリスクをはらんでいる場合、左の画像のようなグラフになります。

追加された作業 (赤) の量が増える一方、完了した作業 (緑) の量は一定になっています。チームがより一層の努力をするか予定リリース日を遅らせる必要があります。

ステップ 5 : 高リスク項目に要注意

プロジェクトのサブセクションの一部が他よりもリスクが高いという状況は常にありえます。時間見積の多い課題は複雑なことが分かっており、予定より時間を食うと判断された既存の作業は要注意です。

現在の作業のサブセットを掘り下げるには、既存のフィルターを変更するのが最適です。課題タブを選択して JIRA の検索に戻ります。ステップ 4 のフィルターはおそらくまだそこにあると思うので、それを使って構築していきます (選択された検索がない場合、左の検索履歴一覧か上部の課題ドロップダウン メニューで見つけます)。

  • 編集タブを選択して、別の詳細検索を作成します。時間見積パラメーターを追加します。
project = "Angry Nerds" AND fixVersion = earliestUnreleasedVersion() AND originalEstimate > 4h
  • これを新しいフィルターとして保存し、”見積 4 時間超え” などの分かりやすい別の名前を付けます。

要注意課題を中心に据える

ダッシュボードに戻って新しいフィルターがフィルター結果ガジェットに表示されるように設定します。

  • 見積 4 時間超え” フィルターを選択し、表示される 4 つの既定列に加えて担当者フィールドを追加します。こうした要注意課題に誰が従事しているかを一目で確認できます。

専門的ヒント :

JIRA OnDemand でこれを設定している場合、列の順序を変更できることに気付くと思います。 JIRA OnDemand をご利用の皆さんはこの優れた新機能をいち早く利用できます。JIRA のダウンロード顧客は今後のリリースでこの機能を利用でき、弊社の 早期アクセス プログラム を通して JIRA 5.2 EAP 3 で利用できます。

JIRA QA チーム リーダーの Penny Wyatt と OnDemand 開発チーム リーダーの Tim Moore は、弊社の最近の ShipIt デー の一環としてこの早期アクセス機能を JIRA OnDemand に追加しました。

フィルター列の順序

ダッシュボードの完成 : 整理整頓と不足がないかの確認

このチュートリアルは どんなことができるかを紹介する ために作成されました。当然、プロジェクト作業のサブセットを深く掘り下げたいと思う部分も出てくるでしょう。ダッシュボードは生きたページであり、必要に応じて 微調整と進化 が必要です。いくつかアイデアをご紹介します。

  • リリース サイクルの終盤ではバグ修正が重要になります。作成済み課題 vs 解決済み課題グラフ ガジェットのフィルターを編集し、バグのみを検出するよう検索を絞り込みます
  • 孤立課題に注意を向けましょう。fixVersion が EMPTY に変更されたプロジェクトの全課題を選択するフィルターを使用して、アクティビティ ストリーム ガジェットを追加します。
  • 人によってはパーセント表示のバーよりもグラフを好むので、作業の内訳を視覚的に表示するようにします。’次の修正バージョンの課題‘ フィルターを使用してヒート マップまたは円グラフ ガジェットをお試しください。

専門的ヒント :

ダッシュボードに内容を詰め込みすぎないように注意しましょう! 最初から情報が多すぎると、本の中のすべての文章を強調しているようなものです。少量で始めて時間をかけて微調整と発展を繰り返しましょう。


Related Articles

お気軽にお問い合わせください

お問い合わせ