バグは技術的負債の一部ですか？

スクラムマスターは、バグを技術的負債と呼んでいます。彼は正しい、バグはアジャイルの世界で技術的な負債と考えられていますか？

ここでの答えはかなり簡単だと思います-技術的負債の重要な特徴は、私たちが選択によって被る何かです。

特定の目標をより早く達成するために、後で問題が発生すると予想されるアーキテクチャ、設計、または実装の決定を行うことを選択します。

バグは、コードに含めることを選択したものではないため、事実上、技術的な負債ではありません。

もちろん、発見後に行われた選択に関するあらゆる種類の興味深い（そしておそらく有効な）議論をすることができますが、基本的に（そして特に質問の文脈では）いいえ、バグは技術的な負債ではありません-私にとって流行語ビンゴの乱用のように聞こえます。

追記として-技術的負債がそれ自体でバグにつながるという主張は、選択の性質に関する多くの仮定に大きく及んでいるという主張には同意しません。たとえば、十分に記述され、適切に構造化された、テストでカバーされたコードを使用して、早期配信のためのアーキテクチャ上の妥協を実現できます。同様に、バグにつながることはありませんが、おそらく多くのストレスと痛みにつながる展開プロセスを自動化しないことを選択できます。もちろん、SOLID（または何でも）ではないコードを書いたことが負債である場合は、そうです...しかし、それは常にそうではありません。

はい。

技術的負債（設計負債またはコード負債とも呼ばれます）は、コードベース内でのソフトウェアアーキテクチャとソフトウェア開発の貧弱または進化の最終的な結果を指す、ネオロジカルなメタファーです。

出典：ウィキペディア

より良いワークフロー（たとえば、コーディングにジャンプする前に適切にアーキテクチャを実行する、TDDを実行するなど）、より良いコーディングの実践などによって、技術的な負債を回避できるものとして読んでください。

追加のレビューまたはより正式な方法の使用により、ほとんどのバグを回避できた可能性があります。そもそもバグがないようにするためにできることをすべて行わないことで、プロジェクトの即時/短期コストを削減しますが、技術的な負債を増やします。

BЈовићの回答を読んだ後、思ったほど簡単ではないかもしれないことがわかりました。

• たとえば、バグは技術的負債の一部ですか？記事では、知っているが修正しないことに決めたバグのみが技術的負債の一部であると主張しています。

• 別の例として、技術的負債に関するクリストファーの思考は、技術的負債の結果としてバグを認定しますが、その一部ではありません。とはいえ、「新しい機能を実装するためのコスト」など、リストされている結果の多くは、バグの数に影響されます。

• 最後に、技術的負債のABCDE-Tモデルを作成するときに、6つの要因の1つとしてバグを含めましたが、それらは異なる方法で考慮されます。バグ自体ではなく、バグの収集、優先順位付け、および解決方法に焦点が当てられています。バグ自体は（前の例のように）技術的負債の結果として現れますが、技術的負債の要因として現れることはありません。

これは言われていますが、私はまだバグ-あらゆるバグ-は技術的負債の一部であると答えたいと思っています。

最初の引数：

ジェフアトウッドの引用を読むと、ほとんどのバグは次のように分類されます。

迅速で汚れたデザインの選択のために、将来の開発で行わなければならない余分な努力

ビジネスアプリケーションでは、ほとんどすべてのバグは、迅速で汚れた設計の選択または悪い慣行（テストの不足、開発者が十分に知らないテクノロジーの使用、コミュニケーションの欠如、ドメインの理解の欠如、など）これは、「迅速で汚いデザインをより良いデザインにリファクタリングすることにより」、そしてより良いプラクティスを適応させることにより、ビジネスのほとんどのバグを解決できることを意味します。

2番目の引数：

会社を別の会社に売却する際に考慮することが重要な会社の通常の債務と、プロジェクトを別の会社に売却する場合やプロジェクトを売却する場合に考慮することが重要な技術的債務とを並行する場合別のチームにとって、バグは技術的な負債の一部であることが簡単にわかります。なぜなら、新しいチームは以下を行うからです。

• 新しい機能を作成する前にそれらのバグに対処する必要があります（Joel Testのポイント5：新しいコードを書く前にバグを修正しますか？）

• または、この方法で技術的負債を維持/増加させ、バグを保持します。

Jeff Atwoodの記事「Paying Down Your Technical Debt」で、技術的負債とは何かについて非常に良い答えが得られます。

