技術的負債は、機能または雑用（またはバグ）としてスケジュールする必要がありますか？
Pivotal Trackerボードに技術的な負債に対処するユーザーストーリーをいくつか追加しました。それらを特徴（速度レベルを維持する）または雑用/バグ（速度を下げる）と見なす必要がありますか？どちらか一方を一貫して実行しても、長期的には何の違いもないことは理解していますが、技術的な借金の話を追加するたびに、私は決定を下さなければなりません。
いくつかの考え：
- それらは実際にはバグではなく、何も壊しません
- ユーザーに影響を与えない低レベルの実装であるため、ユーザーは何も要求していませんが、長期的な開発が容易になります
- ユーザーに付加価値を与えるストーリーとして機能を定義した場合、a）ユーザーには直接的なメリットが見られないため、機能は定義しませんが、b）将来の開発/メンテナンスを可能にするため、機能しますありません値を追加しますが、今は違います
実際に作業を行うかどうか、またはいつスケジュールするかを決めるのではなく、プロジェクト管理ツールで技術的負債と呼ぶべきものを何を知っているか、そしてその理由を知りたいだけです。
特徴です。
As a [Developer],
I want to [refactor the whizbang library]
in order to [simplify maintenance and speed execution]
他の機能と同様に定義され、スケジュールされ、追跡されます。
この機能を実装することが（クライアントにとってもあなたにとっても）十分に価値がなく、スケジュールを立てることができない場合、それは別の問題です。
（返済）技術的負債は機能ではありません、なぜならクライアントはそれについて決定を下す資格がないためです。最も重要なのは、クライアントがいつ終了するかを決定できないことです。さらに、クライアントは完全にあなたに依存して利点を説明します。技術的な負債があるかどうかはあなたの判断であり、それをどのように修正し、いつ完了するかはあなた次第です。技術的負債は、ソフトウェアのクライアントの認識ではなく、（将来の）速度に影響を与えます。借金がない場合は、より生産的になります。また、コードの形状を維持するのにもっと時間がかかるはずだったので、これまでに測定してきた速度は間違っています。
私はあなたがこれをあなたのクライアントと通信すべきだと思いますが、それは彼らの支配下にあるものではありません。次のように言うことができます。「これまでにいくつかのショートカットを使用してきましたが、修正する必要があります。これは、次の数回の反復で速度が少し低下することを意味しますが、これは長期的にメンテナンス可能なソフトウェアがあることを確認するためです。
クライアントの機能に関する作業を継続することは、完璧なデザインを見つけるための一種の学術的な演習になるのではなく、クライアントのソフトウェアの改善に焦点を当て続けるのにも役立ちます（これは私が個人的に苦労することです）。
IMHO技術的負債を解消するタスクは、間違いなく機能ではありません。それは「バグ」部門に押し込まれる可能性がありますが、やはりユーザーが観察できる行動の変化をもたらさないため、用語の定義が拡張されます。
私はそれをメンテナンスタスクと呼びます。どの開発プロジェクトでも、開発/テスト環境のセットアップ、テストデータのアセンブル、SCMでのブランチのマージなど、このようなタスクがたくさんあります。これらはユーザーが直接確認することはできませんが、定期的に実行しないと、開発が増加します。長期的にはコストとバグ率。
ただし、それらを個別のタスクとして処理する必要はないかもしれません（それらが巨大である場合、および/または現在新しい機能を実装する必要がない場合を除く）。通常、新しい機能がリファクタリング/ユニットテストの記述などを必要とする場合を識別し、これらを新しい機能の開発の一部として処理する方がよい場合があります。これは、管理者とエンドユーザーの両方に説明する方が簡単な場合があります（あなたが何に時間を費やしているかを知りたい場合）。 pdate：さらに、開発者がリファクタリングの価値にも集中できるようにします。リファクタリングのためにリファクタリングに夢中になるのは簡単なので、特定のリファクタリングがクライアントの観点からもたらす付加価値に焦点を合わせると、IMHOが役立ちます。
それをimprovementと呼びます。
何も壊れていないのでバグではありません。
リファクタリングはクライアントの要求ではないため、機能でもありません。 （動作するためです！）。
ほとんどの追跡システムはデフォルトで課題タイプimprovementをサポートしていますが、そうでない場合でもタイプを変更できる可能性があります。