問題トラッカーで 1 つの問題に対して複数の担当者を設定することに意味はありますか?

StackOverflow https://stackoverflow.com/questions/7340865

質問

私は過去に JIRA と Bugzilla の管理者を務めていましたが、ユーザーから課題ごとに複数の担当者を指定できるようにしてほしいという要望がよくありました。

JIRA ではこれが可能であることは知っていますが、私の考えでは、それは決して意味がありません。課題は作品を表す必要があり、その作品を実行できるのは 1 人だけです (少なくともソフトウェアでは、私は 2 人のボブスレー チームで課題トラッカーを使用したことがありません ;-)) 大きな作品は、明らかに複数の人が関与しますが、その場合は正確なステータス報告を可能にするためにサブタスクに分割する必要があると思います。

複数の担当者を持つことが有効なユースケースを持っている人はいますか?

役に立ちましたか？

解決

譲受人のフィールドは、多くの人々にとって多くのことを意味します。より良い名前は、「責任あるユーザー」かもしれません。クライアントと話し合う3つのケースがあります。

A.譲受人の数= 0 Jiraには、許可されていない問題オプションがありますが、ワークアイテムが誰にも所有されていない場合、誰もが無視する傾向があるため、それを使用することを思いとどまらせます。

B.譲受人の数= 1デフォルトのケース

C.譲受人の数> 1この問題で表される作業項目の責任者は誰ですか？私がこれについて見た中で最も良いケースは、チームの1人が問題を処理できる場合、トリアージの前に問題がそのチームの全員に割り当てられることです。より良いアプローチは、チーム全体に送信するメールアドレスを備えたJiraユーザーを作成し、そのユーザーに割り当てることだと思います。その後、チームのメンバーは、特に問題を割り当てることができます。

1つの譲受人ケースを変更すると、[履歴]タブに履歴が記録されています。その場合、何も失われません。

他のヒント

多くの場合、複数の開発者に分割できるストーリー /機能があります。彼らは個別にサブタスクを割り当てていますが、リード開発者がいない限り、親を関係者全員に割り当てることは理にかなっています。私は実際に複数の割り当てを行うことができることを知らなかったので、ヒントをありがとう！

私が考えることができる他のケースは、ペアプログラミングです。

私はこれを行うための解決策を探している間にこの質問にぶつかりました。私はこれをやりたいので、私のユースケースはあなたの質問に対する答えとしてカウントされると推測しています：私は現在問題に取り組んでいる誰かの意味で1人の譲受人だけが本当に欲しいですが、私は問題のライフサイクル全体を追跡したいです。私たちにとって、それは次のことを意味します：

  1. サポート担当者が顧客からレポートを受け取り、問題を作成します
  2. Issue-wranglerは、問題を確認して、重複していないことを確認するために問題を確認します。すべての適切な詳細などがあります。
  3. 開発者は問題を実装/修正します
  4. テスターは、適切なテストを実行します（私たちの場合、主に自動化されたテストスイートを拡張して機能/修正をさらにテストします）
  5. 運用担当者がテスト環境に新しいバージョンを展開します
  6. サポート担当者は、テスト環境で新しいバージョンで自分のテストを行う顧客に通知します
  7. 運用担当者が新しいバージョンを制作に展開します

すべての問題が必ずしもすべての手順を実行するわけではありません。いくつかの問題には、より多くの手順があります（たとえば、ステップ3と4の間のコードレビュー）。また、多くの問題がステップの間で後方に移動します（開発者はより多くの情報が必要です。ステップ3から1または2に移動します。テスターは問題を見つけ、4から3に進みます）。

各段階で、実際に何をしなければならないかについては、1人だけが責任を負います。それにもかかわらず、この問題に関連付けられている人々がたくさんいます。私たちが使用した追跡システムは、問題の以前の所有者に簡単な変更を提供します（リストとして表示されます）が、私は理想的にはさらに一歩進めたいと思っています。問題のステータス。ステップ6では、ステップ1の元のサポート担当者が理想的に顧客に連絡する必要があります。ステップ7では、ステップ5のOPSの人が理想的には譲受人になります。

言い換えれば、特定のステップに複数の譲受人を望んでいませんが、「サポート譲受人」、「開発者譲受人」、「テスト担当者」などが必要です。

