報告されたほとんどすべてのバグは優先度の高いバグです
いくつかのソフトウェアプロジェクトで作業しているときにパターンに気づきました。報告されたバグの大部分は高い/非常に高い優先度を持っていました。何人かの同僚になぜこれが起こっているのかについて尋ねたところ、バグにその優先度がなければ、バグが開発者の注意を引くことは非常にまれであり、それは実際に理にかなっていると彼らは述べました。
それで、私はこの問題が一般的であるのか、それとも運が悪かったのかを知りたかったのです。すばやくGoogle検索を行ったところ、一部のチームはバグ報告ガイドラインを実装しているか、別の「バグトリアージ」チームを持っていることがわかりました。この問題に直面して解決した場合、どのようなアプローチが効果的でしたか？
この質問は、具体的には「優先インフレ」問題に関するものです。シナリオに直面した場合、およびこの問題に対してどのような対策が効果的であるか。
何が起こっているのかについて同僚に尋ねたところ、バグにその優先度がない場合、バグが開発者の注意を引くことは非常にまれであり、それは実際に理にかなっていると述べました
実際、あなたが私に尋ねればそれはしません。 （使用された）優先度のレベルが高いほど、より多くの情報が得られます。実質的に1つの優先順位しか持たない場合、それはまったく優先順位がないことと同じです。
また、対処するバグの数は同じで、そのために必要な工数も同じであるため、他のヒューリスティックが使用されることになります。おそらく、ヌルのヒューリスティック-「先着順」です。これで、バグの優先度の測定基準が得られました。ただし、それは到着時刻であり、制御できなくなった場合を除きます。
バグ修正に十分なリソースが割り当てられていないことの症状である可能性があります（「 バグが修正されるまで新しい機能はありません 」などのポリシーがあり、そこで役立ちます Joelは承認します ;制限と結果を理解することは ビジネス上の決定 ）です。
私が取り組んだ1つのプロジェクトでは、入ってくるバグは「優先度なしのバッファー」に蓄積され、毎週月曜日にバグリストを確認して難易度を推定しました（大まかな見積もりです。利用可能な時間で並べ替えます。これは、退屈な、興味のない、または難しいと思われるバグのリストを押し下げる傾向がありました。それを相殺するために、監督者とマーケティングは、お気に入りのバグの優先度を上げるために費やすことができる週あたりの特定の数のクレジットを持っていて、未解決のバグに対して払い戻しを受けました（これにより、開発者向けのバグがどれだけ遅れるかの制限が設定されました）。 。
バグのマージ、キャンセル、分割も可能でした。どうしようもなく欠陥があり、20か30のバグレポートを1つの「このものを最初から書き換える」に陥った1つのモジュールを覚えています。それは「惨めなものの入力と出力を明確に述べる」、「書き込みテスト」に分割されました。入力と出力が仕様に一致することを確認します」など。最後の項目は、「古いコードを再生紙に印刷して、芝生の上に置いて燃やす」でした（私たちもそうしました。気持ちが良かったのを覚えています。私たちは賛辞を交わしました。とても面白かったです。 ）。
少しの騒ぎの後、私たちは次の週にぶつかった「する」、「するかもしれない」、「できない」に分けられた週のやることリストを持っていました。ここで追加の問題が発生しました。バグに割り当てるのに50時間かかったと私たちは最初の20を修正するために95％確実でした。経営陣は21番目のバグの修正を強く望んでおり、クレジットは残っていませんでした。次に、そのバグを「Will do」リストのバグと交換することを提案します。または、「FooBazFeatureサブチームから数日間降りて、それからやります」と言うか、または「もっと必要です。マンパワー」。
システムは実際には誰も満足しませんでしたが、これは（少なくとも開発者の間では）良い兆候であると信じられていました。
現れたいくつかの追加の否定的なパターンは、管理者側の「ウィッシュフルシンキング」（「バグ57212には8時間かかると述べた。これは許容できない。4にする」）と「フィアットによるデバッグ」（「好きなことを何でもして」）しかし、これらの40のバグは、来週の大きなデモの前に修正する必要があります。これ以上時間をかけたり、人を増やすことはできません。」また ボクサーシンドローム （「もっと頑張る」）は、短時間で非常にうまく機能する傾向がありましたが、通常、開発者はすさまじいまたは緑の牧草地に向けて出発しました。
ユーザーがこれまでよりも高い優先度のバグを割り当てているこの問題がある場合、唯一の現実的な解決策はトリアージメカニズムです。すべてのバグは好きな優先度で報告されますが、一部の貧弱なマネージャーは、新しく報告されたすべてのバグを調べ、優先度を適切なレベルにリセットする必要があります。
しばらくすると、ユーザーにメッセージが表示されるか、レポートシステムを変更して、すべてのバグにデフォルトの優先度を設定できます。エスカレートしたい場合は、誰かに連絡してバンプさせる必要があるため、正当化する必要があります。この事実だけでも、すべてのバグの99％がユーザーによってエスカレーションされないままになります。
明らかに、処理できるよりも多くのバグがあるため、バックログをクリアするために、バグ修正のまとめに着手する必要があるかもしれません。これにより、ユーザーは、バグがsuper-super-dooper-really-no-honest-this-time-importantとしてマークされていなくても修正されることをユーザーに示します。
免責事項：ユーザーから報告されたバグの優先度が高いシェナンガンの経験はまだありません。質問がこれを要求することは知っていますが、それは部外者の視点を持つのに役立つかもしれません。
問題は、優先度の高いバグが多すぎるということではありません。あなたの問題は、バグの優先順位を直接制御できる人が多すぎるということです。すべてのユーザーがバグに直接優先度を割り当てることができる場合、ほとんどの場合、問題は高優先度として自動的に報告されます。
バグの優先度をマネージャーまたはヘルプデスクのドローンで設定する必要があるように設定することもできますが、これにより、優先度やソーシャルエンジニアリングにつながる可能性があります。それらをより重要に思わせる。また、はるかに労働集約的です。
ユーザーが優先順位をある程度制御できるという中立の立場がありますが、システムを悪用することを難しくします。基本的に、ユーザーはバグを報告するためのテンプレートを使用する必要があります。彼らは最初にカテゴリーを選択します：
- 何かをすると、プログラムが使用できなくなったり、クラッシュしたりします。
- プログラムには、機能に影響を与えるグラフィックの欠陥があります。
- このプログラムでは、できるはずのことをすることができません。
プログラムにより、私ができないはずのことをすることができます。 - 何かをすると、プログラムが間違った結果を出します。
- プログラムは何かをするのに時間がかかりすぎます。
- プログラムには、機能に影響を与えないグラフィカルな欠陥があります。
- プログラムには、上記のカテゴリのいずれにも当てはまらない欠陥があります。
例を挙げると：
- ヘブライ語のシンボルを含むメッセージを受信すると、iPhoneがクラッシュします。
- 私のAndroidロック画面は、画面の半分が画面から落ちるように回転しています。
- 私のAndroid電話は、正しいコードを入力したにもかかわらず、ロック画面コードを受け入れないことがあります。
- PhoneHub.netに移動しようとすると、私の電話が私をアダルトサイトにリダイレクトします。
- Facebookアプリを開くと、高速接続で他のアプリが実行されていなくても、開くのに1分かかります。
- アプリにスペルミスがあります。
- あなたのプログラムにセキュリティの欠陥を発見し、報告したいと思います。
ご覧のとおり、これらのエラーはそれぞれ重大度が異なり、カテゴリはこの重大度に基づいて大まかに並べられています。次に、カテゴリに基づいて各バグに優先度を割り当て、報告者と説明に表示されるキーワードを報告します。カテゴリ7のバグには、手動で優先度を割り当てる必要があります。
これは完全に自動的に行われる可能性があるため、これは自動的に行われるようにする必要があります。実際、自動化はここでの鍵です。ユーザーはビジネスにとって自分自身の重要性を過大評価する傾向があるため、バグを報告する際の問題が本来よりも優先度が高いとは見なされません。故意にバグを別のカテゴリに分類する傾向はあまりありません。これは、基本的にバグについて嘘をつく必要があるためです。
もちろん、ユーザーはバグを間違ったカテゴリに入力する可能性があります。最初にすべきことは、バージョン1.0から、開発者がバグをより迅速に見つけて修正できるようにバグに関する正確な情報を提供するようユーザーに促す親しみやすいメッセージを表示することです。ほとんどのユーザーは、バグの誤解を理解して停止します。一部のユーザーは引き続き間違った情報を提供する可能性があります。その場合は、正確な情報が重要であり、システムを乱用しないでください。彼らがレコードの改ざんを続けている場合は、システムを故意に悪用していることを警告し、悪用を続けるとバグが自動的に低いカテゴリに割り当てられることになります。持続する場合は、バグの乗数を調整できます。
このシステムの一部は、ハイスループットのサポート状況で確認できます。Microsoft、Facebook、Google、ValveやBlizzardなどのユーザーが多いゲーム会社などの巨大なテクノロジー企業、特定の政府など...よくわかりません裏側の仕組みを見ると、ユーザー向けのサポートシステムには、私がここで提案するものと同様のインターフェイスがあり、厳密なカテゴリシステムがあることがわかります。
人々が言ったように、これがバグを報告する人々が優先順位を割り当てることができない理由です。開発チームは、独自のタスク割り当てを管理する必要があります（上位の管理者が設定した範囲内）。したがって、さらに誰かが「thisアプリで作業して、-this機能を修正し、-this "の機能を改善して、チームが経営陣が望んでいることを達成するための最善の方法を評価するために必要な技術的専門知識を備えているため、その方法を決定します。
バグを報告する人は、スコープを定義したimpactまたはseverityレベルを割り当てる必要があります。重要なレベルの重大な証拠があるため、合意されたレベルの重大度に固執しないことで、簡単に人々を呼び出すことができます。例えば：
- 機能の完全な喪失
- 機能の部分的な喪失
- 効果の広範な減少
- 局所的な効果の低下
- 煩わしさや邪魔（回避策あり）
- 化粧品
- 誰も実際には気づかず、あいまいな探索テスト中に発見されました
まず、これらのレベルを鈍器として使用して、一部のタイトルテキストの調整不良がレベル1のバグではないことを指摘できます。これは、アプリケーション全体が使用できなくなるわけではないためです。彼らがアイデアを得たら、あなたはそれをよりきめ細かくすることができ、この1つのテキストボックスを更新する際のグリッチがテキストボックスを数回右クリックして修正できるため、レベル4であるかレベル4であるかを議論し始めることができます。これは、アカウンティングの全員の速度が低下し、1時間あたりに処理されるフォームが少なくなるためです。
測定可能バグの程度に関する情報組織にとってが役立つと、優先度の割り当てが明らかになります。現在、組織に最大の問題を引き起こしているもの-利益の損失、公共イメージへのダメージ、従業員の不幸など-は優先度が高く、そこから下に向かって作業します。
次のようになります。
Mgr：何に取り組んでいますか？開発者：この優先度の低いタスクマネージャ：優先度の高いタスクに取り組んではいけませんか？
クライアント：いつバグが修正されますか？ Dev：優先度の低いタスクです。優先度の高いタスクがあります。クライアント：ああ、それから私のバグステータスを高優先度に設定します。
これにより、優先度のレベルがますます高まります。あなたはすでに高い優先度を超えて非常に高い優先度に進んでいるようです。次は何でしょう：
- 超高優先度
- 超高優先度
- 非常に非常に高い優先度。
- 非常にスーパーウルトラメガハイプライオリティ。
などなど.
はい、これは通常のプロセスです。優先度の割り当てに費用がかからず、発信者が影響力を持っている限り、もちろん問題を最速で解決して最高の優先度を設定しようとします。
これに対処するには、基本的に2つの方法があります。
- 優先度レベルに関してクライアントから制御を奪います。
- プライオリティレベルを上げるためにクライアントにコストを関連付けます。
特に、それがJiraである場合、システムにますます高い優先度レベルを追加できます。新しい高優先順位をますますばかげていますが、悲惨な名前を付けると、すべての関係者が行う優先順位の選択の質が Hawthorneエフェクトバンプ に増える可能性があります。最高の優先順位が本当に風変わりな名前である場合、その影響は永続的なものになる可能性があります。最終的に誰かが優先順位を選択するとき、彼らは「死のバグ」優先順位を選択することに対する社会的影響とそれに対する正当な注意を得ることの比較をしなければなりません。したがって、最高の優先順位は、ゲストの前で自宅のCTOに起こった何か、または同等の可視性の他のインシデントのために事実上予約されています。
リクエストをサポートするためのコストを導入します。特定の期間にX個の高優先度アイテム、Y個の中優先度アイテム、およびZ低優先度のアイテムのみをユーザーに報告させることができます。
もちろん、これはまた、開発チームと管理者が特定の数のこれらが実際に修正されることを保証する必要があることを意味します-すべての高優先度アイテム、ほとんどの中優先度アイテム、および（おそらく）一部の特定の期間内の優先度の低いアイテム。
しかし、これがうまくいくとすれば、経営陣は実際にそれに取り組まなければならないでしょう。さもなければ、全体の練習は時間の無駄です。
結局のところ、特定の状況は、経営陣がサポートの問題に対処するために十分なリソースを割り当てていないという問題の兆候であるように思われます。問題がタイムリーに処理されていれば、私はこれが起こっているとは思いません。
私が最初に働いた会社では、サポートプロセスが機能していなかったためにこのようなことが実装され、すべてが緊急の場合は何も起こらない状況に至りました。私たちのケースでは、社内の状況を制御した後、新しいソフトウェア開発マネージャーが、顧客がサポート契約で支払った金額に応じて、提出できる優先度の高い問題の数にハード制限を課しました。彼らが制限を超えた場合、彼らはより多くの現金をせき立てるか、サポート問題の優先順位を下げました。
言及されたすべてのバグが優先度が高い可能性があります。私は資金不足と仕様不足の両方のプロジェクトに参加してきました。テストが開始されたとき、QAとユーザーは優先度の低い項目の報告をあきらめました。なぜなら、プロジェクトのコア機能がスペルエラーや使いやすさのグリッチは時間の無駄であることを彼らは知っていたからです。完全にホースでつながれた。 自動化された手荷物システムがカートを一緒にクラッシュさせて荷物を破壊している の場合、タグのフォントが2ptが小さすぎるかどうかは誰が気にしますか？
このような状況では、プロジェクトは失敗しています。これが可能性さえあると思われる場合は、欠陥を報告している人々と突き止めるために、心からの心が必要です。人々がバグレポートを膨らませているなら、他の答えが役に立ちます。バグが報告されているほど悪い場合は、 極端なアクションをとる を行う必要があります。
これは、ITが付随的であると見なされたり、外部委託されたりしている大企業で非常に頻繁に発生します。ビジネスの人々はソフトウェアを理解せず、気にしません。彼らが気にするのは、どれほど重要でなくても、「彼らの」バグは昨日修正されるということだけです。他にも100人のユーザーがバグを報告していることに気づいていない、または気にしていない。
これは、貧弱な管理、特に「いいえ」と言えない、または単にビジネスの人々にバグの優先順位を設定させるIT以外の管理者によって悪化します。 （どちらの場合でも、マネージャーは自分の仕事をしていません。）ほとんどのマネージャーは、「緊急である」ため、最後に連絡があったバグを優先します。最終結果は、開発者がバグからバグへとジャンプすることになるため、単一のバグの修正にはより長い時間がかかり（コンテキストの切り替え）、結局のところ、誰もが不幸です。 「すべてのバグが優先度の高いバグである場合、優先度の高いバグはありません。」
私はこの状況にあり、一般的にそれを脱出する唯一の方法は外に出ることです。ユーザーがs ** tを指定しないため、バグ報告ガイドラインは常に無視されます。バグのトリアージを導入しようとすると、抵抗されるか、実装されて、次にユーザーがマネージャーに電話をかけて「自分の」バグについて不平を言うときに無視されます。
基本的に、開発者が優先度を制御できない場合、あなたはすでに負けています。
会社と同様に、最も重要度/コスト比が高い問題を解決したいと考えています。ユーザーが重要性を決定し、エンジニアリングがコストを決定します。ユーザーがすべてのバグに同じ重要度を割り当てた場合、コストのみが問題になります。
実際には、これは優先度を重要度/コストとして定義し、ユーザーまたは開発者がその優先度を直接設定できないようにすることを意味します。どちらの側にも全体像はありません。
ユーザーがすべての問題を同等に重要視することを決定した場合、それは問題ありません-しかし、エンジニアリング（コスト）が何を行うかを決定することを意味します。重要性は、優先度に影響を与えることができる（ただし決定できない）唯一の方法であることを説明します。
いくつかの要因...
- 多くの場合、バグを報告した人は全体像を把握しておらず、バグの重要性を判断できません。
- 多くの場合、優先度の低いバグはトリアージされたり考慮されたりしないため、高すぎる優先度を与えて、トリアージを行っている人にそれを下げさせる方が良いです。
- 開発者として、私はバグレポートをよく見て、バグの背後に非常に優先度の高い問題があることを発見しましたが、トリアージを行っている製品マネージャーはバグを気にしません。
したがって、1人から2人の経験豊富な開発者がすべてのバグレポートをすばやく確認し、バグレポートに自分の考えを追加してから、バグを選別する必要があると思います。バグを見つけた人が、見つけた時点で有用な優先順位を設定できると期待することは、あまりにも多くのことを求めているだけです。
ほとんどはすでに述べられていますが、私は「バグ動物園」リストを少し細かいものまで蒸留します。
A：このバグにより、ユーザーはトラックで死んでしまい、誤った出力が出され、一般にシステム/機能/機能が使用できなくなります。これは「優先度の高い」バグです。
B：その他すべてこれらは「交渉可能な」バグです。
交渉可能なバグは、さまざまな懸念事項に分類されます（独自の順序で並べます）。
1：セキュリティに影響を与えるバグ。
2：使いやすさに影響するバグ（意図した目的への適合性）。
3：美学に影響を与えるバグ。
4：パフォーマンスに影響を与えるバグ（おそらくユーザビリティのサブセット？）。
5：プロのプログラマーとしてのあなたの感性を害するバグ。
6：ユーザーの信頼を損なうバグ。
つまり、それは私たちの誰もが実際に住んでいないユートピアの世界です。sighOPの述べられた質問に対する私の答えを完了するには、ソフトウェア業界全体で、開発作業がすべてのバグが優先度1のスーパーバンガースペシャルであるという状態になることはまったく一般的です。そして、あなたは彼らが「特別な」について言っていることを知っています：誰もが特別なとき、nobodyは特別です。
基本的に、この問題は、優先順位を分散させる問題に根ざしています。チームのワークロードに優先順位を付ける能力を持つ人は常に奇数である必要があり、3人は多すぎます。つまり、1人が効果的にトリアージを行う責任があります。そして、それはマネージャーのリード/アーキテクトと相談して、マネージャー/アナリストでなければなりません。また、プロセスは非常にシンプルで、機能のリクエストにも適用できます。開発にかかる費用はいくらですか？ビジネスに期待される結果の価値は何ですか。その関数の出力は、割り当てられた優先順位です。
もちろん、すべてのユーザーが最初に問題を修正することを望んでいます。そして、あなたがそれを許可するとすぐに、カオス。有効な優先順位がありません。これは、すべての問題とビジネスニーズに対して可視性があり、必要なビジネスとITの専門家のアドバイスを収集し、それによりメトリックの合理的に正確な見積もりを生成できる十分な能力を持つ1人の担当者（必要に応じて他の人と相談する）が行う必要があります。上記。
言うまでもなく、デフォルトとしてバグを高い優先度に設定している（またはこの設定に設定されている）バグ追跡ソフトウェアはないと想定します。
申し訳ありませんが、コントロールがない場合、これは複数のチーム、クライアントなどが報告する場合のデフォルトのシナリオです。現状が悪用されている場合は、何らかのトリアージプロセスが確実に適切です。
私が過去に非常にうまく機能しているのを見てきた素早い勝利は、P1（優先度の高いバグ）が大量の管理アラートを生成することです。システムが悪用された場合は、すぐに停止されます。または、本当に緊急の場合は、電話会議または物理的な会議で問題にできるだけ早く対処します。
allバグについては、最初の開発からのものだけではなく、ここで話をしていると仮定します。通常、グリーンフィールド開発を雇うのであれば、最初のアルファリリース以降、ほとんどのバグが優先度の高いものであることは珍しくありません。
優先順位を付けて、すべてが魔法のように機能することを期待することはできません。時々、人は自分でそれを理解しますが、常にではありません。
優先順位を正しく割り当てるには、各優先順位の構成要素を正確に定義する必要があります。これらの基準は客観的でなければならず、バグの優先と政治的な優先順位付けを回避します。客観的な基準が守られていない場合は、チームにそれを遵守させる必要があります。
これを回避する方法は本当にありません-どのバグがどこに行くのかについての客観的な基準があり得ない場合、そして人々がこれらの基準を尊重することを意図的に拒否する場合は、提出者が割り当てた優先順位がないかもしれません-優先順位なしで行うか、または他の人が示唆するように、サードパーティが優先順位を割り当てます。クラウドソーシングされたデータは、送信者が協力的である場合にのみ機能し、データ収集を積極的に妨害しません。
客観的な基準を作成できないために困難が生じる場合は、相対基準を使用できます。
- すべてのバグの簡単なキューを用意します。ユーザーはキューのどこにでもバグを挿入できます。バグはその下のすべてよりも重要であると感じた場合にのみ、特定の位置に挿入する必要があります。バグ修正はキューの先頭から始まります。
- すでに明確に分類された一連のバグがあると仮定して、優先度
Xにバグを配置するための条件は、優先度X-1のすべてのバグよりも重要である必要があることを全員に伝えます。 - 優先度
Xのバグの数が優先度X-1のバグの数を超えることは決してできないことを提出者に伝えてください。
しかし、あなたの問題は定義ではないようですが、低優先度のバグは修正されないという提出者の間の信念。 （おそらくあなたの言うことから）彼らの信念は実際には根拠があるので、おそらく、そうでなければ彼らを説得することはできません。では、なぜこれらのバグを提出させるのですか？忙しい仕事になってしまいます。たとえば、アクティブなバグが一定数に達した後、most未解決のバグよりも重要なものを見つけたと感じない限り、レポートを作成しないように全員に指示できます。確かに、これはキューの長さの上限を持つ単なるキューソリューションです。