私は現在、かなり古い製品に取り組んでいます。この製品は、過去の貧弱なプログラマーや貧弱な開発慣行から多くの技術的負債を抱えていました。私たちは改善し始めており、技術的負債の発生はかなり鈍化しています。
状態の悪いアプリケーションの領域を特定し、それらの領域を修正するためのコストを見積もることができますが、投資収益率 (ROI) を見積もるのに苦労しています。
コードは保守しやすく、将来的に拡張しやすくなりますが、これらにドルの数字を付けるにはどうすればよいでしょうか?
開始するのに適した場所は、バグ追跡システムに戻り、これらの「悪い」領域に関連するバグと機能に基づいてコストを見積もることです。しかし、それには時間がかかり、価値の最良の予測因子ではないかもしれません。
過去にそのような分析を行った人がいて、何かアドバイスはありますか?
マネージャーは、成長 (何よりもまず、新しい顧客を引き付ける新機能など) と (2 つ目) プロセスのライフサイクルの最適化を通じて収益を上げることに関心があります。
あなたの問題を見ると、あなたの提案は 2 番目のカテゴリに分類されます: これは間違いなく目標 #1 に遅れをとります (したがって、これがお金を節約できたとしても優先順位が低くなります... )))。
ここで、「悪い技術的負債」に $ の数字を付けると、よりポジティブなスピンに変わる可能性があります (次のことがあなたのケースに当てはまると仮定します):さらにZ人の顧客を獲得する」.
つまり、技術的負債のコストをビジネス機会の損失のコストと比較して評価します。
あなたは正しい軌道に乗っていると思います。
これを計算する必要はありませんでしたが、多くのレガシー コードを扱う大規模なソフトウェア開発組織を管理している友人と数回話し合ったことがあります。
これまで議論してきたことの 1 つは、VCS コミットの分析から大まかな作業指標を生成し、それらを使用してプログラマーの時間の大まかな見積もりを分割することです。これは Joel Spolsky のEvidence-based Schedulingに触発されました。
このようなデータ マイニングを行うと、コードがメンテナンスされているときのクラスタリングを特定し、それを追跡システムでのバグの完了と比較することもできます (2 つの正確な記録の間の緊密な統合にすでに恵まれていない限り)。
適切な ROI は完全なリターンを計算する必要があるため、考慮すべき事項は次のとおりです。リファクタリングによる新しい製品ラインの生成
データを導き出すためのルールができたら、物事を正確に計算する方法について議論することができますが、少なくとも議論の種となる数字がいくつかあることを忘れないでください!
Sonarには、ソースコードを分析してそのようなメトリックを探すための優れたプラグイン (技術的負債プラグイン) があります。ビルドに特に使用できない場合もありますが、Maven ツールであるため、いくつかの優れたメトリックを提供するはずです。
これが彼らのアルゴリズムのスニペットです：
Debt(in man days) =
cost_to_fix_duplications +
cost_to_fix_violations +
cost_to_comment_public_API +
cost_to_fix_uncovered_complexity +
cost_to_bring_complexity_below_threshold
Where :
Duplications = cost_to_fix_one_block * duplicated_blocks
Violations = cost_to fix_one_violation * mandatory_violations
Comments = cost_to_comment_one_API * public_undocumented_api
Coverage = cost_to_cover_one_of_complexity *
uncovered_complexity_by_tests (80% of
coverage is the objective)
Complexity = cost_to_split_a_method *
(function_complexity_distribution >=
8) + cost_to_split_a_class *
(class_complexity_distribution >= 60)
私は、反復的かつ段階的なプロセスでこれを経験的に行う方法についてのみ話すことができます。
実証された最良のコスト/ストーリーポイントを見積もるには、メトリックを収集する必要があります。おそらく、これは、設計の試行錯誤のほとんどが行われたが、エントロピーが減衰を引き起こす時間が最も少ない、最初のアーキテクチャの解約直後のシステムを表しています。速度/チームサイズが最も高いプロジェクト履歴のポイントを見つけます。これをコスト/ポイントベースライン（ゼロデット）として使用します。
時間の経過とともに、技術的負債が蓄積するにつれて、速度/チームサイズは減少し始めます。ベースラインに対するこの数値の減少率は、新しいストーリーポイントごとに支払われる「利息」に変換できます。（これは本当に技術的および知識的債務に支払われる利子です）
規律あるリファクトとアニーリングにより、技術的負債への関心がベースラインよりも高い値で安定します。これは、製品所有者がシステムの技術的負債に対して支払う定常状態の利息と考えてください。（同じ概念が知識債務にも当てはまります）。
一部のシステムは、新しいストーリーポイントごとのコスト+利息が、開発中の機能ポイントの値を超えるポイントに到達します。これは、システムが破産したときであり、システムを最初から書き直すときです。
回帰分析を使用して、技術的負債と知識的負債を区別することは可能だと思います（ただし、私は試していません）。たとえば、技術的負債がコードの重複などの一部のコードメトリックと密接に関連していると仮定すると、技術的負債と知識的負債の違いにより、支払われる利息がどの程度増加しているかを判断できます。
失われたビジネスチャンスにjldupontが焦点を当てている場合は+1。
経営陣が認識しているこれらの機会について考えることをお勧めします。新機能、市場投入までの時間、製品の品質など、収益の成長に何が影響すると彼らは考えていますか？債務返済をこれらの推進要因に関連付けることは、経営陣が利益を理解するのに役立ちます。
管理者の認識に焦点を当てることは、誤った数え上げを回避するのに役立ちます。ROIは見積もりであり、見積もりで行われた仮定よりも優れているわけではありません。経営陣は、どこかに定性的なものがあることを知っているので、定量的な議論だけを疑うでしょう。たとえば、短期的には、債務返済の実際のコストは、プログラマーの現金コストではなく、プログラマーが行っていない他の作業です。これだけのために新しいスタッフを雇って訓練するつもりはないからです。 。将来の開発時間や品質の改善は、これらのプログラマーが追加する機能よりも重要ですか？
また、製品が管理される範囲を理解していることを確認してください。経営陣が今から2年後のことを考えていなければ、18か月間は現れないメリットを気にしません。
最後に、経営陣の認識により、この製品がそもそもこの状態になることができたという事実を振り返ってください。会社が技術的負債にもっと注意を払うようになるために何が変わったのですか？違いがあなたである場合-あなたは前任者よりも優れたマネージャーです-あなたの経営陣はこのことについて考えることに慣れていないことを覚えておいてください。あなたはそれに対する彼らの食欲を見つけ、彼らが気にかけている結果をもたらすであろうそれらのアイテムに焦点を合わせなければなりません。そうすれば、信頼性が高まり、それを使って彼らにさらなる変化について考えさせることができます。しかし、利益の評価は成長するのにしばらく時間がかかるかもしれません。
過去にかかった金額を見積もる方が簡単かもしれません。それが済んだら、上司でも理解できる範囲とロジックで将来の見積もりを立てることができるはずです。
そうは言っても、私はこの種のことについて多くの経験を持っていません。なぜなら、コードを修正するためにこれまで進んで進んでいるマネージャーを見たことがないからです。悪いコードを変更しなければならないとき、それは常に私たちが修正するものでした。そのため、リファクタリングは事実上、すべての変更とバグ修正の隠れたコストです。
ほとんどが単独または小規模なチームの開発者であるため、これは私の分野外ですが、時間が無駄になっている場所を見つけるための優れたソリューションは、非常に詳細な時間管理です。たとえば、このような便利なタスクバーツールを使用して、トイレに行ったときにも除外でき、すべてを XML にエクスポートできます。
最初は面倒で、チームに導入するのは難しいかもしれませんが、ソフトウェアのバグ、ミス、または誤解のために費やした 15 分ごとにチームが記録できれば、印象的な実際のデータの基礎が蓄積されます。毎月の賃金に実際にかかっている技術的負債について。
私がリンクしたツールは、非常にシンプルで (データベースさえも必要としない)、タスク バー アイコンからすべてのプロジェクト/アイテムにアクセスできるため、私のお気に入りです。また、実行された作業に関する追加情報を入力することもでき、計時は文字通り数秒で有効になります。(出品者様とは関係ありません。)