見積もり金利

技術的負債は非常に便利な概念ですが、どのように測定するかという疑問が生じます。残念ながら、技術的負債は金銭的負債とは異なるため、どの程度負債があるのかを判断することは簡単ではありません（最近では金銭的負債の測定に問題があると思われます）。

検討すべきアイデアが1つあります。チームが成果物を完成させたら、それにかかった時間（実際の労力）と、システムが適切にクリーンアップされていれば完了するのに必要な時間の見積もりを教えてもらいます。2つの差が技術的負債の金利です。（実際に5日間かかったけれども、クリーンなシステムであれば3日で終わるはずだと考えている場合、あなたは2日分の労力を技術的負債の金利として支払いました。）

この手法には確かに深刻な欠陥があります。クリーンなシステムで完了までにかかったであろう時間を示すステートメントは、想像上の状態に基づいた見積もりです。そのため、客観的に作成することは難しいです。この情報を収集するには労力がかかりますが、すぐに手に負えなくなる可能性があります。しかし、結果として、技術的ではないスタッフにもわかる方法で、コードベースの状態の概要を明らかにできる可能性があります。

さらに、元金を支払うかどうかを判断する際の決定にも役立つ可能性があります。一部のチームは、製品のバックログに技術的負債のストーリーを追加することがあります。これらには、削除にかかる時間の見積もりも含まれます。このような技術的負債のストーリーは概算ですが、負債がどれほど蓄積されたかを示すものでもあります。元金の支払いの決定に役立つ情報を得るために、これらの負債ストーリーに概算金利を割り当てることで、もう少し賢くすることができます（私はフリッパーモジュールの状態が悪いせいで、この機能に1日余分に費やしました）。元金と利息の支払いを比較することで、元金を返済するかどうかという判断を行うのに役立つ可能性があります。

最近、このような方法を少し試してみて、役立つと判断した人に会いましたが、これまで何度も出会ったことはありません。確かに実行には欠陥がありますが、数回の反復試行を行う価値はあるかもしれません。

更新:最近の議論で、概算金利を把握する別の方法が浮上しました。回顧（賢明なチームは反復の最後に実施します）中に、システムの各問題領域に対して支払われた金利の見積もりを把握します。この見積もりを最近の完了した仕事に対して実施する方が、今後のストーリーに対する見通しを立てるよりも簡単かもしれません。