私の会社では、JIRAを要件追跡ツールおよびバグトラッカーとして使用しており、一度に1つのプロジェクトに取り組んでいる間、JIRAは非常にうまく機能しています。
これで、要件が部分的に重複する3つの異なるプロジェクト提案があるシナリオがあります（たとえば、要件1はプロジェクトAとBに適用され、要件2はプロジェクトBとCに適用されます）。要件ごとに1つのJIRA課題を入力できるようにしたいのですが、JIRAの課題とプロジェクトは1対1の関係にあるため、それは不可能のようです。
JIRAで、またはJIRAと統合する他のツールを使用してこれを行う方法を見つけた人はいますか？
正解は1つではありませんが、アイデアを提供することができます。あなたの作業プロセスについて十分な情報がありませんが、プロジェクトの提案があるとのことです。したがって、プロジェクトA、B、Cは初期段階にあると思います。要件の収集など、まだバグはありません。
「初期要件」など、単一のJIRAプロジェクトを設定します。プロジェクトA、B、Cのすべての要件をそのJIRAプロジェクトに入れます。要件と実際のプロジェクトの間に多対多の関係を可能にするには、「複数のチェックボックス」または同等のタイプのカスタムフィールドを設定し、その値として「プロジェクトA」、「プロジェクトB」、および「プロジェクトC」を構成します。どのような要件についても、それがどのプロジェクトに適用されるかを確認できます。
今-そして私はここでより多くの仮定をしている-いくつかの提案が先に進み、いくつかが消滅したとしましょう。a）実際のプロジェクトAのすべての要件をAの新しく作成されたJIRAプロジェクトに抽出するプロセスが必要になります。これは、検索と一括クローンの発行を介して実行できます。b）ライブプロジェクトが関連付けられていないすべての要件を削除します-検索と一括削除。
警告：要件をさまざまな顧客と共有する必要がある場合は、注意が必要です。権限は、JIRAプロジェクトと課題の種類ごとに構成されます。
そうは言っても、JIRAには、ベースラインやトレーサビリティなど、適切な要件管理のための機能がありません。ただし、今後の作業のためにデータを収集するだけでも問題ない場合があります。
jiraの「duplicates」または「relatesto」機能を使用します。
したがって、各プロジェクトで問題を提起しますが、それらを相互に関連付けます。そうすれば、プロジェクトが1つの問題を「所有」し、それぞれで変更がテストされたら、関連するすべてのプロジェクトを終了できます。
プロジェクトのセットアップでこれが理にかなっている場合は、リンケージに依存して使用することもできます。
同じ問題があります。複数の製品に関連し、それらの間に依存関係がある問題（バグまたは新機能）がある場合。（例として、サーバー、接続API、クライアントアプリケーションがあるとします）。クライアントアプリケーションを特定の方法で拡張することについて新しいアイデアがある場合、接続APIとサーバーにも何らかの拡張が必要になる可能性があります。おそらく、それらは異なるチームによって開発されています...したがって、同じスプリント/イテレーションでは処理されませんが、製品所有者として、これらすべての新機能をグループとして追跡する必要があります。
私たちが行ったことは、実際にいくつかのカスタムフィールドを作成することでした。最初に紹介したフィールドは、「プログラム」および「フェーズ」としての「カスケード選択」でした。これにより、製品の所有者は、プログラムの下で問題をグループ化し、大まかな長期計画（数回の反復）を行うことができます。
次に、「エピック」（または「テーマ」）に別のフィールド（テキストフィールド）を追加しました。これにより、特定のエピック/テーマに関連する問題がバンドルされます。アイデアは、「プログラム」内で「エピック」を使用することです。より大きな「プログラム」の場合は、おそらくそれをさまざまな部分に分割して、これらの「エピック」に反映させることができます。（一種のストーリーライン。一連の製品に穴として価値を付加するストーリーのグループ（複数の製品に広がる可能性があります））。
どちらのフィールドでも、プログラム（フェーズの有無にかかわらず）とエピックに基づいて、複数の製品にまたがる問題を簡単に除外できるようになりました。
実際、リンクを有効にすると、さまざまな製品でさまざまな問題間の依存関係を作成することもできます。また、デフォルトのJira製品のバージョン管理から完全に分離されています。これは素晴らしいので、通常のリリースプロセスはそのままです。
私が紹介しようと考えているもう1つのアイデアは、「反復」というフィールドです。計画セッションに入るとき（またはその直後）。このフィールドは、そのスプリントの名前で更新できます（Jiraは複数の問題の編集/更新に最適です）。これにより、そのスプリントのすべての問題を簡単に除外できます。
Jiraをスクラム計画/スプリント追跡ツールとしても使用することで私が最も気に入っているのは、個別の計画およびバックログツールがないことです。バグがより目立ちます。計画ツールへのバグの二重管理やバグ追跡ツールへの計画項目の二重管理はありません（正しいcvs / svn / etcコミット番号の場合）。またはリリースノートの生成。
この場合、jiraに加えてconfluenceを使用する方がおそらく良いでしょう。
最高のものにはJiraを使用し、それ以外にはConfluenceを使用します。
有用だと思われる場合は、さまざまなプロジェクトを共有の「サブモジュール」に分割しますが、実際の実装と関連するバグを追跡するためにJiraを使用することをお勧めします。
別のアプローチは、オプションとして発行するハイパーリンク（「XYZ-123 」など）を使用して複数選択のカスタムフィールドを作成することです。
より良い方法は、開発の追跡に使用される問題と、すべてのプロジェクトで80％で同じであることが多い要件を区別することです。
解決策が存在します：Rmsis JIRAプラグイン：