報告されたほとんどすべてのバグは、優先度の高いバグです[終了]

いくつかのソフトウェアプロジェクトの作業中にパターンに気付きました。報告されたバグの大部分は、優先度が非常に高い/非常に高いものでした。私は何人かの同僚になぜこれが起こっているのかと尋ねましたが、バグがその優先度を持たない場合、バグが開発者の注意を引くことは非常にまれであると述べました。

ですから、この問題が一般的なのか、それとも運が悪かったのかを知りたいと思いました。Googleで簡単に検索したところ、一部のチームがバグ報告ガイドラインを実装しているか、別の「バグトリアージ」チームを持っていることがわかりました。この問題に直面して解決した場合、どのアプローチが効果的でしたか？

この質問は、具体的には「優先インフレ」問題に関するものです。シナリオに直面した場合、およびこの問題に対してどのような対策が効果的か。

何が起こっているのかを同僚に尋ねたところ、バグがその優先度を持たない場合、バグが開発者の注意を引くことは非常にまれであると述べました。

実際に、あなたが私に尋ねると、そうではありません。優先度の（使用済み）レベルが高いほど、より多くの情報が得られます。実質的に優先度が1つしかない場合、それは優先度をまったく持たないのと同じことです。

そして、あなたはまだ同じ数のバグに取り組む必要があり、それを行うために同じ工数を費やしているので、他のヒューリスティック、おそらくヌルのヒューリスティックが使用されます-「先着順」。これで、バグの優先度メトリックが得られました。ただし、それは到着時刻であり、もはや制御できません。

これは、バグ修正に割り当てられているだけでは不十分なリソースの徴候である場合もあります（「のようないくつかの政策があるバグが修正されるまで、新しい機能があり助けることができる」。ジョエルが承認し、理解の限界と結果は、ビジネスの意思決定）。

私が取り組んだあるプロジェクトでは、入ってくるバグは「優先バッファなし」に蓄積され、毎週月曜日にバグリストを確認し、難易度を推定しました（非常に大雑把な推定です。利用可能な時間で並べ替えます。これは、退屈な、面白くない、または考え抜かれたバグをリストに落とし込む傾向がありました。それを相殺するために、スーパーバイザーとマーケティングは、お気に入りのバグの優先順位を上げるために費やすことができる週に一定のクレジットを持ち、未解決のバグの払い戻しを受けました（これにより、開発者が依存するバグを遅らせることができる限度が設定されました） 。

バグをマージ、キャンセル、分割することもできました。あまりにも絶望的に欠陥があった1つのモジュールを覚えているので、20から30のバグレポートを単一の「ゼロからこのものを書き直し」にし、それを「惨めなものの入力と出力を明確に述べる」、「テストを書く」入力と出力が仕様に一致することを確認します」など。最後の項目は、「古いコードを再生紙に印刷し、芝生の上に置いて燃やします」でした（私たちもそれを行いました。それがどれほど良い感じだったかを覚えています。 ）。

いくつかの苦労の末、今週の予定リストがありました。これは、「やる」、「やる​​」、「できない」に分かれていて、来週にぶつかりました。これが追加のハグリングの出番です。バグに割り当てるのに50時間と言っていましたが、最初の20個は95％確実に修正できました。経営陣は、21番目のバグの修正を強く望んでおり、クレジットが残っていませんでした。次に、そのバグを「Will do」リストのバグと交換するか、誰かが「FooBazFeatureサブチームから数日間降りて、それをやる」と言うか、「もっと必要です」と言うでしょう。人材」。

システムは本当に誰も満足しませんでしたが、これは（少なくとも開発者の間では）良い兆候だと信じられていました。

現れたいくつかの追加のネガティブなパターンは、マネージャー側の「希望的観測」（「バグ57212には8時間かかると述べました。これは受け入れられません。4にする」）と「フィアットによるデバッグ」（「好きなことをしてください」）しかし、これらの40個のバグは、来週の大きなデモの前に修正する必要があります。これ以上の時間を確保することはできません。また、ボクサー症候群（「私は一生懸命に働きます」）も短期間はうまく機能する傾向がありましたが、通常は開発者が緑の牧草地に飛び込んだり、離れたりします。

ユーザーがより高い優先度のバグを割り当てているこの問題がある場合、唯一の現実的な解決策はトリアージメカニズムです。すべてのバグは、好きな優先順位で報告されますが、一部の貧しいマネージャーは、新たに報告されたすべてのバグを調べて、優先順位を適切なレベルにリセットする必要があります。

