リファクタリングの潜在的な価値を測定する方法


46

技術的な負債を抱える古い大規模なプロジェクトでは、リファクタリングコードの利点をどのように確実に推定または測定できますか?

たとえば、古い言語で記述されたソフトウェアスタックソリューション内のコンポーネントと、新しい言語で記述された後のコンポーネントがあるとします。このソリューションには、開発チームによって常に新しい機能とバグ修正が追加されています。

開発者は、既存の古い言語コンポーネントを新しいバージョンに置き換えることは「良いこと」だと提案します。ただし、この作業によって追加の機能は追加されず、x開発日数かかります。

営業担当者は、「すばらしい新機能」を追加することを提案しています。会社は数式を使用して提案の価値を測定します。すなわち。x dev-daysの作業コストで、t年間でFポンドを獲得します。

どうすれば会社はリファクタリングの提案に意味のあるコストをかけることができますか?そして、どのような状況下でそれが会社にとって最も収益性の高いオプションになる可能性がありますか?


可能性のある重複んが完済職人技?
gnat

あんまり?それは開発者のキャリアの観点から見返りを得るということです。私は非特徴タスクのビジネス価値を測定について聞いてるのよ
ユアン・

3
番号。私の質問は、これらのいずれかが重複していると思わせますか?
ユアン

4
私が質問「あなたはまた、に興味がある可能性があり、」にブヨ用途にリンクする「可能性の重複」の事を考える@Ewan
ベン・アーロンソン

8
「信頼できる」?ソフトウェアを推定するのは難しいことで有名です。これに読み取りを与える:blog.hut8labs.com/coding-fast-and-slow.html。フォローアップ(下部にリンク)も読んでください。リスクの観点からこれにアプローチする方が良いでしょう。他の技術的負債をリファクタリングまたは処理するリスクは何ですか?技術的負債を処理しないリスクは何ですか?(2番目は常にメンテナンスまたはバグに関連するリスクになることに注意してください。)このように、ビジネスの現実とオプションを提供します。リスクを受け入れるかどうかは会社次第です。
jpmc26

回答:


48

x dev-daysの作業コストで、t年間でFポンドを獲得します。

メンテナンスコスト、サポートコスト、販売/マーケティングのコストを無視し、市場で機能がどのように使用されるかについて多くの仮定をしています。

しかし、何でも。あなたが探しているものについてあなたの質問は十分に明確です:

リファクタリングのビジネスケースを作成するにはどうすればよいですか?

認識すべき主なことは、時間はお金に等しいということです。「5人の開発者2週間= 80時間* 5人の開発者* $ 50 /時間-> $ 20,000」に直行できます。これはビジネスマンにとって理にかなっています。賢明なビジネス関係者は、これら5人の開発者がどちらの方法でも支払われていることに気付くでしょう。とにかく、リストで。

  • 効率性 -おそらく、VB6よりもC#でより多くのことができます。優れたツール、優れたライブラリ、その他。新しいテクノロジーは、古いテクノロジーよりも優れている傾向があります。短時間で作業ができるということは、会社のお金を節約できるということです。
  • オーバーヘッド -ソフトウェアのコストはコーディングだけではありません。Windows 2020が登場したときに何が起こるか考えてください。そのVB6アプリを動作させるのにどれだけの時間と労力を費やしますか?それはC#アプリよりもはるかに多くの時間と労力ですか?それはあなたの会社のお金を節約しています。
  • 品質 -おそらく、C#ではVB6よりも高品質(またはよりクリーンなアーキテクチャ、またはリファクタリングターゲットが何でも)で処理を行うことができます。品質が高いほど、バグが少なくなります。バグが少ないということは、これらのバグを修正するためのコスト、これらの問題を解決するためのカスタマーサポートコスト、品質の問題による顧客の損失の減少、品質に対する評判による売上の増加などです。
  • HRセービング -事実に直面しましょう。誰もそのくだらないVB6アプリを使いたくありません。それは、より多くの人々が会社を去り、それらを置き換えるために時間とお金が費やされることを意味します。つまり、新しい従業員を雇用するには、より多くの時間とお金が必要です。最悪なのは、そのVB6アプリを使用してキャリア自殺を完全にコミットしている開発者がいることを意味します。これらの開発者は、順番に品質問題の死のスパイラルを早めます。離職率と雇用時間を削減することで、会社のお金を節約できます。自己満足でくだらない開発者を遠ざけることで、会社を救うことができます。
  • 士気 -同様に、すでにそこにいるプログラマーはVB6で働くことを嫌います。彼らはそれをするでしょう、そして彼らはそれを上手くやるかもしれません。しかし、それは最悪です。多分皆のためではなく、確かにいくつかのために。それは、モチベーションを取り戻すためにWebをブラウズするのにより多くの時間を費やすことを意味します。それはより長い昼食を意味します。それは、プログラマーが下手な仕事から回復するのにより長い時間をかけながら、仕事を片付けることを減らすことを意味します。
  • 機能 -これはテクノロジー主導のリファクタリングではあまり適用されませんが、アーキテクチャの種類のリファクタリングに適用されます。特定のコードの問題により、クールな機能Xを提供して大量のお金を稼ぐことができません。たぶんあなたはスケーリングできない。たぶん、あなたはデータを取得してクールな情報学を行うことはできません。おそらくコードはネズミの巣であり、実際に作業を行うことは非常に困難です。なんでも。時々あなたはそのポイントにいます、そして時々あなたはそのポイントに向かってまっすぐに運転しています。ビジネス用語に翻訳するのは難しいですが、可能であれば「この問題が、私たちが機会X、Y、Zを活用することを妨げている」ことが強力な場合があります。

