バグ追跡ツールでの連続的な優先度値ではなく、個別の優先度値

Question

バグ追跡ツール（およびおそらく他の同様のアプリケーション）では、チケットは連続的な値ではなく個別のカテゴリに基づいて優先されます。

これにより、奇妙で直感に反する状況が発生する可能性があります。たとえば、同じ開発者に20のチケットが割り当てられており、そのうちの3つにimmediate優先度がある場合、それはどういう意味ですか？ 3つのうち、どれが他よりも緊急ですか。ほとんどが最初に解決されますが、どれも多くの作業が必要だと考えていますか？または、開発者は3つのチケットを同時に解決するために3つの頭を持つドラゴンでなければなりませんか？

代わりに、継続的な優先順位は、3番目のチケットが4番目のチケットの前に解決される必要があることを示します。すべてが簡単になります。上から始め、最後のチケットを解決するまで下がっていきます。これらのチケットは、プロジェクトマネージャーによってドラッグアンドドロップで注文されます。

バグ追跡ツールが個別のカテゴリを使用する理由を説明する理由はありますか、それともそれが「常にこのように、永遠に行われた」だけの理由ですか？

Vitaly Mijiritsky · Accepted Answer

いくつかの理由があります。

まず、@ Chaseが指摘したように、バグの重要度を判断するのは比較的簡単なので、離散値の方が意味がありますが、同じ重要度の他のバグよりも優先度を付けても意味がありません。 QA担当者は、各バグの優先度について考え、他のバグと比較し、場合によってはチームメンバーと相談するためにたくさんの時間を費やす必要があります。彼らに関する限り、決定は実際には恣意的であり、あなたがそのような決定を彼らに強制するとき、それは多くの努力を必要とします。それは、多くの無駄な時間です。一方、同じグループの特定のバグを最初に処理する必要があり、それが他のバグを処理する可能性があることがわかる開発者にとって、それは恣意的ではない可能性があります。したがって、この方法では、適切な当事者が判断を下すことができ、「間違った」当事者が無意味な決定をめぐって闘うことから解放されます。

2つ目は、ほとんどの場合、多くの人がバグを提出しているということです。慣れていない他の人のバグをどのように優先するのでしょうか？そして、誰かが自分のバグに優先順位を付け、それらを大きな優先順位のリストにマージするだけでは、誰かがそれらの決定を行う必要があるためです。

Kashyap · Answer

開発者は3つの「即時」の優先バグを持ち、最初に修正したいバグを1つ選択する柔軟性を保持することを好みます。

コーディングする人だけが、他のバグよりも修正が容易なバグを知って、最初にそれに取り組む、「最短のジョブファースト」です。すべてが同じに見えるか、共鳴的に推定できない場合は、最も古いものを最初に釘付けします。

私がチェイスセイバートに同意します。それがショーストッパーである場合、誰かがおそらくあなたにそれを言うでしょう。

Lode · Answer

FogBugz と Pivotal Tracker の両方を使用しています。 FogBugzはカテゴリに基づいており、Pivotalは連続スケールに基づいています。

アジャイル開発/ Pivotalは、製品の所有者またはスクラムマスターが優先順位を決定する必要があることを提唱しています。そして、私の経験では、優先順位は1つのバグに厳密に関連付けられているわけではありません。 優先順位は、バグの修正の影響と、企業が現在向かっている方向のミックスになります。これは常に変化し、多くの場合はバグの送信者によって、またはバグの作成時に設定されるべきではありません。

これは、Pivotal Trackerが実際に機能する方法です。バグを送信すると、一般的なバグのプールに分類されます。そして、それをそこから取得した場合にのみ、優先順位を付けます。これは通常、製品の所有者またはチームミーティングで行われます。

他の人のメモとして、人々は優先度と重大度の違いに問題を抱えており、誤用しています。バグの重大度は提出者が推定できるものであり、おそらくプログラマーまたは製品の所有者によって確認または変更されます。 優先順位は、バグを発見または修正する人ではなく、決定を下す人の手にある必要があります。

しかし、それは製品の所有者が開発に優先順位と方向性を密接に与える組織がない場合があるかもしれません。次に、個々のバグ（送信者と修正者）で作業する人が実際に以前のバグの経験に基づいて優先順位を設定すると非常に便利です。

しかし、それらの状況でも、提出者がバグの優先度を自由に設定できないことがよくあります。または、たとえば2〜4の値（1〜5のスケール）のみ。システムを使用している他の人だけ（おそらくプログラマーまたは製品の所有者）が優先順位を設定できます。

Chase Seibert · Answer

バグ追跡システムの潜在的なユーザーとして言えば、離散値を持つことは私にはより理にかなっています。優先度の高いバグもあれば、低い優先度のバグもあります。ある高いバグが他のバグよりも重大であるかどうかを誰が言うのでしょうか。さらに、バグは通常、修正に数分しかかからないため、一度に多数をクローズするか、少なくとも同じバージョン/デプロイですべてをクローズする可能性があります。

バグが本当に致命的である場合、重要な誰かがやって来て、他のすべてを停止して修正するように要求することに賭けることができます。その場合、バグ追跡システムは実際には必要ありません。

一方、新しい機能のストーリーの追跡などの新しい作業では、継続的な値の方が理にかなっています。特にアジャイルの場合、実行可能なすべての作業のうち、より大きなスペースから「次の」X単位の作業を選択できることが重要です。 Xを超える作業単位をすべて同じ「優先度の高い」バケットに入れても、必要な場所に到達できません。