しばらくすると、ユーザーがメッセージを受け取るか、すべてのバグがデフォルトの優先度になるようにレポートシステムを変更できます。エスカレートしたい場合は、誰かに連絡してバンプする必要があります。これには正当化が必要です。この事実だけでも、すべてのバグの99％がユーザーによってエスカレートされないままになります。

明らかに、処理できる数よりも多くのバグがあるため、バックログをクリアするにはバグ修正のまとめに着手する必要があるかもしれません。これにより、バグが修正されることをユーザーに示すことができます。バグを修正する必要はありません。

免責事項：ユーザーから報告されたバグの優先順位に関する経験はまだありません。質問がこれを要求していることは知っていますが、部外者の視点を持つのに役立つかもしれません。

問題は、優先度の高いバグが多すぎるということではありません。問題は、バグの優先度を直接制御できる人が多すぎることです。すべてのユーザーがバグに優先度を直接割り当てることができる場合、ユーザーはほぼ自動的に問題を高優先度として報告します。

バグの優先順位をマネージャーまたはヘルプデスクのドローンが設定する必要があるようにできますが、これは、クライアントのステータスやメッセージの作成方法を知っているために、クライアントが人為的に高い優先順位を取得する優先順位とソーシャルエンジニアリングにつながる可能性がありますそれらをより重要に見えるようにします。また、労働集約的です。

ユーザーが優先順位をある程度制御できるが、システムを悪用するのを難しくする中間的な状況があります。基本的に、バグの報告にテンプレートを使用するようユーザーに強制します。彼らは最初にカテゴリーを選択します：

1. プログラムを使用できなくなるか、何かをするとクラッシュします。
2. このプログラムには、機能に影響するグラフィカルな欠陥があります。
3. このプログラムでは、できるはずのことをすることができません。
   このプログラムは、私ができないはずのことをすることを可能にします。
4. 私が何かをすると、プログラムは間違った結果を出します。
5. プログラムは何かをするのに時間がかかりすぎます。
6. このプログラムには、機能に影響を与えないグラフィカルな欠陥があります。
7. このプログラムには、上記のカテゴリのいずれにも当てはまらない欠陥があります。

例を挙げると：

1. ヘブライ語の記号を含むメッセージを受信すると、iPhoneがクラッシュします。
2. Androidロック画面は、画面の半分が落ちるように回転します。
3. 正しいコードを入力したにもかかわらず、Androidスマートフォンがロック画面コードを受け入れない場合があります。
4. PhoneHub.netに移動しようとすると、携帯電話からアダルトサイトにリダイレクトされます。
5. Facebookアプリを開くと、高速接続でも他のアプリが実行されていなくても、開くのに1分かかります。
6. アプリにスペルミスがあります。
7. プログラムにセキュリティ上の欠陥が見つかったため、報告したいと思います。

ご覧のとおり、これらのエラーにはそれぞれ重大度の異なるグレードがあり、カテゴリはこの重大度に基づいて大まかに並べられています。次に、各バグをカテゴリ、報告者、および説明に表示されるキーワードに基づいて優先順位を割り当てることができます。カテゴリ7のバグは、優先度を手動で割り当てる必要があります。

これは完全に自動的に発生する可能性があることに注意してください。これは自動的に発生させる必要があります。実際、ここで重要なのは自動化です。ユーザーはビジネスに対する自分自身の重要性を過大評価する傾向があるため、バグを報告する際に問題を優先順位よりも高い優先順位で表示することはありません。基本的にバグについてうそをつく必要があるため、意図的にバグを別のカテゴリに配置する傾向はありません。

もちろん、ユーザーはバグを間違ったカテゴリに入力する可能性があります。最初にすべきことは、バージョン1.0から、ユーザーがバグに関する正確な情報を提供することを促すフレンドリーなメッセージを表示し、開発者がバグをすばやく見つけて修正できるようにすることです。ほとんどのユーザーは、バグの誤報告を理解して停止します。一部のユーザーは引き続き間違った情報を提供する可能性があります。その場合、正確な情報が重要であり、システムを悪用しないように、それらのユーザーにメールで穏やかなリマインダーを送信してください。記録を改ざんし続けている場合は、システムを故意に乱用していることを警告し、悪用を続けるとバグが自動的に下位のカテゴリに割り当てられます。持続する場合は、バグ乗数を調整できます。

このシステムの一部は、高スループットのサポート状況で適切に表示されます。Microsoft、Facebook、Google、ValveやBlizzardなどの多くのユーザーを抱えるゲーム会社、特定の政府など...舞台裏の仕組みの中で、ユーザー向けのサポートシステムには、ここで提案するものと同様のインターフェイスがあり、厳密なカテゴリシステムがあることがわかります。

