JIRAコンポーネント戦略

Question

私は最近、別のバグ追跡システムからJIRAに切り替えました。以前は「コンポーネント」フィールドを使用していませんでした。プロジェクトはかなり小さかったので、当時それは必要ないようでした。プロジェクトが少しずつ大きくなるにつれて、コンポーネントフィールドが有用かもしれないことがわかりましたが、コンポーネントを分割する方法が正確にはわかりません。

たとえば、銀行アプリケーションがあり、アカウント間で送金する機能を追加しているとします。その機能は「アカウント」コンポーネントとして分類される可能性がありますが、ユーザーインターフェイスにも影響し、セキュリティに関連するいくつかの問題もあります。多くの問題がこのような問題を抱えているようです。

プロジェクトをコンポーネントに分割する方法を決定するベストプラクティスはありますか？ 「ユーザーインターフェース」や「セキュリティー」のようなものは広すぎますか？

この質問には正解が1つしかないので、コミュニティウィキに移動する必要があるかもしれませんが、洞察力のある人が提供できるものはここで役立ちます。

Answer 1

コンポーネントは、それぞれに明示的なデフォルトの譲受人（コンポーネントリード）がある場合に最も便利です。もう1つの方法は、しばらく待ってラベルを使用することです。ユーザーが使用したい共通のラベルがあるかどうかを確認し、それらのラベルのコンポーネントを数週間で作成します。

〜マット

Answer 2

バグを作成しているユーザーは、問題を報告する際に複数のコンポーネントを追加できます。そのため、特定のバグによって影響を受けたすべてのコンポーネントとして、アカウント、転送、セキュリティの問題（またはローン、支払い、セキュリティの問題）を選択できます。開発チームがこのバグの発生場所を正確に把握できるように、コンポーネントの任意の組み合わせを組み合わせることができます。

Answer 3

私たちは、これらのコンポーネントへのレポートは、あなたのアプリケーション開発の一部は、ほとんどの問題を取得し、フィードバックを与えることができるように、意味のある方法で問題をクラスタ化するために、主に当社でコンポーネントのフィールドを使用するか、またはほとんどの変更（最も多くのバグが発生）が発生しています。時には、コンポーネントがプロジェクトの構成を反映している場合、デフォルトの譲受人の側面は有効なものです（@mdoarが答えます）。しかし、それでもなお、プロジェクトの概要はここで最も興味深い側面です。