技術的負債の計算: 速度ベースの対。問題ベースの対。品質ベースの測定の説明

金利が157%アップ！

いいえ、私はFRBの最新の決定について話しているのではなく、Fictional Inc.がプラットフォームのバージョン3.0をリリースした後に直面した減速について話している.

彼らにとって幸いなことに、製品のリリースは非常に成功し、収益の伸びが急速に回復し始めていますが、リリースの一環として導入した技術的負債をどのように処理するかを考える必要があります.

新しいリリースの一部として導入された新しい技術的負債は、金利を引き上げ、チームが将来直面する減速を増大させると考えることができます。

(ここでは、技術的負債の概念について十分に理解していることを前提としています。プライマー)

エンジニアリング マネージャーが技術的負債についてこのように話しているのを聞くことはないでしょう。

しかし、なぜですか？

あなたの継続的な影響を測定し、定量化することができます技術的負債は重大ですそれに対処するための実行可能な計画をまとめたい場合。

技術的負債について考えるとき、関心は、現在および将来の開発で失われた時間の量であり、既存のレベルの技術的負債になります。

これは、元本(負債の原因となるコードの書き直し、リファクタリング、または修正のコスト) を返済するための将来の決定について考える際に考慮すべき負債の重要な部分であることを意味します。十分に高いです。

技術的負債の健全なレベルとは?

技術的負債が新しい開発を遅らせることは明らかですが、それ自体は、あらゆる場所で技術的負債を修正する必要があるという意味ではありません。既存のコードを書き直したりリファクタリングしたりすると、かなりのコストがかかる可能性があります。そのため、技術的負債の元本を返済したいのは、利息 (前進を遅らせている金額) が元本を超えた場合のみです。

1 つの明らかな問題がすぐに発生します。元本は一定の時間単位 (修正/書き換えにかかる時間) ですが、利息は時間ごとに失われる時間の割合です。これを説明するには、影響間隔のアイデアを導入する必要があります。これは、技術的負債による将来の減速が書き換えのコストを超えるかどうかを気にする時間です。気になる影響間隔は、会社、典型的な計画プロセス、その段階、またはコードベースのライフサイクルに大きく依存しますが、個人的には通常、影響間隔は 3 か月です。会社としての初期段階では、1 年以上のタイムスケールで何かを見るのは広すぎますが、2 ～ 3 か月よりも短いものは、後で説明するように、技術的負債の影響を大幅に過小評価することになります。

これは、次の場合、技術的負債のレベルに対処する価値がないことを意味します。

たとえば、技術的負債があり、週に 2 時間遅くなることがわかっている小規模なプロジェクトがある場合、その負債をリファクタリングするのに 4 日かかり、3 か月の影響間隔を気にする必要はありません。まだその借金を返済するために時間を費やしてください。

さて、これは実際には健全なレベルの技術的負債のレベルには答えていません。なぜなら、チームの大幅な減速に直面することは健全ではないことに誰もが同意できると思うからです.代わりに、書き換えやリファクタリングに集中する必要があるかどうかを判断する簡単な方法が得られました。この記事の後半で、実際に健全な負債水準とは何かを見ていきます。

技術的負債をどのように測定するか?

テクノロジー負債の利率を決定するには、これまでに行ったさまざまな決定によってどれだけ減速しているかを把握する必要があります。残念ながら、開発の速度がどの程度低下しているかを追跡するための明確な、または簡単な方法はありません。

速度ベースの測定

スローダウンをコードベースのさまざまなセクションに結びつける最も直接的な方法は、プロジェクトのさまざまなセクションで速度がどのように変化するかを調べることです。コードベースのさまざまな領域に目を向けると、さまざまなセクションにまたがるバリエーションの特定を開始できます (たとえば、この分析セクションに触れる開発には、他のセクションの 3 倍の時間がかかります)。時間の経過に伴う領域の変化を見ることで、新しい開発が将来の開発率にどのように影響したか、チームが取り組んでいる関心のレベルを知ることもできます。

例: 4 つの異なる領域に取り組む比較的単純なプロジェクトがある場合、ベロシティが時間の経過とともにどのように変化するかを確認できます (ここでは、ストーリー ポイント/開発者月でベロシティを追跡しています)。

技術的負債の影響の速度ベースの測定

ここから、D は常に、同様に複雑なタスクの他の領域と比べて作業に約 3 倍の時間がかかっていることがわかります。これは、コードベースの他のすべてのセクションの 3 倍の関心があることを意味します。 B は A & C と比較的同等でしたが、4 か月目から突然 2 倍の時間がかかりました。これは、B の以前の金利と比べて金利が 2 倍になった債務をここで導入したことを示唆しています。