要するに、「このことは仕事をより良くするのに役立ちます。仕事をもっとよくすれば、より多くのお金を稼ぐ/節約することができます」。


1
「どのような状況で最も収益性が高いと思われるか」についての考えはありますか?開発チームの総コストで最大化するコスト削減の観点からのみメリットを定義すると思われます。大企業では、これは可能性の高い新機能のX」による売上高は言う'10%の増加によって極端に小さくすることがある
ユアン・

11
@Ewan-「売上の10%の増加」は、コストの平等な増加を伴う場合、あまり良くありません。競合他社が市場に参入して優位に立ってから6か月が経過した場合、「売上の10%増加」は役に立ちません(したがって、売上が-10%増加します)。機能より重要な場合もあります、多くの場合、「売上の10%の増加」はたまにしかありません。
テラスティン

4
VB6を維持するビジネスリスクもあります。マイクロソフトは数年前にVB6のフルサポートを落としたとオンに沿って足を引きずってきた「これだけの作品」以来のサポート。ビルド環境はXPより新しいものでは実行されず、ランタイムはWindowsの将来のバージョンで動作を停止する可能性があります。たとえば、VB6がWindows 10でサポートされているという正式な発表はまだありません。
Dan Lyons

1
すべての例は架空のものであり、実際の企業との類似点はまったく偶然です
。...-ユアン

12

自問すべき質問は、この機能が開発者の作業にx日かかることを営業担当者がどのように知っているかです。長年のプロの経験を持つ優秀なプロジェクトマネージャーでさえ、それをしばしば語ることができないことを考えると、営業担当者からのこのようなデータは非常に推測的です。

私の経験によると、営業担当者は通常、見積もりを行いませんが、管理者や顧客にとってどれだけ多すぎるかを推測します。この機能は再交渉の準備ができている間(実際の見積もりでは問題になっているもの)、55人週まで70人週かかります。

  • 一方では、次のようなことを言っているIT専門家による見積もりがあります。

    この特定の監査によると、新しいテクノロジーを使用する同様のサイズの同様のプロジェクトと比較して、時代遅れのテクノロジーを使用して1日あたり8,000ドルを無駄にしています。また、コードベース全体を移行するのに50〜80人週かかると思われます。この間、新しい機能はリリースされません。また、特定のコンポーネントを移行すると、20〜30週間の追加作業が発生する可能性があるという10%のリスクもあります。

  • 一方、説得する必要のある人と交渉する際のレバレッジに基づいて、セールスマンが推測したことがあります。

それはあなたがあなたの会社にどれほど影響力があるかということです。ここではコミュニケーションが重要です。これは、管理者(または顧客)に機能の利点を説明する際に、セールスマンが通常ITプロフェッショナルに勝つ場所です。

過去に見積もりが非常に正確だった場合、評判と影響力を獲得することに注意してください。見積もりが常に間違っていた場合、経営陣はおそらくあなたの提案を無視するでしょう。

