エピックで構成され、エピックの完了によってイニシアチブも完了します。テーマとは、バックログ項目、エピック、イニシアチブにラベルを付け、どの作業がどの組織目標の達成につながるのかを組織で把握するためのツールです。 Jira 管理者は、新しい課題タイプを作成して、チームが取り組むさまざまな作業を示すことができます。課題タイプは課題タイプ スキームに含まれ、課題タイプ スキームは 1 つ以上のプロジェクトに関連付けることができます。

同じ Jira サイト内の課題にリンクする場合. ShareJIRA のアジャイルプロジェクト数が (なんと Cloud 製品の顧客だけで) 50 万を超えました。アジャイルチームがどのように仕事をしているかがわかる膨大なデータを私たちは持っていることに気付きました。そして、匿名データマイニングによって、スプリントを繰り返してテンポ良くリリースしているチームを発見しました。調査中に際だったのは、素早く頻繁にリリースするチーム、ここでは「迅速にリリースするチーム」と呼びますが、このようなチームには通常、1 スプリントにおよそ 30 の課題があるということです。そして私たちは、5 〜 7 人で構成された効率的なアジャイルチームについて議論しています。課題の数が 30 というと多すぎるように聞こえるかもしれませんが、その数字が全てを語っているわけではありません。30 という数字は、迅速にリリースするチームが仕事を多くの小さな機能単位に分割していることを意味しています。各機能を細かく分割することによって、小さなチームが自らを守り、1 つのスプリントで自信を持って完了できるレベルまで仕事に取り組むことができるのです。1 スプリントで発生する課題の数に対するチームのスイートスポットを見つけるために、あなたのチームに必要なことは、課題の範囲が大きくなりすぎる瞬間を見極めることです。その瞬間を見つけたら、それに対して何か行動を起こし、JIRA によって変化を起こす必要があります。ストーリーだったものをエピックに変更すべきでしょうか? 課題管理ツール『Jira Software』を使うことになったものの、どうやって使ったらいいのか分からないという人もいるでしょう。Jira Softwareとは何ができるツールなのか、操作方法などの基本知識から参考書まで紹介します。 リンク元の課題を開きます。 [その他] (•••) > [リンク] > [Jira 課題] をクリック (または [新しい課題ビュー] のクイック追加ボタン をクリック) します。 課題リンクのタイプを選択します (例: "this issue is blocked by プロジェクトと課題の追跡サービス デスクとカスタマー サポートあらゆるビジネス プロジェクトの管理ドキュメント コラボレーションGit によるコード管理使用状況と管理者向けのヘルプ回答、サポート、およびインスピレーションクラウド サービスの健全性機能の提案とバグ レポート製品アプリケーションよくある質問関連ドキュメント読み込みに失敗しましたアトラシアン コミュニティをご利用ください。課題とは実行する必要があるアクションのことです。そのアクションには、タスクやバグ、機能リクエスト、または組織の取り組みが必要なあらゆる種類のアクションが含まれます。すべてのチーム コラボレーションは作業項目や作業に取り組む組織の周りで発生するものであるため、課題が Jira アプリケーションの中核となります。Jira 管理者は、新しい課題タイプを作成して、チームが取り組むさまざまな作業を示すことができます。課題タイプは課題タイプ スキームに含まれ、課題タイプ スキームは 1 つ以上のプロジェクトに関連付けることができます。このページでは、クラシック プロジェクトで使用する課題タイプの追加について説明します。次世代プロジェクトの課題タイプについての情報をお探しの場合、「クラシックプロジェクトで課題タイプを追加、編集、または削除するには、新しい課題タイプの名前と説明を入力します。標準課題タイプか、サブタスク課題タイプのいずれかを選択します。サブタスクは、標準的な課題に関連する小規模な作業に使用できます。新しい課題タイプは既定の課題タイプ スキームに追加されます。これを含む他のあらゆる課題タイプ スキームを構成して課題タイプをグループ化し、それらを 1 つ以上のプロジェクトに関連付けることができます。課題タイプを削除する前に、そのタイプのすべての課題を検索し、それらの課題を一括編集して、既存の他の課題タイプを選択しておくことをお勧めします。これで、既存の作業に影響を与えることなく、元の課題タイプを削除できます。この内容はお役に立ちましたか? サブタスクをどこに当てはめれば良いのでしょうか?これらの質問に答えるために、課題を適切に分割して、それらの全てを JIRA でまとめる方法を一緒に見て行きましょう。最近投稿された JIRA Portfolio ブログにおいて、この階層構造があるため各要素の範囲がある程度わかるでしょう。しかし、チームのバックログにある ユーザーストーリー が機能全体を表している場合がありますし、あるいは、他の課題より 2 倍あるいは 3 倍大きいと思われるものもあるかもしれません。どちらのケースでも、課題の範囲は再評価する必要があります。ある課題の説明が一つの機能の説明のように見えるか、もっと大きな作業になりそうであれば、その課題はエピックに変換しましょう。そして、その構成要素である ユーザーストーリー とタスクにすぐにリンクするべきです。このために JIRA では以下の作業が必要になります。次に、ユーザーストーリー 用の課題を作成し、これとあなたが新しく作成したエピックを関連付けます。JIRA で課題を作成する方法はエピックと関連する課題に関しては非常に簡単です。これが課題タイプをより大きい範囲に変更する方法です。逆に、ユーザーストーリー が機能全体になってはいないけれど、1 つのスプリント内で 1 人で完了できないほど作業が多い場合、複数の課題に分割する必要があります。そういった問題が起きる時、チームの見積もりを理解する必要性が出てくるでしょう。例えば、JIRA マーケティングチームは、ストーリーポイントを見積もりに使用しています。ユーザーストーリー が 20 ポイントかそれ以上だと見積もられた場合、私たちはそれをレッドフラグとしています。それは、課題の見積もりが、2 週間のスプリントには大きすぎるということです。これがストーリーポイントを基準にするチームルールです。さまざまな基準があり得ます。しかし、試しにあなたの開発チームも同じ基準で 2 週間スプリントを実施するとしましょう。20 ストーリーポイントは、ユーザーストーリー に含まれる未知の物が多すぎるか、単に大きすぎることを意味するでしょう。小さい課題に分割する方法は、プロダクトオーナー、開発者、テスター、スクラムマスターなどから構成されるあなたのチーム次第です。ユーザーストーリー を 2 つの課題に分割することにした場合、コピーをすること、すなわち JIRA の課題においてはクローニングが最高の選択肢になります。クローニングによって、新しい課題には概要、課題タイプ、スプリント、エピック、バージョン、予定日、担当者などのオリジナルと同じあらゆる情報が含まれます。説明文は、各課題の希望の範囲を反映するように、明らかに更新する必要があります (基本的には 2 つに分割)。クローンした課題の担当者とフィックスバージョンも、状況に応じて同様に変更する必要があるかもしれません。これまでに課題のクローンをしたことがない方のために簡単な方法を以下に紹介します。クローニングのもう一つのメリットは、新しい課題がオリジナルの課題の課題リンクセクションに表示されることです。それには「クローン先」というリンクタイプと新しい課題への参照が付与されています。同様に、新しい課題の課題リンクセクションには、オリジナルの課題の参照があり、それには「クローン元」というリンクタイプが付与されています。リンキングは各課題の関係を繋げる素晴らしいものです。JIRA には「クローン先 / クローン元 (is cloned as/is cloned from)」や「ブロック/ ブロック元 (blocks/is blocked by)」などの基本的なリンクタイプがいくつかありますが、JIRA 管理者と協力して、あなたの希望のあらゆるカスタムリンクタイプを追加することも可能です。限界はありません。例えば、ここアトラシアンでは「問題 / 原因 (causes/is caused by)」というカスタムリンクタイプを追加し、コード変更が新しいバグを生み出した状況を反映しています。2 つの課題がリンクされれば、それらの関係は課題リンクセクションに表示されます。また、リンクされた課題の優先度やステータスを見ることもでき、それにより課題間を移動する必要がなくなり、待機中の課題が完了されたかどうかを確認するために検索する必要もなくなります。課題を分割しようとしているかどうか、または課題をプロジェクトにまとめようとしているかどうかに関わらず、リンクはシンプルです。ここに課題のリンク方法を紹介します。さらに、上述したオペレーションダイアログボックスを使うことで時間を節約することもできます。そしてサブタスクがありました。それらを課題を解決するための個別ステップとして列挙するチームもあります。複数のメンバーに課題の完了が要求された場合、担当者を変えるのではなく 5 つのサブタスクを 5 人の異なるメンバーに割り当てることができるから、サブタスクを気に入っているというチームもあります。リンキングと同じように、管理者がサブタスクは通常、バックロググルーミングあるいはスプリント計画中に追加されます。これは、ユーザーストーリー を分割する必要性を決定するのと同じ状況です。これにより課題を小さくするタイミングを見つけやすくなるため、必然的により簡単で正確に見積もりがしやすくなります。JIRA の他のあらゆる機能と同様、サブタスクはカスタマイズが可能です。サブタスクが全て完了するまでユーザーストーリーを次のワークフローステータスに移したくない場合は、そうすることも可能です。これらは、より賢くチームの計画を立て、リリースリズムを見つける助けになるツールなのです。JIRA の 50 万以上に及ぶアジャイルプロジェクトにおいて、迅速にリリースするチームのおおよその平均値としては 1 スプリント当たり 30 の課題数ではありますが、本当に重要なことは、スプリントの間に完了できるように課題の大きさを決めることです。課題が大きすぎると判断して、エピックに変換したり小さな課題に分割したりすることができれば、より成功に近づき、スプリント後にはあなたのチームは「迅速にリリースするチーム」になっているでしょう。私たちは、迅速にリリースするチームの他のパターンやよくある傾向も発見しています。迅速にリリースするチームの特徴をインフォグラフィックスでご覧ください。