バグの修正には限界がありますか
以前の同僚から、すべてのバグを修正する必要があるわけではないという話を聞いたことがあります。バグの優先順位リストを下に行くと、そのバグの原因となるユースケースが不明瞭になるか、得られる顧客満足度が低下するためです。しかし、そのバグを修正するために、かなりの時間を費やす必要があります。
このコンセプトについて製品の所有者を納得させるために、良いリソースを見つけることができませんでした。私が見つけることができたのは、ソフトウェア開発に限界費用があるかどうかについての議論だけでした。
バグを修正することには本当に限界的なメリットがありますか？この概念を説明する別の用語はありますか？
ビジネスの観点からは、バグ修正は機能のリクエストと同じです。開発期間には一定のコストがかかり、顧客にとっては一定の価値があります。バグが致命的でない場合は、バグ修正よりも重要な機能を優先することは、ビジネス上完全に理にかなっています。
しかし、技術的な観点からすると、バグmayは他のコードが使用/構築する可能性があるファンデーションのエラーを示しているため、より重大です。メンテナンス。したがって、notバグの修正は技術的負債であり、管理が必要ですが、not機能の実装には、継続的なコストはかかりません。ただし、バグによって発生する技術的負債のレベルは、バグの性質に大きく依存します。
優先順位を付けるときは、これらすべての要素を考慮する必要があります。
バグを修正することには限界的なメリットがあるかどうかについては、これは当たり前のことです。すべてのバグの重大度が同じではないため、当然ながら、最も重要なバグを最初に優先します。したがって、修正するバグが多いほど、次の修正の限界値は低くなります。しかし、バグを修正するレベルに達するかどうかは、努力する価値はありません。技術的な決定ではなく、ビジネス上の決定です。
これは良い参考文献です
http://www.joelonsoftware.com/articles/fog0000000043.html
新しいコードを書く前にバグを修正しますか？ Microsoft Word for Windowsの最初のバージョンは、「死の行進」プロジェクトと見なされていました。 [...]バグ修正フェーズは正式なスケジュールの一部ではなかったため[...]
Microsoftは普遍的に採用しているもの[...]最優先事項は、新しいコードを書く前にバグを排除することです[...]一般に、バグを修正するまでの待ち時間が長いほど、修正にコストがかかります（時間と費用の面で）。 。
これらのバグが長く続くほど、優先度が高くなってから修正に時間がかかるようになります。そのため、今すぐ生のメリットを得る代わりに、将来のコストのかかる損失を回避できます。
これを管理する良い方法は、バックログの問題を処理するために割り当てられる時間を定義することです。これはMicrosoftのように急いでプッシュすることはありませんが、クライアントが本当に気にかけていなくても、それらがまだあなたの問題ではない場合は、将来の問題を解決するためのかなりの量を確実にします。
このコンセプトについて製品の所有者を納得させるために、良いリソースを見つけることができませんでした。
あなたが商業組織で働いていると仮定すると、確かにそこに費用便益分析を知っている誰かがいるでしょう。
あなたの組織には、限られた量の開発者リソースと、やるべき有益なことの無限のリストがあります。それらの有益なことには、新機能の追加と既存のバグの削除の両方が含まれます-新機能を追加するのと同じように、バグを削除するとソフトウェアが改善されます。
したがって、この無限のリストに対してこの有限のリソースを割り当てる方法について決定が必要であることは明らかです。その結果、一部のバグが現在、来週、または来年、または中に修正されないことは特に驚くことではありません事実。
ここでより構造化されたアプローチを探している場合は、 PEF/REVシステム を試してみて、numbersをユーザーとプログラマーによるバグの見解。何が修正され、何が修正されないかを決定するための開始点として。
ソフトウェアエンジニアリングに関する次の2つの投稿も参照してください。
ソフトウェアの動作の意図しない、または望ましくない側面がすべてバグであるとは限りません。重要なことは、ソフトウェアが有用な方法で動作するために信頼できる、有用で文書化された範囲の条件がソフトウェアにあることを確認することです。たとえば、2つの数値を受け入れ、それらを乗算し、結果を出力し、結果が9.95を超えて10.00未満、99.95を超え100.00未満の場合に偽の数値を出力するプログラムを考えてみます。 。プログラムが3から7までの数値を処理する目的で作成され、他の製品を処理するように要求されない場合、9.95でその動作を修正しても、意図した目的のためにそれをさらに有用にすることはできません。ただし、プログラムが他の目的により適している場合があります。
上記のような状況では、2つの合理的な行動方針があります。
問題を修正します（実用的な場合）。
プログラムの出力が信頼できる範囲を指定し、プログラムが有効な範囲内の値を生成することがわかっているデータでの使用にのみ適していることを述べます。
アプローチ＃1はバグを排除します。アプローチ＃2は、進行状況を一部の目的に適さない場合がありますが、プログラムが問題ではない可能性のある問題のある値を処理する必要がない場合。
値99.95から100.0を正しく処理できないことがプログラミングの間違いの結果である場合でも、たとえば小数点以下2桁を出力してから1桁に丸める前に00.00を出力することを決定した場合、そのような場合にプログラムが意味のある出力を生成するように指定されている場合にのみ、バグと見なす必要があります。 [ちなみに、前述の問題はTurbo C 2.00 printfコードで発生しました。その文脈では、それは明らかにバグですが、問題のあるprintfを呼び出すコードは、問題のある範囲の出力を生成する可能性がある場合にのみバグがあります。
大まかに言えば、はい、すべてのバグを修正する必要があるわけではありません。リスク/利益の比率を分析することがすべてです。
一般的に起こることは、ビジネスが技術的なリードや利害関係者とのミーティングを持ち、明らかに「修正の必要性」の山にないバグについて議論することです。彼らは、バグの修正に費やした時間（=お金）がビジネスにとって価値があるかどうかを判断します。
たとえば、「マイナーなバグ」は、ウェブサイトの利用規約セクションのわずかなスペル/文法エラーである可能性があります。これを提起した個人は、変更するのは小さすぎると思うかもしれませんが、企業はそれがブランドにもたらす可能性のある潜在的な害と、数文字を修正する比較的容易さを認識します。
一方、重要であるように見えても、修正が難しく、ごくわずかなユーザーにのみ影響を与えるバグがある可能性があります。例えば。以前のバージョンのGoogleを使用しているユーザーのマイナーボタンリンクが壊れているChromeまた、JavaScriptが無効になっていることもあります。
ビジネスがバグを修正しないその他の理由としては、投資した時間がプロジェクトを予想外の時間に戻してしまうことや、開発者の時間を他の修正やコーディングに費やしたほうがよいことが考えられます。また、バグがマイナーであり、稼働して、後日修正される可能性もあります。
コンセプトがもう少しよく説明されていることを願っています！私は確かにこれについて一般的な用語で考えることから遠ざけるでしょう-すべてのバグは固有であり、そのように扱われるべきです。