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

プロジェクト、ユーザー

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

チケットのタイプの決定

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

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

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

ワークフロー

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

ステークホルダーの決定

プロジェクトロール

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

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

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

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

パイロット トレーニング

Atlassian University, CAC

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

ビジネス メトリック

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

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

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

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

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

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

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

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