見積もりに関しては、考慮すべきパラメーターが非常に多いため、ここで価値のあるものを作成することは非常に困難です。とりわけ:

  • VB6と比較して、C#でのチームのスキルを実際に知っていますか?それは実際の測定値に基づいていますか、それとも単なる推測に基づいていますか?

  • このチームはC#で大規模なプロジェクトを開発しましたか?使用すべきツール(IDE、デバッガー、プロファイラーなど)を知っていますか?追加のライセンスが必要ですか(Microsoftの世界では、マシンごとに数千ドルを意味します)。

  • 現在のプロジェクトは完全に明確であり、移行時に驚きがないことを保証できますか?すべて、すべての機能を書き直すのは簡単ですか、それとも驚きがありますか?

  • C#をサポートするインフラストラクチャはありますか?継続的インテグレーションはどうですか?ビルドサーバーはどうですか?スタイルガイド?静的チェッカー?

  • 運用環境では、サーバー(これがWebアプリの場合)または顧客のPC(これがデスクトップアプリの場合)は、使用する予定の.NET Frameworkのバージョンを実行できますか?

しかし、最も重要なことは、なぜすべてを書き換えたいのを知ることです。書き換えによって解決しようとしている問題はですか?生産性の損失?どのように測定しますか?この生産性の損失を経営陣にどのように示しますか?