サブタスクでこれを行うことができ、ステータスを変更するときに以前の所有者を手動で選択することでそれを行うことができますが、どちらも理想的ではなく、上記の状況は複数の譲受人が理にかなっていると思います。

私の会社では、Nikhil と同様のワークフローを採​​用しています。私たちはスクラム モデルで作業しており、各チームに開発者、テスター、テクニカル ライターがいます。

開発タスクのワークフローは次のとおりです。

開発 -> 開発者レビュー -> QAテスト -> PO受理 -> 完了

QA タスクのワークフローは次のとおりです。

QAがテストケース/自動テストを作成 -> QAレビュー -> 完了

JIRA に置き換えられたツールを使用すると、複数の人をタスクに割り当てることができ、ワークフローにとって非常に便利であることがわかりました。QA タスクでは、チームの他のテスターがすでに作業を終えていて、自分が次のステップを実行する必要があるかどうかを簡単に確認できました。

これがないと、スクラム チームの他のテスターが書いたタスクで、私がレビューできる状態になっているタスク (私が書いたタスクで、他のテスターがレビューする必要があるタスク) をすぐに特定するのが難しいことがわかりました。

少なくとも 2007 年以来、多くの人が複数の担当者を持つ機能を求めてきました。さまざまな有効な使用例があります。JIRA開発チームが一方的にこれを実装しないので再考を求めると言ったのにはがっかりしました。

https://jira.atlassian.com/browse/JRA-12841

  1. ペアグループが機能している間（ペアプログラミングなど）、両方の人を問題に割り当てることができます。

  2. タスクは、開発を通じてさまざまなステップを移動します（例：開発、レビュー、テスト）。さまざまな人が各ステップに対して責任を負うことができます。タスクはレビューまたはテストにある可能性がありますが、レビュアーには開発者が修正するものがあります。異なる役割を割り当てることは、作業の整理に役立ちます。

私たちのチームでは、通常1人または2人を一緒に開発します。その後、コードは、個別またはペアで約2〜5人によってレビューされ、最初に1〜2人がテストし、最終的にチーム全体でテストされます。

現在、当社のシステムにより、特定の時間に一人の人を割り当てることができます。これにより、問題のログを調べることなく、誰が何に取り組んでいるのかをフォローする能力が制限されます。複数の人を割り当てることができる蜂の巣の恩恵は私たちにとって良いことです。

ジョンにタスクが割り当てられてそれを完了できない場合、ジョンが怠け者だったのでジェーンのリストに移動した場合はどうなりますか？

それが元々割り当てられた歴史と、それに費やされた /請求された時間の歴史を失っても大丈夫ですか？

eラーニングシナリオでは、複数のユーザーに問題を割り当てることは理にかなっています。これが私がやりたいことです。アニメーター、レコーディングアーティスト、グラフィックデザイナーなど、3人に同時に割り当てたいストーリーボードがあります。これらの人々がタスクを完了すると、彼らはそれを共通のレビュアーに伝え、問題をレビューして閉鎖します。グラフィカルには、次のようになります：

                   Storyboard
                 /     |     \
           graphics animator recording
                 \     |     /
                    reviewer
                       |
                     done

3つのジョブの役割は、1つのストーリーボードのみに依存します。 3人の編集は、レビュアーに行く必要があります。私はこれをRedmineで機能させるために脳を悩ませています。まだ解決策を見つけていません。

アトラシアンのパートナーからこの答えを得ました https://www.isostech.com/solutions/そして後にアトラシアンから

目的：問題の各ステップで誰が作業を行うかを設定したい

概要：プラグインを使用して、問題が新しいステップに移行するたびに、カスタムフィールドから譲受人フィールドに値をコピーします。

方法：1。スイートユーティリティプラグインのインストール：このプラグインは、ワークフローに新しい機能を追加します。

プラグインを使用して、カスタムフィールドの値を譲受人にコピーします。

  1. 各役割の単一のユーザーピッカーとしてカスタムフィールドを作成します。

  2. これらのフィールドをIssueタイプの画面に追加します

  3. 各ステップ間のワークフロートランジションのポストファンクションを変更する「他のフィールドからのコピー値」ポスト関数を追加し、適切なユーザーカスタムフィールドから値を譲受人フィールドにコピーするように設定します。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top