元の開発と比較して、バグにはどのくらいの時間を費やす必要がありますか？
この質問は少し抽象的ですが、誰かが私を正しい方向に向けてくれることを願っています。
私の質問は、元の開発時間に関連して、ソフトウェアプロジェクトのバグにどれだけの時間を費やすことができるかということです。決定的な要素が膨大にあることに気づきましたが、典型的または平均的な内訳を望んでいました。
たとえば、プロジェクトAが完了するまでに40時間かかり、さらに10個のバグを修正する場合、このプロジェクトの比率は4：1になります。
別のプロジェクト（B）が完了するまでに10時間かかりますが、バグに関してさらに8時間かかる場合、比率は5：4になります。
これは文書化/調査された概念ですか？
更新
すべての有益な答えをありがとう。関連するすべての変数と環境要因により、この種のメトリックに基準を設定することは不可能であることを理解しています。回答を割り当てる前に、このメトリックに同意済みの名前があるかどうかを知りたいので、さらに調査を進めます。自分でメトリックを生成するために必要な測定を理解し、最終的にプロジェクトのベースライン標準を思い付くことができるようになりたいと思います。
欠陥修正に割り当てられた総容量の平衡パーセンテージは、欠陥注入率に等しくなります。
もちろん、多くの要因がこの比率に影響を与える可能性があります。もちろん、チームが開発している製品の種類、使用しているテクノロジーと技術、チームのスキルレベル、企業文化などです。
チームBを考えると、完了した作業10ユニットごとに平均8ユニットのリワークを作成する場合、それらの8ユニットを使用すると、新しい6.4ユニットのリワークが作成されます。彼らが最終的に費やさなければならない総努力を幾何学的な進行の合計として見積もることができます：
10 + 8 + 6.4 + 5.12 + ...
バグの数は時間とともに指数関数的に減少しますが、チームBの指数には非常にゆっくりとゼロになる係数が含まれています。実際、上記のシリーズの最初の3つの項の合計は24.4のみです。最初の5つのうち33.6;最初の10、45の;シリーズ全体の50。つまり、チームBの要約：欠陥の注入率は0.8。機能開発、10/50 = 20％;欠陥修正、80％。 20/80は、持続可能な容量割り当てです。
対照的に、チームAの方がはるかに良い状態です。彼らの進行は次のようになります：
40 + 10 + 2.5 + 0.625 + ...
このシリーズの合計は53 1/3なので、チームAの機能開発割り当ては40 /（53 1/3）= 75％であり、欠陥修正割り当ては25％です。これは、欠陥注入率10/40 = 0.25と一致します。 。
実際、最初の3つの後のチームAのシリーズの用語はすべて無視できるほど小さくなっています。これが実際に意味することは、チームAはおそらく2回のメンテナンスリリースですべてのバグを潰すことができるということです。これはまた、anyチームがそれを実行できるという幻想を生み出します。しかし、チームBではありません。
David Andersonの新しい本「Kanban」 を読んでいるときに、この同等性について考えました。 （この本は別のテーマですが、品質の問題にも対処しています。）アンダーソンはソフトウェアの品質について議論するときに、Capers Jonesによる この本を引用し、「ソフトウェアの評価、ベンチマーク、およびベストプラクティス」と述べています。 ：
「... 2000年に...北米チームのソフトウェア品質を測定したところ、機能ポイントあたり6個の欠陥から100個の関数ポイントあたり3個未満の範囲で、範囲は200〜1でした中間点は、0.6〜1.0機能点あたり約1つの欠陥です。これは、チームが欠陥の修正に90％以上費やすことが一般的であることを意味します。 "彼は提供された例を引用しますバグの修正に90％の時間を費やしている会社の同僚の1人。
アンダーソンが欠陥注入率から欠陥修正能力の割り当てに至るまでの流暢さ（失敗需要はその用語です）は、2つのことの同等性はよく知られていることを示唆していますソフトウェア品質の研究者にとって、おそらく以前から知られていました。
ここで提示しようとしている推論のキーワードは、「均衡」と「持続可能な」です。持続可能性を排除する場合、これらの数値をだますための明白な方法があります。最初のコーディングを行ってから、どこか別のコーディングに移り、メンテナンスは他の人に任せます。または、技術的負債を使い果たして、新しい所有者に荷を下します。
明らかに、特定の割り当てがすべてのチームに合うことはありません。 20％をバグに費やす必要があると私たちが定めた場合、チームの欠陥注入率が非常に低いと、時間を埋めるのに十分なバグがチームになく、チームの率が非常に高いと、バグが発生します。蓄積していきます。
ここで使用した数学はかなり単純化されています。パーセンテージに多少影響するトランザクションコスト（計画および見積もりのミーティング、事後分析など）などは無視しました。また、ある製品の持続と別の製品の同時開発をシミュレートする方程式も省略しました。しかし、結論はまだ残っています。ユニットテスト、継続的インテグレーション、コードレビューなどの技術的実践の観点からできる限りのことを行って、欠陥の注入率を減らし、結果として障害の需要を減らします。 10個の機能ごとに1つのバグしか作成できない場合は、新しい機能を開発して顧客を満足させるための多くの時間があります。
残念ながら、この比率は特定のプロジェクトでは非常に変動しやすいと思います。環境、言語、ツール、チームの規模、経験に大きく影響されます。
修正から得られるものが投資よりも大きい場合にのみ、バグに時間を費やす必要があります。
次のようなマトリックスを使用します（水平-バグの修正に必要な時間、垂直-バグの種類-ユーザーへの影響）
| Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix | Fix
問題の例：
| Few hours | Many hours
--------------+--------------------------------------+---------------------------------
| Window moves 1px every 10 | Windows is painted incorrectly
Minor problem | times when you open the application. | every 100th time the app is open.
| Fix is: handle window resize event | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening | Poor performance when >100 users
| SQL connection. | are connected (unusable app)
| Fix: Fix invalid query + add Nice | Fix: change architecture + DB
| message |
マトリックスは、さまざまなレベルの重大度、労力、リスクなどにより、より複雑になる可能性があります
バグごとにランクを作成し、ランクに基づいて修正することもできます。何かのようなもの：
Bug priority = Risk x Severity x Effort
*選択するスケールによっては、一部のオペランドでは（1-x）になる場合があります:)
だから、あなたの質問に答える：バグの種類、利用可能な時間/予算などに依存します。
あなたのコードは完璧なので、本当に正しい答えはバグ修正のゼロ時間です。 :-)
現実的には、誰かがそのような比率を要求したり提供したりするのを聞いたことがあるとは言えません。一部の企業が開発とメンテナンスの両方の時間を追跡していないと言っているのではありません。しかし、アプリケーションの開発は、ほとんどの企業が戻ってその比率を計算しないメンテナンスと比較すると、非常に短い期間です。彼らはおそらくアプリがメンテナンスを必要とする理由を学び、それらの発見を新しいアプリケーションに適用することについてもっと心配しています。
これは、（もちろん）チームの経験と品質、プロジェクトの難易度（新しいOSカーネル以外の標準のWebアプリケーションを作成するのと同じではない）だけでなく、管理アプローチにも大きく変動します。使用します。
たとえば、ウォーターフォールモデルでは、最初のテストフェーズで最初のバグを正確に設定できますが、アジャイル環境では、「これからは、バグを修正しています」と言って、機能が変更される可能性があるため、（私にとっては、機能の変更をバグとしてカウントするのは公平ではありません）
経験上、これは常に過小評価されていることであり、「元のプロジェクト」と同じ時間を非常に簡単に費やすことができると私は言います。
バグとは何かの基準が広すぎると、時間はほぼ2倍になります。クライアントのボタンを大きくする要求（マウスの問題がある）を考える熱狂的なマネージャーは、修正したバグの数を増やすのに最適な方法です。パッチの検討、テスト、再コンパイル、および配布の必要がないため、修正には数秒しかかかりません。ああ、それは新機能として二重にカウントされます。
重要でないソフトウェア、1：1の比率は珍しいことではありません。単体テストのみの場合、インジケーターがコードの10行ごとに1日の単体テストに言及しているのを見ました。
私はあなたが正しいと思います-影響を与える要因の数が非常に多いため、意味のあるメトリックを取得することはできません。
それが役立つ場合は、私が取り組んでいるプロジェクト（エンタープライズスペース、大規模で複雑なシステム、他のシステムへの多くの統合）の比率が約3：2であることを伝えることができます。これらのほとんどは、コードの障害ではありません-通常、インターフェイスの障害です。たとえば、システムAとBはインターフェースXを介して相互に通信します。システムAの開発者はインターフェースXをシステムBの開発者とは少し異なる方法で解釈します。
注目すべき1つの観察は、コードの開発とコードのテスト/バグ修正は2つの異なるフェーズであってはならないということです。開発時にテストする場合、バグ修正の「コスト」は少なくなります。
この質問は偏っています：バグの修正は新しい機能の開発と同様のフェーズであるという前提から始まります。これはそうではありません。
優れた開発者は、最初からコードにバグがないため、コードのデバッグに多くの時間を費やしません。悪い開発者は、実際の問題を解決するための適切な抽象化を作成できないため、コードのデバッグに多くの時間を費やします。
開発者は自分でコードを単体テストする必要があることに注意してください。バグのないコードを提供するのは彼らの仕事です。したがって、コーディングとデバッグを分離するのは困難です。
それも優先事項です。開発中、バグを修正するのに必要な時間は、コードにバグを挿入した瞬間から経過した時間に指数関数的に関連しています。したがって、バグを修正することは、新しい機能を開発することよりも優先されるべきです。
したがって、「バグに費やされた時間」ではなく、「テストに費やされた時間」（統合テスト、ユーザー受け入れテストなど）について話す必要があります。
これを決定する最大の要因は、新しいテクノロジーで作業しているか、既存のテクノロジーで作業しているかです。何か新しいことに取り組んでいて、まだ行われていないか、さまざまな状況で数回行われた何かを開発している場合、バグ修正に多くの時間を費やし、プロジェクトを思い通りに機能させることになります。多くの場合、バグは自分が片隅まで作業した結果であり、行った作業を再構築するにはかなりの量の作業を行う必要があります。さらに、多くのバグは、ユーザーの期待を十分に理解していないことと、開発者がEdgeケースを認識していないことに起因します。
確立されたテクノロジーに取り組んでいる場合、ほとんどの問題はライブラリーまたはコミュニティーのプラクティスによって対処されているので、発生したバグをグーグル、購入、または回避することができるはずです。
私は純粋に実用的な見方をしています。プロジェクトの実用性をさらに妨げているものは何ですか？既存の機能のバグの場合は、バグを修正する必要があります。不足している機能がある場合は、独自の開発を行い、最も深刻な不足している機能が実装されたら、戻ってバグを修正する必要があります。これには、ユースケースについての知識が必要です。奇妙なコーナーケースでプログラムをクラッシュさせるバグは、すべてのユーザーに影響するユーザビリティのマイナーな拡張機能よりも優先度が低い場合があります。最も一般的に使用される機能の小さな厄介なバグは、ソフトウェアを極端に押し進めている人にのみメリットをもたらす機能よりも重要な場合があります。