強調しておくべきことの 1 つは、コードベース全体の利率について話しているのではなく、個々のコンポーネント/領域の利率について話しているということです。これは、技術的負債の蓄積によってもたらされるスローダウンは、通常は問題ではないためです。コードベースの一部にローカライズされています。

速度ベースの測定に関しては、考慮すべき重要な注意事項がいくつかあります。

• 速度は変動しやすく、新しい (または既存の) バグ、見積もりの不一致、技術的なハードル、または外部プロジェクトの遅延などの技術的負債とは無関係の要因に依存する可能性があります。

• 見積もりにはある程度の固有の不確実性があり、そもそも不正確な測定値になる可能性があります。

• このデータの収集と分析は、手間がかかり、時間がかかる場合があります。

  
  

速度ベースの測定の簡単な代用方法の 1 つは、エンジニアリング チームに、コードベースの各主要領域でプロジェクト/タスクを完了するのにかかる時間を相対的に見積もってもらうことです。十分に理解されている/頻繁に使用される領域の確立されたベースラインに同意し、そのベースラインのパーセンテージまたは倍数として他の領域を全員に推定してもらいます。完全な速度ベースの測定アプローチほど厳密ではありませんが、チームの洞察と直感に基づいて、相対的な技術的負債の関心をすばやく知ることができます.

問題ベースの測定

別のアプローチは、プロジェクト内の技術的負債の特定のインスタンスを特定し、それぞれがどれだけ遅くなるかを見積もることです。この一部は、静的分析ツールなどの自動化ツールを使用して、プロジェクトの可読性、拡張性、または保守性に影響を与える可能性のあるコード品質に関する一般的な問題を見つけることで実行できます。問題の種類ごとに、これらの種類の問題に対処したチームの経験に基づいて、利息コスト (例: 5 分/週または 1%) を割り当てることができます。

ただし、これは問題の原因となっている技術的負債のサブセットのみをキャプチャします。他の問題は、コードベースに合わせて巧妙にカスタマイズされたものであり、チームがコードのその領域に積極的に取り組んでいる間にのみ観察されます。この例では、特定の問題 (コードベースの領域に関連付けられている) と、それが開発を遅らせる推定影響を記録する必要があります。これらの問題を追跡するには、何らかの問題トラッカーを使用することをお勧めします - GitHub や Jira などの問題バックログで、または専用の技術的負債の問題トラッカーを使用する刻み幅.

このアプローチには、次のような欠点があります。

• 特定の問題に関連する時間の見積もりは不正確になる可能性があります
• 一部の問題は、長期間にわたって簡単に検出されない可能性があります

品質ベースの測定

コードベースの全体的な状態を把握し、各領域の将来の開発に影響を与える現在の技術的負債の見積もりを取得するために使用できる、さまざまなコード品質メトリックがあります。 Sourcery では、複雑、ワーキングメモリ、関数またはクラス内を調べる際の重要な指標としてのメソッドの長さ - しかし、保守性インデックス、ドキュメントとテストのカバレッジ、重複率なども見ることができます。

問題ベースのアプローチと同様に、さまざまなスコア (または全体的な品質スコアまたは正常性スコア) の相対的な影響を、技術的負債による進行中および将来の開発の減速に割り当てることができます。調査によると、複雑さと速度などの要素と、コードの品質とバグのリスク、メンテナンスの負荷などの間には強い負の相関関係があることが示されています。

例を見てみましょう。Velocity Based Measurement のセクションで見た単純な 4 つの部分からなるコードベースをもう一度見てみましょう。

このプロジェクトの問題セクションは表で簡単に確認でき (赤で強調表示)、金利の見積もりの計算は比較的簡単です。さまざまなコンポーネントの金利の影響を合計するだけです。

このアプローチには、次のような欠点があります。

• さまざまな品質メトリクスでインタレストの影響の見積もりを定義する必要があります (ベースラインとしていくつかをまとめようとしていますが、かなりコードベースに依存します)。これを行うには、おそらく速度ベースの測定値を見て、それを品質に結び付けたいと思うでしょう。
• 品質指標自体は不完全であり、言語によって大きく異なります.