たとえば、VB6のために1日あたり8,000ドルを浪費していることを示したら(つまり、C#に移行すると1日あたり8,000ドルを節約できます)、すべての新機能の開発と完全な書き換えに焦点を当てていますか?コンポーネントを1つずつ小さな塊で移行しながら、新機能を出荷するプログレッシブリライトと比較した場合の利点は何ですか?


営業担当者の例は、お金で提案の価値を測定する「合計」があることを示すためだけのものです。開発者はどのような「合計」を使用できますか?
ユアン

2
生計を立てるソフトウェアを30年にわたって開発した後、IT専門家から得られた見積もりは、実際には営業スタッフからの推測に基づいたものに過ぎないと言うことができます。フランネルが多く含まれているだけです。悲しいことは、それらが異なる場合、見積もりは常に正しいとみなされ、実際の配達は間違っているということです。
ビンスオサリバン

3

まず、販売主導の機能リクエストと同様に、リファクタリングの開発コストを見積もる必要があります。

大規模な仕事の場合、これを正確に行うのは難しいかもしれませんが、2つのテクノロジーの経験が十分にあると仮定すると、実行できるはずです。

次に、リファクタリングを行わない場合のコストの見積もりが必要です。あなたが私のために見積もりをしていたなら、私はある程度のメトリックを期待しています。たとえば、四半期のVBコードとC#コードの平均開発コストの差。またはそのようなもの。これをどの程度正確に追跡するかに明らかに依存します。

これらの2つの数値を使用して、リファクタリングがもたらすペイバック期間、つまりリファクタリングが純費用から純利益に変わる時点を見積もることができます。

特定の結果がどの程度説得力があるかについてのみ推測できます。ただし、1年未満の場合はおそらく非常に強力で、2年をはるかに超えると、苦労する可能性があります。

さらに、ケースの作成に役立つ他のディメンションを追加する価値があります。私が過去に使用したことの1つは、出口インタビューでテクノロジーがドライバーとして引用されているかどうかを確認することです。もしそうなら、リファクタリングはスタッフを維持すると主張することができます(雇用とトレーニングは非常に高価です)。

もちろん、証拠を裏付けることなくこれらのことを議論できますが、事件の影響に大きな違いをもたらすことができると思います。


2

リファクタリングの価値はさまざまな方法で現れます。

後で他の変更を加えるのに役立ちます。そのため、その機能にかかっていたX日間は、完了するのに2 / 3X日かかります。アジャイルの用語を使用すると、速度が上がります。

リストされた明示的な変更は、VB6の経験を持つ開発者を維持する必要がなくなり、C#の経験がある開発者のみを維持する必要があるため、時間の経過とともに役立ちます。

また、スタッフの定着や採用など、その他の具体的でない方法でも役立ちます。C#とVB6を実行するジョブは、C#のみを実行するジョブよりも魅力的でしょうか?あなたは仕事に就く可能性がありますか、それともすてきなコードベースまたはお粗末なものに取り組んでいる仕事にとどまるでしょうか?


2

他の答えが見落としている点は、リファクタリングを行わないことによる収益の損失に対してリファクタリングのコストを測定する必要があるということです。

コードを変更するためのリファクタリングは時間の無駄です。テーブルに価値をもたらす必要があります。このコンテキストでは、問題のクラスをリファクタリングするのに1時間かかるのではなく、例で使用したように別のCLR言語に変更するなどの主要なリファクタリングを行います。

  • 私たちがやっていることをやり続けるなら、何かを見逃していますか?価値を実現することを妨げている、古いデザインがありますか?たとえば、機能を追加したい場合、実装に100時間かかるのに対して、リファクタリングに50時間、新しいデザインに対して実装するのに25時間かかりますか?

  • 既存のコードにはお金がかかる技術的負債がありますか?このくだらない古いコードはバグの原因ですか?そのため、問題を修正するために無料で作業することになりますか?誰もが有利な請求可能な時間を無料で提供することを好みません。

  • リファクタリングのコストは、リファクタリングを行わない場合のコスト以下ですか?

  • ロックスターの小さなチームが最も多くの問題を引き起こしているコードをリファクタリングすることによってコストを償却することは可能ですか?リファクタリングをリリース全体に広げることはできますか?どこにでも小さな非効率性があります:この余分な仕事といえば「ギャップを埋める」ことができますか?


1

リファクタリングされたシステムを持つことの利点

リファクタリングのビジネスケースを作成するには、ビジネスの最終的なメリットを実行する場合と実行しない場合のメリットを比較します。これは、現在の実質コストの削減、または将来の実質キャッシュインフローの増加を意味します。

リファクタリングの影響を受ける主要な予算項目は次のとおりです。

  • メンテナンスコスト-現在のシステムがスパゲッティの脆弱な山であり、実際には小さなバグ(開発と運用の両方)の修正に多大な工数がかかることが観察できる場合、そのようなコストが予想されます「適切に再設計された」システムの場合、メンテナンスは小さくなります。年間の純粋なメンテナンスコストと、書き換え後に実際にどのように変化するかを確認してください。
  • 新しい機能を追加するコスト-繰り返しますが、現在のシステム設計と構造により、新しい機能を記述するのに不当に時間がかかる場合は、書き換えによって節約できる可能性があります。新機能の計画予算を見てみましょうが、現実的です-50%の改善が見られると主張する場合、以前に実現するのに2 * x人月を要したx人月で実際に機能を開発することを期待してください。そのような約束を守るのは難しいかもしれません。

  • ソフトウェアの品質が販売に与える影響-現在のシステムが、適切な保守作業にもかかわらずクラッシュやダウンタイムなど、顧客に見える問題を頻繁に引き起こしている場合、書き換えが解決策となります。IFこれは大きな問題であり、その後、同じ営業担当者は「より安定した製品」と呼ばれる「機能」の値を定量化することができます。

上記の3つの点がリライトの予想コストに達しない場合(さらに、非機能にx dev-daysを費やす機会コストは、それらの機能の値に等しく、x devの純粋なコストよりも大きい-日)それからそれが怖い-予想される節約は書き換えを正当化しない。

また、ロードマップが「提供できる限り」の新機能の必要性を示さない場合、節約は「必要なすべてのことを行うのに10人が必要だった」という形になりますが、書き直した後は「たった6人で同じことができる」。開発者よりも多くの開発プロジェクトを「販売」できる場合、効率を改善することでより多くの開発が可能になりますが、現在のリソースを持つビジネスが、付加価値をもたらすすべてのものをすでに開発できる場合、唯一の経済的利益があります少ない人にお金を払ったり、安い人を雇ったりすることができます。


0

リファクタリングの価値は次のように測定できます。現在、新しい機能xの開発コストは5週間で2週間です。古いコンポーネントをリファクタリングすると、新しい機能のコストが推定20%削減されます。したがって、新機能xの費用は2週間で4人の開発者のみです。

リファクタリングは、将来の開発コストを削減するための投資です。リファクタリングのためにその議論をすることができない場合、おそらくビジネスケースはありません。


機能をより安く/より速くするという重要なポイントにヒットしたと思います。私はこのPROBは、コスト削減の任意の量よりも多くの付加価値を考える
ユアン・
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.