人々が言っ​​たように、これがバグを報告する人々が優先順位を割り当てられない理由です。開発チームは、（上級管理職によって設定された範囲内で）自分のタスク割り当てを管理する必要があります。だから、誰かがさらにアップ「の仕事と言うこのアプリ、修正この良くやってでそれを作る、機能をこれを」、そしてチームは、彼らがしているので、技術的な専門知識を持つものがどのように評価するのに必要な、それについて移動する方法を決定するために取得します経営陣が望むものを達成するのが最善です

バグを報告する担当者は、範囲を定義した影響または重大度レベルを割り当てる必要があります。合意された重大度レベルに固執していないことを人々に簡単に呼びかけることができます。これらのレベルの重要な証拠があるからです。例えば：

1. 機能の完全な喪失
2. 機能の部分的な喪失
3. 有効性の広範囲にわたる低下
4. 有効性の局所的な低下
5. 迷惑または妨害（回避策が存在します）
6. 化粧品
7. 誰も実際に気づかなかった、あいまいな探索テスト中に発見された

まず、これらのレベルを鈍器として使用して、一部のタイトルテキストのずれがレベル1のバグではないことを指摘できます。これは、アプリケーション全体が使用できなくなるわけではないからです。彼らがアイデアを手に入れたら、よりきめ細かくすることができ、この1つのテキストボックスを更新する際の不具合がレベル5であるかどうかを議論することができます。経理部門の全員が遅くなり、1時間あたりに処理されるフォームの数が少なくなるためです。

バグが組織にとってどれほど悪いかについての有用で測定可能な情報を得たら、優先順位の割り当てが明らかになります。現在、組織にとって最大の問題を引き起こしているもの-利益の損失、公共イメージへの損害、従業員の不幸など-が最優先事項となり、そこから先に進みます。

次のようになります。

Mgr：何に取り組んでいますか？開発者：この優先度の低いタスクMgr：優先度の高いタスクに取り組むべきではありませんか？

クライアント：バグはいつ修正されますか？開発者：優先度が低く、優先度の高いタスクがあります。クライアント：それでは、バグのステータスを高い優先度に設定してください。

これにより、優先レベルが常にエスカレートされます。あなたはすでに高い優先度を超えて非常に高い優先度になっています。次は何ですか：

1. 超高優先度
2. 超高優先度
3. 非常に高い優先度。
4. 非常に超ウルトラメガ高優先度。

などなど

はい、これは通常のプロセスです。優先度の割り当てに費用がかからず、発信者が影響力を持っている限り、もちろん、彼らは問題を最速で解決し、最高の優先度を設定しようとします。

これに対抗するには、基本的に2つの方法があります。

1. 優先度レベルに関して、クライアントから制御を奪います。
2. 優先レベルを上げるために、クライアントにコストを関連付けます。

特にJiraの場合は、システムにさらに高い優先度レベルを追加できます。新しい高優先度をますます愚かにしますが、ひどい名前を付けると、すべての関係者が行う優先度の選択の質におけるホーソーン効果の増加を増加させる可能性があります。最も優先度の高い名前が本当に風変わりな名前である場合、その効果は永続的なものになる可能性があります。最終的に誰かが優先順位を選択するとき、彼らは「死のバグ」優先順位を選択することの社会的結果とそれに注意を払うことを比較検討しなければなりません。そのため、ゲストの目の前で自宅のCTOに起こった事実、または同等の可視性のある他の出来事のために事実上確保されているのが最優先事項です。

リクエストをサポートするためのコストを導入します。ユーザーは、一定期間内にX個の優先度の高いアイテム、Y個の優先度が中程度のアイテム、およびZ個の低優先度のレポートのみを許可できます。

もちろん、それはまた、開発チームと管理者がこれらの特定の数が実際に修正されることを保証する必要があることを意味します-すべての高優先度アイテム、ほとんどの中優先度アイテム、および（おそらく）いくつかの特定の期間内の優先度の低いアイテム。

しかし、これがうまくいくなら、経営陣は実際にそれに投資しなければなりません。さもなければ、全体の運動は時間の無駄です。

しかし、結局のところ、あなたの特定の状況は、経営陣がサポートの問題に対処するために十分なリソースを割り当てていないという問題の症状のようです。問題がタイムリーに処理されていた場合、私はこれが起こっているとは思わない。

