59

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

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

4

8 に答える 8

29

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

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

于 2009-08-03T16:45:36.737 に答える
17

コンポーネントについて最も重要なことは、あいまいさをなくし、多すぎないようにすることです。私たちのチームでは現在、3 レベルの階層に移行しています (GreenHopper の意味で):

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

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

于 2010-10-17T05:33:08.910 に答える
13

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

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

この 1 対 1 の対応付けは、リリース スケジュールを明確にするのに役立ち、プロジェクトのバージョン X にどのような問題があり、どのモジュールに注力すべきかを簡単に知ることができます。また、Jira、ビルド システム、および SCM 間の関連付けを簡素化するのにも役立ちます。たとえば、Bamboo を使用している場合、モジュールごとにビルド プロジェクトがある可能性が高いため、関連付けを追加するだけです。

于 2009-08-02T16:14:50.250 に答える
12

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

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

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

于 2011-03-08T21:45:54.660 に答える
10

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

于 2010-03-03T14:09:40.213 に答える
5

私は今、コンポーネントについて別の見方をしています。
顧客の場合、私は「コンポーネント」フィールドを次のように参照します。

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.

では、元の質問にもう一度答えるには、問題をチームごとに割り当てるのか、それとも参照した細かいレベルごとに割り当てるのかを自問してください。
おそらく前者。

于 2012-11-08T23:42:19.313 に答える
3

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

于 2014-01-06T19:17:05.767 に答える
1

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

于 2010-11-18T03:32:14.807 に答える