私が働いている会社のいくつかの開発チーム内で使用できるかどうか、JIRAをレビューしています。プロジェクト管理のベースとしてスクラムを使用します。優れた自己組織化チームがあり、割り当てられた作業はほとんどありません。JIRAはこれらの項目の一部に適しているように見えますが、私たちが苦労しているのは、プロセスと技術タスクの管理、および「問題のバンドル」と呼ばれるものです。
プロセス制御。現在、「損益レポートのグラフに凡例テキストの重複に関する問題があります」というストーリーを作成します。さて、十分です。次に、技術的なサブタスクを作成します。簡単にするために、「問題を調査して修正する」としましょう。次に、作成する一連のプロセスサブタスクがあります。ピアレビュー、ビルドの作成、QAテスト、マージ、追跡。次に、これらのそれぞれをユーザーに個別に割り当てて、スクラムボードの保留中のビンに配置できます（ところで、todo、進行中、完了モデルではなく、保留中、待機中のアクション、進行中、完了、マージ済みモデルを使用します）。保留とは、基本的に、次に優先されるかどうかを待っていることを意味します。開発中、プログラマーは技術的なタスクを取得し、自分を担当者として設定し、進行中の状態に移行します。完了したら、それを[完了]ビンに移動し、ピアレビュープロセスのサブタスクを[アクションを待機中]に更新して、担当者をコードパートナーに設定します。メールが送信され、ピアレビューが行われます。それが完了すると、ピアレビューパートナーはピアレビューを完了ビンに移動し、ビルドの作成サブタスクをビルドマネージャーに設定して、アクション待ちに移動します。ビルドマネージャーはこれを確認し、ビルドを実行して完了に移動し、QAテストチケットをアクション待ちのステータスに更新します。ポイントを取得します。それが完了すると、ピアレビューパートナーはピアレビューを完了ビンに移動し、ビルドの作成サブタスクをビルドマネージャーに設定して、アクション待ちに移動します。ビルドマネージャーはこれを確認し、ビルドを実行して完了に移動し、QAテストチケットをアクション待ちのステータスに更新します。ポイントを取得します。それが完了すると、ピアレビューパートナーはピアレビューを完了ビンに移動し、ビルドの作成サブタスクをビルドマネージャーに設定して、アクション待ちに移動します。ビルドマネージャーはこれを確認し、ビルドを実行して完了に移動し、QAテストチケットをアクション待ちのステータスに更新します。ポイントを取得します。
それは機能していますが、代替案、ベストプラクティスなどに関する提案はありますか？技術的およびプロセスのサブタスクを作成することは、進むべき道ではありませんか？私が気づいたことの1つは、サブタスクを非表示にするために問題リストをフィルタリングする必要があることです。スクラムボードは、親ストーリーのステータスを確認したいだけの利害関係者にとってはかなり圧倒される可能性があります。親ストーリーはサブタスクが移動するまで移動しないため、サブタスクの移動中にストーリーが「進行中」であっても、関心のあるものは何も表示されません。うーん。
バンドルを発行します。多くの場合、おそらく密接に関連しているが、通常はより一般的な一連の問題があります。たとえば、ソフトウェアのレポートに関連するすべての問題。現在、15の既知の問題があります。これらの問題は、再現するための特定の手順など、システム内のさまざまなレポートにある可能性があります。スプリントに向けて準備をしているときに、これらの関連する問題のバンドルを選択します。その理由は、QAは、各レポートを個別のプロセスとしてテストするのではなく、通常1回のパスで関連する一連の小さな修正をより効率的にテストできるためです。
現在、各号をバンドルのサブタスクに移動しています。たとえば、バンドルは単に「レポート修正1」と呼ばれる場合があり、たとえば、技術的な5つのサブタスクがあり、それぞれが修正される異なるレポートバグです。次に、上記のプロセス制御項目をバンドル全体に追加できます。また、バンドル内のすべてのアイテムが完了するまでマージされないこともわかっているため、すべて同じバージョンになります。
ただし、前述のように、サブタスクがバンドルに含まれているため、サブタスクのステータスを簡単に確認できないため、可視性が低下します。
繰り返しますが、ベストプラクティスですか？アイデア？他の人はこれをどのように扱っていますか？