私の会社では、JIRAを要件トラッキングツールとバグトラッカーとして使用しています。時間。JIRA（またはその他のツール）を使用して複数のプロジェクトにまたがる要件の追跡
要件が部分的に重複する3つの異なるプロジェクト提案があるシナリオがあります（要件1はプロジェクトAとB、要件2はプロジェクトBとCなどに適用されます）。要件ごとに1つのJIRA問題を入力できるようにしたいと思いますが、JIRAの問題とプロジェクトには1対1の関係があるため、これは可能ではありません。
誰かがJIRAでこれを行う方法を見つけましたか、あるいはJIRAと統合する他のツールを使用している可能性がありますか？
1つの正解はありませんが、私は考えを示すことができます。私はあなたの仕事のプロセスに関する十分な情報がありませんが、あなたはプロジェクトの提案があると言います。プロジェクトA、B、Cは初期段階にあると仮定しています。要件収集など、まだバグはありません。
単一のJIRAプロジェクト、たとえば「Early Requirements」を設定します。プロジェクトA、B、Cのすべての要件をそのJIRAプロジェクトに入れます。要件と実際のプロジェクトの多対多の関係を可能にするには、「複数のチェックボックス」タイプのカスタムフィールドを設定するか、「プロジェクトA」、「プロジェクトB」、「プロジェクトC」を値として設定します。どんな要件に対しても、それが適用されるプロジェクトを確認することができます。
ここで、私はここでより多くの仮定をしています。いくつかの提案が進んでいくうちに、いくつかのものが消滅するとしましょう。 a）実際のプロジェクトAのすべての要件を新しく作成したAのJIRAプロジェクトに抽出するプロセスが必要です。これは、検索&バルククローンの問題を介して実行できます。 b）関連するライブプロジェクトがないすべての要件をパージします。& bulk deleteを検索します。
警告：異なる顧客との要件を共有する必要がある場合は、処理が複雑になります。パーミッションは、JIRAプロジェクト&発行タイプごとに設定されます。
これまで述べてきたように、JIRAには、ベースラインやトレーサビリティなどの適切な要件管理のための機能がありません。しかし、それ以上の作業のためだけにデータを収集することは可能かもしれません。
ジラの「重複」機能または「関連」機能を使用します。
プロジェクトごとに問題が発生しますが、それらを関連付けることになります。そうすれば、プロジェクトによって「所有されている」問題を1つ持ち、それぞれのプロジェクトで変更がテストされると、関連するすべてのプロジェクトを閉じることができます。
プロジェクト設定で意味がある場合は、リンケージを使用することもできます。
答えをありがとう - 私は少しSeredaの提案を好むが、それはうまくいかない場合、私はあなたを試してみることがあります。 –
この場合、jiraに加えて合流を使用する方がよいでしょう。
Jiraを使って、それが一番うまくいくかどうかを確認し、それ以外の場合はConfluenceを使用してください。
役に立つと思えば、さまざまなプロジェクトを共有する「サブモジュール」に分割しますが、Jiraを使って実際の実装や関連するバグを追跡することをお勧めします。
私たちはConfluenceを持っており、初期の要件収集やディスカッションなどの自由形式のドキュメントに広範囲に使用していますが、必要な詳細な要件追跡には適していません。 –
まだ、コンフルエンスマクロでたくさんのクレイジーなことをすることができます...そして、あなたはそれからジラタスクを参照することができます。 – Arafangion
別のアプローチは、オプションとして発行するハイパーリンク（ 'XYZ-123'など）を含む複数選択カスタムフィールドを作成することです。
同じ問題があります。複数の製品が関係し、それらの間に依存関係がある問題（バグや新機能）がある場合（例として、サーバー、接続API、クライアントアプリケーションがあるとします）。特定の方法でクライアントアプリケーションを拡張することについての新しいアイデアがある場合、接続apiとサーバーにも何らかの拡張が必要な可能性があります。おそらくそれらは異なるチームによって開発されています...同じスプリント/反復では扱われませんが、プロダクトオーナーとして、これらの新しい機能をすべてグループとして把握したいと考えています。
私たちが実際に行ったことは、カスタムフィールドをいくつか作成したことです。導入した最初のフィールドは、「プログラム」と「フェーズ」として「カスケード選択」でした。これにより、製品所有者はプログラムの下で問題をグループ化し、長期的な計画（いくつかの反復）を行うことができます。
次に、「Epic」（または「Theme」）の別のフィールド（テキストフィールド）を追加しました。これは特定のEpic/Themeに関連する問題をまとめたものです。アイデアは、 'プログラム'の中で 'Epics'を使うことです。より大きい「プログラム」の場合は、おそらくそれを別の部分に分けることができます。これらの部分は、これらの「エピック」に反映されます。 （ストーリーラインの一種。一連の製品に穴として価値を加えるストーリーのグループ（複数の製品に広がる可能性があります）。
両方のフィールドを使用すると、プログラム（フェーズの有無にかかわらず）とエピックに基づいて複数の製品にまたがる問題をフィルタリングすることが容易になります。
実際にリンクが有効になっているので、異なる製品間で異なる問題間の依存関係を作成できるようになりました。また、Jiraのデフォルトのバージョン管理とは完全に分離されています。どちらが素晴らしいですか。したがって、通常のリリースプロセスはそのままです。
私が導入しようと考えている別のアイデアは、フィールド '反復'です。計画セッションに入るとき（またはその直後）。このフィールドは、そのスプリントの名前で更新することができます（Jiraは、複数の問題の編集/更新で素晴らしい）。これにより、そのスプリントのすべての問題を簡単に除外することができます。
JiraをScrum計画/スプリントトラッキングツールとしても使用することについて、私が最も気に入っているのは、別個の計画とバックログツールがないことです。バグはより目立ちます。プランニングツールやバグトラッキングツールへのバグの重複管理ができません（正しいcvs/svn/etcコミット番号の場合）。またはリリースノートの生成。
より良い方法は、開発追跡に使用される問題と、多くの場合、すべてのプロジェクトで同じ80％の要件を区別することです。
ソリューションが存在します。Rmsis a JIRA plugin：
ありがとう、それは興味深い考えです。関係するプロジェクトに要件の問題があるのが本当に好きですが、私はあなたの提案がどのように機能するかを見ていきます。 –