このようなことは、サポートプロセスが機能しなかったため、私が最初に勤務した会社で実装され、すべてが緊急事態である場合、何も起こらない状況に至りました。私たちの場合、社内の状況を管理した後、新しいソフトウェア開発マネージャーは、サポート契約で支払った金額に応じて、顧客が提出できる優先度の高い問題の数に厳しい制限を設けました。彼らが制限を超えた場合、彼らはより多くの現金を吐き出すか、サポートの問題の優先度を下げました。

これは、ITが補助的であると見なされたり、外部委託されたりする大企業で非常に頻繁に発生します。ビジネスの人々はソフトウェアを理解せず、気にしません。彼らが気にするのは、それがどれほど重要でないかに関係なく、「彼らの」バグが昨日修正されることです。彼らは、バグを報告している他の100人のユーザーと、5人の開発者からなるチームが問題を修正できることを認識していません。

これは、貧弱な管理者、特に「ノー」とは言えない、または単にビジネスの人々にバグの優先順位を設定させるIT以外の管理者によって悪化しています。（どちらの場合も、マネージャーは仕事をしていないと述べた。）ほとんどのマネージャーは、「緊急」のために最後に連絡したバグを優先します。最終的な結果は、開発者がバグからバグへとジャンプすることになるため、1つのバグの修正に時間がかかり（コンテキストの切り替え）、最終的には誰もが不幸になります。「すべてのバグが優先度の高いバグである場合、優先度の高いバグはありません。」

私はこの状況にありました、そして一般的にそれを逃れる唯一の方法は外に出ることです。ユーザーはas ** tを指定しないため、バグ報告のガイドラインは常に無視されます。バグのトリアージを導入しようとすることは抵抗されるか、ユーザーが次に「彼らの」バグについて不平を言うためにあなたのマネージャーに電話するときに実装され、無視されます。

基本的に、開発者が優先順位を制御できない場合、あなたはすでに負けています。

会社として、あなたは最高の重要性/コスト比で問題を解決したいと考えています。ユーザーが重要性を決定し、エンジニアリングがコストを決定します。ユーザーがすべてのバグに同じ重要度を割り当てた場合、コストだけが問題になります。

実際には、これは重要度/コストとして優先度を定義し、ユーザーや開発者がその優先度を直接設定できないようにすることを意味します。どちらの側にも全体像はありません。

ユーザーがすべての問題を同等に重要と評価することを決定した場合、それは問題ありません-しかし、それはエンジニアリング（コスト）が何を行うかを決定することを意味します。重要性が優先度に影響を与えることができる（決定はしない）唯一の方法であることを説明します。

いくつかの要因...

• 多くの場合、バグを報告した人は全体像を知らず、バグの重要性を判断できません。
• 多くの場合、優先度の低いバグはトリアージまたは考慮されることはありません。したがって、優先度が高すぎてトリアージを行っている人にそれを低くする方がよいでしょう。
• 開発者として、私はよくバグレポートを見て、バグの背後に非常に高い優先度の問題があることを発見しましたが、トリアージを行うプロダクトマネージャーはバグを気にしません。

だから私は、すべてのバグレポートを1〜2人の経験豊富な開発者がすばやく検討し、彼らの考えをバグレポートに追加してから、バグをトリアージする必要があると思います。バグを見つけた人が、それを見つけた時点で有用な優先順位を設定できると期待するのは、あまりにも多くを求めているだけです。

記載されているすべてのバグの優先度が高い可能性があります。私は資金不足と仕様不足の両方のプロジェクトに取り組んできましたが、テストの開始時にQAとユーザーは優先度の低いアイテムの報告をあきらめました。完全にホース接続されました。あなたの場合は、自動手荷物システムが一緒にカートをクラッシュし、荷物を破壊しているタグのフォントが小さすぎる2PTであれば、誰が気に？

このような状況では、プロジェクトは失敗しています。これが可能性でさえあると疑う場合、あなたは見つけるために欠陥を報告する人々と心から心が必要です。人々がバグレポートを膨らませている場合、他の答えが役立ちます。バグが報告されているほど悪い場合は、極端な行動を取る必要があります。

ほとんどはすでに述べていますが、「バグ動物園」リストを少し粒度の低いものに絞り込みます。

A：このバグは、ユーザーをトラックで停止させ、間違った出力を与え、一般にシステム/機能/機能を使用できなくします。これは「優先度の高い」バグです。

B：他のすべて。 これらは「交渉可能な」バグです。

NEGOTIABLEのバグはさまざまな懸念事項に該当します（独自の順序で配置します）。

1：セキュリティに影響するバグ。

2：使いやすさ（意図した目的への適合性）に影響するバグ。

3：美学に影響を与えるバグ。

