1.7 パイロット構成の観点

トライアル インスタンスをインストール / セットアップしたら、プロジェクトのパイロット フェーズの計画に時間を費やすことができます。このフェーズで学んだ大きな教訓の 1 つは、Jira の柔軟性とカスタマイズ性を活用して、組織の特定の要件とビジネス プロセスにインスタンスを適応させることです。しばらく時間をかけて、課題タイプ、フィールドの構成、通知、権限、およびワークフロースキームにをご確認ください。Jira のデフォルト バージョンを使用し、プロジェクトが軌道に乗ってから構成機能を確認することはおすすめしません。

パイロットの観点

Jira 構成アイテム

コメント

参加するプロジェクトの選択

プロジェクト、ユーザー

一般に、最初の Jira プロジェクトには潜在的な需要が高い候補を選択することをお勧めします。ALM コラボレーションの改善や新しいプロジェクトのためのアジャイル手法の導入など、Jira のメリットを活用したいグループを選択します。また、そのグループのメンバーがアーリー アダプターであるとよいでしょう。これは、初期段階での変更管理に大いに役立ちます。

チケットのタイプの決定

課題タイプ、フィールド、およびフィールド構成

Jira には、あらかじめ設定された課題タイプとフィールドのセットが付属します。これらは名前の変更、削除、および修正が可能です。プロジェクトに伴う、タスク、課題、要件、変更要求などのタイプを決定するようにします。また、異なるフィールドやワークフローを必要とする課題タイプを区別します。これらはそれぞれの課題タイプ専用である必要があります。また、デフォルトの Jira ラベルを使用する代わりに、タスク、課題、要件などに関する既存の企業言語を使用することを検討します。

ステータスとトランジションの決定

ワークフロー

ワークフロー デザイナーに進んで新しいワークフロー スキームの作成を開始する前に、紙で計画を立てることをおすすめします。各課題タイプが経由する作業ステータスや、それぞれのトランジションにおいてどのグループまたはロールによる操作が必要かを書き出します。ほとんどの場合、単純な、オープン - 進行中 - 解決済みで十分です。ただし、ソフトウェア開発などの場合には、ソフトウェア要件の進捗をさまざまな段階で示す個別の段階が役立ちます (例: "要求済み"、"指定済み"、"開発中"、"QA 中"、"解決済み")。ここで、課題はフェーズからフェーズに移行し、それを視覚的に確認できます (例: Jira Agile のラピッド ボード)。プロジェクト チームが既にビジネス プロセスを確立し、それを実証済みの場合、ワークフロー デザイナーまたはエディタを使用してそれを Jira で再構築し、アプリケーションの高度なカスタマイズ性をご確認ください。

ステークホルダーの決定

プロジェクトロール

プロジェクトに特定のステークホルダーがいる場合、プロジェクト ロールを作成して、個別のユーザーに割り当てることができます。これは、特定のステータス トランジションの後の課題の自動割り当て先としてプロジェクト ロールを指定できるため、便利です。例: 課題が "解決済み" の段階になると、課題は "QA Dispatcher" に自動的に割り当てられ、このユーザーは課題のテストを構成できます。ただし、ボトルネックを避けるため、プロセスが特定の個人のアクションに依存しすぎないようにします。

コンポーネント、バージョン、およびリリースの計画

コンポーネント、バージョン

各プロジェクトには、コンポーネントに使用できる特定のサブ領域が含まれる場合があります。これらはソフトウェア製品の一部やプロジェクトの専門知識である可能性があります。このフィールドを使用して、課題、要件、変更リクエストをグループ化できます。また、プロジェクトのバージョン (ソフトウェア バージョン、SPRINTS、純粋なプロジェクト管理の場合は主要なマイルストーン) を入力します。

パイロット トレーニング

Atlassian University, CAC

Jira の実装はパイロット段階ですが、各利用者に対してシステムを使用した作業方法のトレーニングを行うことをおすすめします。これを行うには、システムで実行する必要がある手順を大まかに示したプロセス ドキュメントを使用します。また、特定のアクションを実行するためのコースがある Atlassian University を利用したり、アトラシアンの公式ドキュメントを参照することもできます。

ビジネス メトリック

ダッシュボード、レポート

ポートフォリオ管理および財務のビジネス ステークホルダーに、必要な KPI やその他のメトリックを確認します。あるお客様は、タイム トラッキング (特にアドオンを使用した) 機能を財務部門に示すことで、Jira の利用を開始できました。また、生産性および予測レポートにも重点を置きます。フィルタを使用して、問題のある課題を特定したり、作業が停止した領域を特定したりすることもできます。さまざまなプロジェクトおよびビジネス ステークホルダー用にさまざまなダッシュボードをセットアップし、それを定期的な会議で使用します。

 

パイロット システムの調整

スキーム / カスタム フィールド

パイロット プロジェクト自体に対してアジャイル アプローチを採用します。最初から理想的な Jira シナリオを計画することはできないかもしれません。代わりに、パイロット チームが作成した実用的な知識を活用できます。システム自体をレビューしてからそれぞれの変更を実装する、定期的なパイロット プロジェクトのレビュー ミーティング (イテレーション ミーティング) のスケジュールを設定します。これにより、パイロット チームに当事者意識やモチベーションが生まれ、この言葉をさらに広げられる可能性があります。

他の用途のためのアイデアを歓迎する

その他のプロジェクト / スキーム

パイロット プロジェクトの範囲は明確に定義する必要がありますが、他の部門を招待してインスタンスを確認したり、システムの柔軟性を示したりすることもおすすめします。Jira を使用するための、プロジェクト管理、サービス デスク、人事、サポート、タイムトラッキングなどの、純粋な開発以外の領域を含むアイデアを歓迎します。別のスキームを使用して新しいプロジェクトをセットアップし、これらのアイデアをすばやく視覚化してデモンストレーションします。

Jira で ClearQuest を作成しないでください

お客様から学んだ教訓の 1 つは、 ClearQuest のフィールドとプロジェクト階層構造を Jira で正確に再現しようとしないことです。複数のプロジェクトを作成し、それらを会社の実際のチームや製品に合わせて調整できるメリットを活用するようにします。また、改善、変更リクエスト、ナレッジ記事、ユーザー ストーリー、エピックなどの多くのチケット タイプを追跡する機能を活用し、それらを不具合と同じコンテキストで管理します。過去には、課題トラッカーが品質保証部門でのみ使用されている事例が多くありました。Jira はアプリケーション ライフサイクル管理プロセスですべてのチームをまとめるソフトウェアです。

最小構成

構成とカスタマイズは容易に行えますが、異なるプロジェクト パラメータを検討するために時間をかけすぎないようにします。パイロットの最初の段階では必要な調整のみを行い、時間をかけすぎないようにします (例: 最初のパイロット イテレーションでは 50 のチケット タイプや 10 のワークフローは不要です)。反復的アプローチを活用し、ユーザーやステークホルダーからのフィードバックに応じて変更や拡張機能を実装します。

最終更新日 2018 年 1 月 12 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.