web-dev-qa-db-ja.com

Jiraプロジェクトでコンポーネントを使用するベストプラクティス

日々の開発でJiraを多用しています。 Jiraでプロジェクトコンポーネントを作成する際のベストプラクティスがありますか?

たとえば、あなたの意見では、Jiraの各開発モジュールにコンポーネントを作成する方が良いでしょうか、それともより細かいコンポーネントがチームに好まれますか?

57
ashkrosh

コンポーネントは小さなサブプロジェクトのようなものです。プロジェクトは、人々をグループ化するときに最も役立つようです。クライアントに、少なくともプロジェクトの数が非常に多くなるまで、JIRAプロジェクトが社会組織をある程度反映することをお勧めします。

また、「Misc」または「Other」という名前のコンポーネントの使用を避けてください。誰も気にしない問題の廃棄物になる傾向があります。

27
mdoar

コンポーネントについて最も重要なのは、明確であり、多すぎないことです。私たちのチームでは、3レベルの階層に移行しています(GreenHopperの意味)。

  • 最上位レベルには、チーム(インフラ、バックエンド、GUI)で区切られた少数のBAコンポーネントがあります。これにより、BA担当者は、コンポーネントリードとして割り当てられた正しいDEVチームマネージャーにリクエストをルーティングできます。
  • 2番目のレベルは実際のプロセスです(Unixの意味で)。これは非常に明確な定義です。問題が複数のプロセスにマッピングされる場合、それらの1つに割り当てます(ところで、GreenHopperは複数のリーフコンポーネントを許可しませんが、プレーンJIRAは許可します)。これはDEVマネージャーによって行われます。
  • 3番目のレベルはオプションであり、めったに使用されず、プロセス内のサブシステムを示します。問題のかなりの部分がコードの明確に定義された部分に関連しており、それらを個別に追跡したい場合に使用します。これは通常、問題に取り組んでいる開発者によって行われます。

このような漸進的な改良が機能するためには、誰がどのコンポーネントに割り当てられ、誰が割り当てられた課題を処理しているのかを把握する必要があります。後者はコンポーネントリードで示され、前者はJIRAで明示的にサポートされていません(または、BAはコンポーネント、DEVマネージャー、サブコンポーネントのみ+すべてのBAなどのみを表示していると言えます)

17
ddimitrov

コンポーネントをモジュール/アーティファクト/ jarに一致させるため、各問題は特定のモジュールが所有できます(ただし、他のモジュールとの依存関係/関係がある場合もあります)。

モジュールレベルよりもきめ細かな問題管理を行うことを強く主張できる場合は、関連するモジュールも分離しない理由を検討してください。

この1-1マッピングは、リリーススケジュールの明確化に役立ちます。プロジェクトのバージョンXの問題と、作業に焦点を当てるモジュールを簡単に確認できます。また、ビルドシステムであるJiraとSCMの間の関連付けを簡素化するのにも役立ちます。 Bambooを使用している場合、モジュールごとにビルドプロジェクトがある可能性が高いため、単純に関連付けを追加できます。

12
Rich Seller

4.2.4では、コンポーネントのみをバージョン管理することはできず、プロジェクトのみをバージョン管理することができます。ロードマップ機能を使用する場合は、そのことに留意してください。

コンポーネントのバージョン管理を追加するには、長年(7年以上)要求があります。

http://jira.atlassian.com/browse/JRA-3501

11
M. Dudley

各主要モジュール、または場合によってはシステム層(バックエンド、フロントエンドなど)ごとにコンポーネントを作成します。私は、モジュールレベル以下の粒度には行きません。 BA、テスト(mdoaに同意)など、アクティビティをサポートするためのコンポーネントを追加できます...コンポーネントはバージョン/リリースに直交しています

10

私は今、コンポーネントに関する別の見解を持っています。
顧客の場合、コンポーネントフィールドは次のように参照します。

A multiselect field that's useful for automatically assigning issues. Each of the things in this field has a potential assignee associated with it.

そして、私は言う:

If you don't care about automatic assignment, just treat the components field as a convenient system field.

元の質問に再び答えるために、チームごとに課題を割り当てたのか、それとも言及した詳細レベルごとに課題を割り当てたのかを自問してください。
おそらく前者。

5
mdoar

JIRAは、プロジェクトのすべてのコンポーネントに同じバージョン番号のセットを持たせるように設計されているため、コンポーネントに独立したバージョン番号を持たせたい場合は、コンポーネントごとに異なるプロジェクトをセットアップするか、コンポーネント固有を許可する私が開発したプラグインを使用する必要がありますバージョン番号と同時に、コンポーネントをバンドルにグループ化できます。プラグインは "JIRAのコンポーネント/サブコンポーネント/バンドルバージョン" で、Atlassian Marketplaceで入手できます。詳細については、atlassian プラグインヘルプページ をご覧ください。もう1つのオプションは、チームのすべてのコンポーネントに同じバージョン番号のセットを強制することです。そうでなければ、コンポーネントの正しいバージョン番号を選択することは非常に困難です。

2
Deniz

2レベルのコンポーネント階層を使用します(greenhopperに感謝します...)-テーマとエピック。 Greenhopper ThemesおよびEpicsのビルドでは、必要な方法を集約して報告することはできませんが、これは非常にうまく機能します。

1
Agile Coach