4：パフォーマンスに影響を与えるバグ（おそらく使いやすさのサブセット？）;

5：プロのプログラマーとしてのあなたの感受性を損なうバグ。

6：ユーザーの信頼を低下させるバグ。

だから、私たちのどれも実際にライブであることユートピアの世界だ。 ため息 OPの規定の質問に私の答えを完了するために、全体のソフトウェア業界全体では、開発努力はすべての単一のバグがpriority-ある状態であるために全く一般的ですワンスーパーバンガースペシャル。そして、あなたは彼らが「特別」について何を言っているか知っています：誰もが特別であるとき、誰も特別ではありません。

基本的に、この問題は優先順位付けの分散化の問題に根ざしています。チームのワークロードを優先する能力を持つ人は常に奇数人である必要があり、3人は多すぎます。そのため、1人が効果的にトリアージを担当します。そして、開発者/アーキテクトと相談して、マネージャー/アナリストでなければなりません。また、プロセスは非常に簡単で、機能のリクエストにも適用できます。開発にかかる費用はいくらですか？ビジネスに期待される結果の価値は何ですか。その関数の出力は、割り当てられた優先度です。

もちろん、すべてのユーザーが最初に問題を修正することを望んでいます。そして、あなたがそれを許すとすぐに、混乱。有効な優先順位付けがありません。これは、権限（必要に応じて他の人と相談）を持ち、すべての問題とビジネスニーズについて可視性を持ち、必要なビジネスとITの専門家のアドバイスを収集してメトリックの合理的に正確な推定値を生成する能力を備えた1人の人物が行う必要があります上記。

言うまでもなく、デフォルトとしてバグを高い優先度に設定している（またはこの設定に設定されている）バグ追跡ソフトウェアがないと仮定します。

コントロールがない場合、これは複数のチーム、クライアントなどが報告するデフォルトのシナリオです。現状が悪用されている場合、何らかのトリアージプロセスが間違いなく正常に行われています。

過去に非常にうまく機能していることを私が見た素早い勝利は、P1（最優先のバグ）が大量の管理アラートを生成したことです。システムが悪用された場合、すぐにダウンします。または、それが本当に緊急の場合は、電話会議または物理的な会議で、できるだけ早く問題に対処します。

ここでは、最初の開発のバグだけでなく、すべてのバグについて話していると想定しています。あなたが一般的に雇用のためのグリーンフィールド開発銃なら、ほとんどのバグが最初のアルファリリースに続いて高い優先度であることは確かに珍しいことではありません。

優先順位を設定して、すべてが魔法のように機能することを期待することはできません。時々、人々は自分でそれを理解しますが、常にそうではありません。

優先順位を正しく割り当てるには、各優先順位を正確に定義する必要があります。これらの基準は、バグの支持と政治的優先順位付けを避けるために客観的でなければなりません。客観的な基準が守られていない場合は、チームがそれに従うようにする必要があります。

本当にこれを回避する方法はありません-どのバグがどこに行くかについて客観的な基準を持たない場合、そして人々がこれらの基準を尊重することを故意に拒否する場合、あなたは提出者が割り当てた優先順位を持っていないかもしれません-優先順位なしで行うか、持っています他の人が提案したように、第三者が優先順位を割り当てます。クラウドソーシングされたデータは、提出者が協力的であり、データ収集を積極的に妨害しない場合にのみ機能します。

客観的な基準を作成できないために困難が生じる場合は、相対的な基準を使用できます。

• すべてのバグの単純なキューがあります。ユーザーは、キューのどこにでもバグを挿入できます。バグはその下のすべてよりも重要であると感じた場合にのみ、特定の位置に挿入する必要があります。バグ修正はキューの先頭から始まります。
• すでに十分に分類された一連のバグがあると仮定して、バグを優先する条件はX、すべての優先度のバグよりも重要でなければならないことを全員に伝えますX-1。
• X優先度の高いバグの数が優先度の高いバグの数を超えることはないことを提出者に伝えてくださいX-1。

しかし、あなたの問題は定義ではなく、低優先度のバグは修正されないという提出者の信念のようです。おそらく、（あなたの言うことから）彼らの信念は実際には根拠があるので、そうでないと彼らを説得することはできません。それでは、なぜこれらのバグを提出させるのですか？最終的には忙しい仕事に過ぎません。たとえば、特定の数のアクティブなバグに到達した後、最も顕著なバグよりも重要な何かを見つけたと感じない限り、誰もレポートを作成しないように指示できます。確かに、これはキューの長さに上限がある単なるキューソリューションです。