この品質ベースの測定アプローチは、これまで見てきた 3 つのアプローチの中で最も正確ではありませんが、プロジェクトのさまざまな領域を時間の経過とともに全体的に見るには非常に効果的です。このアプローチを先ほど説明した問題ベースのアプローチと組み合わせて、特定の問題の追跡と、プロジェクトの各セクションでの一般的な品質および正常性の問題の追跡のバランスを取ることができます。

コードベースのインタラクション頻度を見る

これら 3 つのアプローチすべてについて、コードベースのさまざまなセクションでの影響を、コードベースのそのセクションに実際に触れる頻度に対してマッピングする方法が必要です。私たちのプロジェクトに対処するのは悪夢であるが、もはや誰も触れていないセクションがある場合、それは実際には進行中の技術的負債に大きな影響を与えていません.逆に、毎日貢献しているコードベースのセクションで、わずかではあるが持続的なスローダウンが発生すると、すぐに膨大な時間の損失が発生する可能性があります。

これを説明するには、プロジェクトの各領域がどのくらいの頻度で貢献されているかを調べる必要があります。ここで取れるアプローチはいくつかあります。Git の歴史を見て、どの領域が最も頻繁に触れられているかを理解し、より焦点を絞った次のようなツールを使用します。コードシーンより消化しやすい過去の貢献データを取得するか、今後の計画と優先順位を見て、今後数か月間でチームがほとんどの時間をどこに費やすかを理解することで、前向きなアプローチを使用します。

データを取得する方法に関係なく、コードベースの各セクションとのやり取りに費やす時間の割合の内訳を取得できます。これを、既に決定した Interest の寄与と組み合わせると、コードベースの各セクションを処理する際にどれだけ遅くなると予想されるかを正確に確認できます。

前の例を続けます - 前向きな見方をして、次の 3 か月で取り組む予定のすべてのプロジェクトを新しくした場合、これがコードベースの各領域で費やされた時間であると自信を持って見積もることができます (これは非常に単純なプロジェクトであることを覚えておいてください):

これを、速度ベースのアプローチと品質メトリック ベースのアプローチから得た関心の見積もりに結び付けて、どこで最も遅くなっているのかを把握することができます。

ここでは、以前に速度ベースの測定を調べたときにセクション B と C の作業で見た速度の低下を使用しており、それを使用して、今後 3 か月で技術的負債が原因で予想される損失時間を計算しています。全体として、開発者は 28 か月分以上の労力を費やして、借金だけに費やされると予想しています。このアプローチで考慮すべき重要なことは、これらすべてが相対速度を見ているということです。したがって、ベースライン プロジェクトは事実上負債がないものとして扱われますが、これは通常は正確ではありません。このアプローチのもう 1 つの問題は、発生する可能性が高い将来の債務水準の変動を考慮していないことです。しかし、それらは予測が難しいため、無視する方が簡単です。

ここでは、各セクションのコード品質に基づいて予測される典型的な遅延を取得し、今後 3 か月にわたってそれを予測しました。全体的に、ベロシティ法を使用した場合よりも大幅に低い債務影響予測が見られます。これは、技術的負債に基づくスローダウンの見積もりが、速度のケースで見たものよりも低いためです。このケースでは、さらに調整を行う必要があるかもしれません!速度ベースのメトリックと同様に、これは技術的負債の将来の変化を考慮していませんが、両方の見積もりは、プロジェクトのさまざまなセクションの書き直しとリファクタリングの優先順位を決定するのに役立ちます.

利子と負債の管理

技術的負債が継続的にどれだけの影響を与えているかを説明するために、いくつかの異なる方法を検討しましたが、技術的負債の健全なレベルとは何かという質問には完全には答えていません.

残念ながら正確な数字はありません。短期的には、いくらかの負債を受け入れることは現実的かもしれません。しかし、長期的には、負債をゼロに近づけることを目指したいと考えています。関心が長引くと非常にコストがかかり、技術的負債が積み重なっていくからです。しかし、わずかな利益しか得られない問題のリファクタリングや書き直しにすべての時間を費やしたくはありません。

前に説明したように、通常、次のようなコードベースの領域に対処するのに時間を費やしたくありません。

しかし、この極端なケースでは、修正に非常にコストがかかる高水準の負債によって大幅に減速するケースになる可能性があります。これも良い状況ではありません。

最善のアプローチは、真ん中のどこかに落ちることです。継続的な計画に時間を割いて、技術的負債の問題に対処し、既存のコードをリファクタリングして、現在最もコストがかかるものに優先順位を付けます。そして、借金を減らすことによる利益の大幅な減少が見られるまで、それを続けてください.