Best practices for scaling JIRA Software
In this guide, we'll look at the best ways to use JIRA Software for both large organizations and teams that wish to scale. If you have a large JIRA instance with multiple JIRA applications, then you'll want to start with Performance and scale testing, which shows the performance of JIRA Data Center and how different factors and data sets (issues, users, attachments, etc.) affect it.
このページでは、Jira Software アプリケーションの拡張に関する具体的な情報を提供します。
次のセクションにジャンプ
ボードの設計と使用
スケーリングに対応するボードを構成する際には、多数の考慮事項があります。複数のプロジェクトの課題を含めることができるだけでなく、JQL に基づいて課題を除外することもできます。これは、ボードでの表示内容に対する誤解を招く場合があります。一般に、ボードの最終的な目的から検討を開始することをおすすめします。複数のボードを作成して (同じ課題を対象とする複数のボードも可能)、異なるチームに異なる方法でデータを表示することもできます。
スクラムやカンバン プリセットを使用して新しいボードを作成すると、対応するフィルターも作成されます。つまり、フィルターを変更してボード上の課題を絞り込み、表示する必要のない課題を削除したり、必要なものにのみ焦点を当てることができます。
ボードは最大 2,000 の課題を表示できますが、ボード上に一度に多くのレコードを表示することはお勧めしません。課題が 500 以上あるボードは、一部のブラウザー (IE8 など) や性能の低いコンピューター (詳細は、「クライアント側の考慮事項」の下のセクションを参照してください) ではレンダリングに長い時間がかかることがあります。さらに、膨大なカードの中から必応な課題を見つけることは困難です。さらに、JIRA インスタンスは更新のたびにこれらの課題に関するデータを取得する必要があります。もし数千の課題があり、25 人のユーザーが同時にこのボードを読み込もうとすると、一仕事必要になります。
The issue data itself is pulled from the indexes with the new boards, rather than from the database directly, so this should greatly improve the load times you'll see on larger boards. This should also be taken into consideration when scaling a JIRA instance.
また、ボードは元になっているフィルターのパーミッションを継承するため、正しいボードを見つけようとしている際に余計なボードが表示されるのを防ぐため、特定のグループやロールにのみ表示されるボードを作成できるようになりました。
作業負荷の削減
大規模なボードがある場合、クイック フィルターを確認します。ボードでクイック フィルターを使用すると、元のフィルターとクイック フィルターの両方に一致する課題のサブセットに絞り込むことができます。大規模なボードでは多くの場合、2 〜 3 個の小さなボードに簡単にブレイク ダウンできる多数のクイック フィルターが使用されています。まず、もっとも頻繁に使用されているクイック フィルターを見つけ、それが何に焦点を当てているかを確認します。また、フィルターによる古い課題の除外についても確認します。1 年以上更新されていない課題があった場合、その課題が実現している価値を再確認することをおすすめします。古い課題を集めた 2 つめのボードをセットアップし、それらを定期的にトリアージして必要に応じてクローズまたは更新 (プライマリ ボードに表示) する方法もあります。
JQL では、課題の幅広い側面で検索することができます。担当者やレポーター (個人とグループの両方) 課題の経過日数、前回の更新からの時間、そしてもちろん履歴検索をにより、ある時点で特定のステータスや担当者などであった物事を表示することができます。課題が重要となっている原因の項目に焦点を当てることで、必要な課題が入ったボードにたどり着きやすくなります。
初期フィルターを構築したら、さまざまな方法で必要な課題への焦点を増やすことができます。
次のアイテムはユーザーの作業に焦点を当てるのに役立ちますが、すでにパフォーマンスの低下が発生している場合はおすすめしません。スイムレーンとカード カラーはいずれも JQL クエリを複雑化させるため、ボードの読み込み時間が長くなります。
- スイムレーンを使用すると、必要な JQL に基づいて特定の課題の順序を設定できます。たとえば、課題を優先度順に整理し、クリティカルな課題やブロッカーを一番上に移動させることができます。あるいは、担当者別に整理して、誰が何を行っているかを確認することもできます。
- クイック フィルターを使用することで、自身に割り当てられた課題などの自分に必要な課題を確認したり、最近更新された課題のみを取得して昨日以降の変更内容を参照したりできます。
- カードの色を使用することで、課題タイプや任意の JQL に基づいてカードの色をカスタマイズし、重要な課題をハイライトすることができます。
アトラシアンによる Jira Software を使用するしくみ
アトラシアン内には小さなチームが多数ありますが、それぞれの焦点や課題の処理方法が異なり、JIRA インスタンスが大幅に異なる、特に 2 つの大きなチームがあります。
サポート内で、地域チームに基づいて小さな個別ボードに分割されたカンバン スタイルのボードを実行します。サポート内では課題にランクを付けないため (先入れ先出しベースではなく、優先順位が考慮されます)、フィルターを変更してランク別順序を使用しないことを決定しました。代わりにランク順優先度とステータスの時間の組み合わせ別に並べ替えます。
これに加え、スイムレーンを大幅にカスタマイズし、エスカレーションされたチケット、クリティカルな課題、エンタープライズおよび未割当の課題を、クリティカルでない課題や割り当て済の課題よりも上に移動させ、いつでも最も重要な課題を一番上の行で素早く確認できるようにしました。その後、各エンジニアの作業負荷を視覚化し、次の課題を担当できるのは誰かを素早く決定できるようにしました。
一方、JIRA 開発チームは作業テーマに基づいて自分たちを小さなサブ チームに分割しました。これによって、それぞれがチームごとに独自のボードを持つことができます。一方プロダクト マネージャーは、ストーリーの集約ボードを使用して、それぞれのチームが実行中の作業を確認することができます。大局的に焦点を当てることで、ボードをシンプルにし、すべてをまとめ、処理するストーリーが最も多いチームはどれかを素早く確認することができます。
クライアント側の考慮事項
新しいボードは以前よりもクライアント側で多くの作業を行うようになったため、最初にアップグレードを行うと、古いブラウザーや低い性能のコンピューターを使っている一部のユーザーの読み込み時間が遅くなる場合があります。ボード サイズを縮小してブラウザー タイプやクライアント マシンの仕様を見直すことは、これらの問題の緩和に役立ちます。
Atlassian Long Term Support releases
An Atlassian Long Term Support release is a feature release that gets backported security updates and critical bug fixes during its entire two-year support window. If you can only upgrade once a year, consider upgrading to a Long Term Support release. Learn more
ソリューション パートナーについて
Especially when your JIRA Software has reached a more advanced size and complexity, we would recommend to collaborate with one of our Solution Partners.
お客様にマッチしたパートナーをご紹介できるよう、支援いたします。興味をお持ちの場合はお問い合わせください。