バグの修正にわずかな利点がありますか[終了]

以前の同僚から、すべてのバグを修正する必要があるわけではないと聞いたことがあります。バグの優先リストを下るにつれて、そのバグを引き起こすユースケースが不明瞭になったり、顧客満足度が低下したりするためです。ただし、そのバグの修正にはかなりの時間を費やす必要があります。

このコンセプトについて製品の所有者を説得しようとして、良いリソースが見つかりませんでした。私が見つけられたのは、ソフトウェア開発に限界費用があるかどうかの議論だけでした。

バグを修正することで実際にわずかな利点がありますか？この概念を説明する別の用語はありますか？

ビジネスの観点から見ると、バグ修正は機能のリクエストと同じです。開発時間に一定のコストがかかり、顧客にとって一定の価値があります。バグが重大ではない場合、バグ修正よりも価値のある機能を優先することは、ビジネス上理にかなっています。

しかし、技術的な観点からは、他のコードが使用/構築する可能性のある基盤のエラーを示すため、バグはより重要になる可能性があります。そうでないバグを修正している技術的負債ながら、管理を必要としない機能を実装することは、本当に継続的なコストを持っていません。しかし、バグが被る技術的負債のレベルは、バグの性質に大きく依存します。

優先順位を付ける際には、これらすべての要因を考慮に入れる必要があります。

バグを修正することにわずかな利点があるかどうかに関して：これは当然です。すべてのバグの重大度が同じではないため、最も重要なバグを最初に優先順位付けします。したがって、修正するバグが多いほど、次の修正の限界値は低くなります。しかし、バグを修正するレベルに達したかどうかは努力する価値はなく、技術的な決定ではなくビジネス上の決定です。

ここに良い参考文献があります

http://www.joelonsoftware.com/articles/fog0000000043.html

新しいコードを書く前にバグを修正しますか？Microsoft Word for Windowsの最初のバージョンは、「死の行進」プロジェクトと見なされていました。[...]バグ修正フェーズは正式なスケジュールの一部ではなかったため[...]

マイクロソフトは普遍的に何かを採用しました[...]最優先事項は、新しいコードを書く前にバグを排除することです[...]一般に、バグを修正するまでの待ち時間が長いほど、時間と費用のかかる修正に時間がかかります。

これらのバグがここに長くあるほど、それらが優先事項になってから修正するのに時間がかかると確信できます。そのため、今すぐ生の利益を得る代わりに、将来的にはより高価な損失を回避しています。

これを管理する良い方法は、バックログの問題を処理するために割り当てる時間を定義することです。これは、Microsoftのようにマッシュアップすることはありませんが、クライアントが実際に気にしなくても、まだあなたの問題ではない場合、将来の問題を解決するための量を確保します。

このコンセプトについて製品の所有者を説得しようとして、良いリソースが見つかりませんでした。

あなたが営利団体で働いていると仮定すると、きっと費用便益分析を知っている誰かがそこにいるでしょう。

組織には、有限量の開発者リソースがあり、有益なことの無限のリストがあります。これらの有益なことには、新しい機能の追加と既存のバグの削除の両方が含まれます。バグを削除すると、新しい機能の追加と同様にソフトウェアが改善されます。

したがって、この無限リストに対してこの有限リソースをどのように割り当てるかについて決定する必要があることは明らかであり、その結果、一部のバグが現在、または来週、来年、または年内に修正されないことは特に驚くことではありません事実。

ここでより構造化されたアプローチを探している場合は、バグのユーザービューとプログラマビューに番号を割り当てるPEF / REVシステムを試してみてください。修正するものとしないものを決定するための出発点として。

ソフトウェアエンジニアリングに関する次の2つの投稿も参照してください。

どのバグが最大のコストメリットをもたらすかを解決する

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

ソフトウェアの動作の意図しないまたは望ましくない側面がすべてバグではありません。重要なのは、ソフトウェアが有用な方法で動作するために信頼できる有用で文書化された条件の範囲を持っていることを保証することです。たとえば、2つの数値を受け入れ、それらを乗算して結果を出力し、結果が9.95以上10.00未満、99.95以上100.00未満などの場合に偽の数値を出力することになっているプログラムを考えます。 。製品が3から7の間の数を処理するためにプログラムが書かれていて、他の処理を要求されない場合、9.95でその動作を修正しても、意図した目的に役立つことはありません。ただし、プログラムが他の目的により適したものになる可能性があります。

上記のような状況では、2つの適切なアクションコースがあります。

1. 問題を修正します（実用的な場合）。

2. プログラムの出力が信頼できる範囲を指定し、プログラムが有効な範囲内の値を生成することがわかっているデータでの使用にのみ適していることを示します。

アプローチ＃1はバグを排除します。アプローチ＃2は、他の方法よりも目的によって進行が適切でない場合がありますが、プログラムが問題ではない可能性のある問題のある値を処理する必要がない場合。

値99.95から100.0を正しく処理できないことがプログラミングの誤り[たとえば、小数点の左側に2桁を出力してから1桁に丸めてから00.00を出力することを決定]の結果である場合でも、そのような場合にプログラムが意味のある出力を生成するように指定されていない場合のバグ。[ちなみに、前述の問題はTurbo C 2.00 printfコードで発生しました。その文脈では、それは明らかにバグですが、障害のあるprintfを呼び出すコードは、問題のある範囲で出力を生成する可能性がある場合にのみバグがあります。

大まかに言うと、はい、すべてのバグを修正する必要はありません。リスクと利益の比率を分析することがすべてです。

一般的に起こるのは、ビジネスが技術リードや利害関係者とのミーティングを持ち、明らかに「修正が必要」な山に含まれていないバグについて話し合うことです。彼らは、バグの修正に費やした時間（=お金）がビジネスにとって価値があるかどうかを決定します。

たとえば、「マイナーバグ」は、Webサイトの利用規約セクションでのわずかなスペル/文法エラーである可能性があります。これを提起した個人は、それを変更するにはあまりにも小さいと思うかもしれませんが、ビジネスはそれがブランドに引き起こす可能性のある潜在的な損害、および少数のキャラクターを修正する相対的な容易さを認識するでしょう。

一方、重要と思われるバグもありますが、修正は難しく、ごくわずかなユーザーにしか影響しません。たとえば、Google Chromeのレガシーバージョンを使用しているユーザーのマイナーボタンリンクが壊れており、Javascriptが無効になっていることもあります。

ビジネスがバグを修正しない他の理由は、投資した時間がプロジェクトを予想外の時間に戻すこと、または開発者の時間を他の修正/コーディングに費やす方が良いことです。また、バグが十分にマイナーであるために、ライブになり、後日修正される可能性もあります。

コンセプトが少し良くなることを願っています！私は確かに一般的な用語でこれについて考えることから遠ざかります-すべてのバグはユニークであり、そのように扱われるべきです。

バグの優先リストに進むと、そのバグを引き起こすユースケースが不明瞭になるか、得られる顧客満足度が低くなるためです。

彼らの「引数」は実際には

バグを十分に長く無視すると、ユーザーは問題が何であったかを忘れるか、それを回避する方法を見つけます。

バグは、新しい機能要求と同じように優先順位を付けて「順序どおり」に処理する必要があります（ただし、おそらく、後者のすべてに加えて）。