技術的負債は利子の支払いを招きます。これは、迅速で汚れた設計の選択のために、将来の開発で行わなければならない余分な努力の形でもたらされます。利息の支払いを続けるか、迅速で汚れたデザインをより良いデザインにリファクタリングすることで元本を返済するかを選択できます。元本の返済には費用がかかりますが、将来的には利息の支払いを減らすことで利益を得ます。

厳密に言えば、バグはそれ以上のソフトウェア開発（物事の変更、新機能の追加など）を遅くしない限り、技術的な負債の一部ではありません。ソフトウェアの欠陥です。

ただし、バグを修正するのに費用がかかりすぎる場合、またはバグを回避する必要がある場合（さらに技術的な負債が発生する場合）は、技術的な負債の一部になります。

バグは技術的な負債ではありません。技術的負債は、品質の欠如ではなく、品質を犠牲にしている。そもそもソフトウェアにバグがある状態で提供されるべきではありません。ご存知のように、機能するソフトウェア全体が包括的なドキュメンテーションに関するものです。

技術的負債の最大の犯罪者は「一時的なバグ修正」であり、テストに合格してストーリーを受け入れさせるために投入したものを知っています。自分が約束したものは後でリファクタリングします。これらの一時的な修正、パッチなどが蓄積されると、コードは不要になり、更新やテストが難しくなり、一般に悪夢になりますが、それでも仕事はします。

この意見を支持するために、私は情報源であるウォード・カニンガムに直行しました。これに関して、ウォードはしばらく前にケイパーズ・ジョーンズとの良いインタビューをしました、それは一見の価値があります。

ウォードカニンガム＆ケイパーズジョーンズとのテクニカルデットディベート

読む価値のある別の記事は、Martin Fowlerによるものです

技術的負債に関するマーティン・ファウラー

Martinの記事内で、OOPSLA92のWard Cunninghamによる技術的負債の元の言及へのリンクを見つけてください。

WyCashポートフォリオ管理システム

上記の記事からの引用：

未熟なコードは罰金を仕事と顧客に完全に許容可能で、過剰量は、プログラマの極端な分業し、最終的に柔軟性のない製品につながる、プログラムがunmasterableようになります。初回コードの出荷は、借金をするようなものです。

結局、技術債務には一部の人々のためのバグが含まれるようになったかもしれませんが、それで問題ないでしょう。それが当初の意図ではなかったと思う。

厳密に言えば、あなたの質問に対する答えはいいえです。

技術的負債はバグにつながる可能性があります（おそらくそうなります）が、バグは技術的負債の結果であると結論付けていることは、2つの事実の間に解釈を置いています：バグがあり、技術的負債があります（事実として結論付けることができると仮定）。

スクラムマスターがバグが技術的負債の結果であると「理論として」述べている場合、彼はコーナーをカットしています。彼が再出現し続ける特定のバグについてこれを言っている場合、彼は正しいかもしれません-ここからコード品質を見ることができません;-)

彼はまた、技術的負債について彼の話を聞いていない人々について継続的な苦情を持っているかもしれません。

私の意見では、バグが技術的負債の一部であると言っても、実際に問題ではありません。

明白な事実は、既存のバグは、修正または回避するために、将来実行する必要がある追加の作業を表しているということです。

技術的負債（通常、ラベルが使用される）は、将来的に実行する必要のある余分な作業も表します...何らかの形で。

したがって、既知の（または未知の）バグが技術的負債であるかどうかは、定義の問題です。また、「技術的負債」の正式な定義¹がないため、議論全体は無意味です。

ルイス・キャロルが書いたように：

「私が言葉を使うとき、ハンプティ・ダンプティは、むしろ軽tone的な口調で、「それは私がそれを意味するために選んだことを意味します-多かれ少なかれ」と言いました。。

それが実際に自然言語が機能する方法です。言葉は、人々が彼らが意味すると思うことを意味します。辞書の定義などは単に単語の使用方法を文書化しているだけであり、必ずしも正確な文書ではありません。スクラムマスターが既知のバグを技術的負債と呼びたい場合、誰が「間違っている」と言うのでしょうか。

^{1-Ward CumminghamやCaper Jonesなどの人々を引用することも助けにはなりません。せいぜい、フレーズを使用する（使用する）ときの意味（または意味）を示しているだけです。彼らはフレーズを「所有」しません。彼らは間違いなくこれらの問題の権威ですが、これはまだ彼らの意見です。}