まず第一に-あなたはあなたの登録簿を非常に単純に保ちたいです、さもなければ登録簿を維持するオーバーヘッドは人々がそれを使うのを止めそしてそれが解決することを意図した技術的負債を実際に修正するより多くの時間を浪費します.....
それでも先に進むことにした場合は、フラットファイル/単純なデータベース/次のフィールドを持つGoogleスプレッドシートである単純なレジスタを保持することをお勧めします。
- モジュール/コンポーネント名
- 修正が必要なものの説明(カテゴリのリストがあるかもしれませんが、これにもテキストのワンライナーが必要だと思います)
- 推定修正時間(日数)(整数の日数を主張する傾向があります。そうしないと、人々は些細なことを記録し始める傾向があります)
- どの開発者が債務を負ったか(そして修正時間の見積もりを提供したか)
- どのプロジェクトで債務が発生したか(含意によって、どのプロジェクトマネージャーが責任を負うか)
ルールは次のとおりです。
- 開発者は、技術的負債について透明性を保つことが期待されています。プロジェクトのプレッシャーのために開発者が技術的負債を負担する必要がある場合、開発者はこれを推定修正時間とともにログに追加する必要があります。
- プロジェクトマネージャーは、発生した技術的負債について説明責任を負います(つまり、開発者にショートカットを取るように圧力をかけましたか?)。彼らは、総債務の増加に対する堅実なビジネスの正当化を正当化し、それを修正するために何をすべきかを提案することができるはずです。
- 技術的負債が記載されていない場合、コードは最高品質であり、関連するコードレビューに合格することが期待されます。技術的負債が記録された場合、開発者は記録されたものすべてに対して「合格」を取得します(代わりに、レビューは債務ログの正確性と修正のために何をすべきかについてのアイデアを検討するのに役立ちます)。
- 開発者は、修正時間について公正な見積もりを出すことが期待されています。アーキテクチャのリファクタリングに2日かかると言われたとしても、後で修正するために2日が与えられても驚かないでください。
このアプローチは全体的に良いダイナミックを生み出すと思います-開発者は透明性を持ち、技術的負債を解決する方法を考える責任があり、プロジェクトマネージャー/ビジネスリードはトレードオフを行う必要がありますが、負債のコストが彼らの責任を負い、最高の開発者と建築家は、技術的負債を管理しながら、困難なプロジェクトを完了したことに対して称賛を得るでしょう。