私は経営陣にリファクタリングへの努力を投資するよう説得するための議論を探しています。
Jiraを使用して作業を記録し、すべてのsvn-commitをjira呼び出しに関連付けます。
私のアイデアは次のことです。
これについてどう思いますか？そのような測定は有用であり、説得力があるでしょうか？長所と短所は何ですか？
回答:
有効な番号を提供できれば、マネージャーが行動する可能性が高いことがわかりました。（彼らが論理と費用/便益を理解できるなら。）
私見、説得力のあるケースを作成するには、それがどれほど悪いかを示すために次のものが必要です：
そして、リファクタリングを主張するには、次のものが必要です。
これらを使用すると、リファクタリングにかかる時間が、上位3つの各アイテムの3つのインシデントのサポート時間よりも大幅に短い場合、時間を節約できます。あなたはこの短い時間が費やされると主張することができます
ただし、多くの人があなたがしているすべてのサポートのスケジュールに時間を割いていないため、この販売の最も難しい部分は次の質問に答えることです。
Xでこれらの問題の作業に時間を費やしている間に、現在のプロジェクトYが完了するのをどれくらい待つ必要がありますか????? （現在のサポートタイムシンクにもかかわらず、ガントチャートで予測およびスケジュールすることはできません）
これは、意思決定者とのコミュニケーションの程度と、状況をどのように理解しているかに大きく依存します。
これは間違いなく価値があると思うので、メトリックを使用してケースを作成し、時間を節約するために、たとえそれがうまくいかなくても、練習することができます。残念ながら、データにもかかわらず、誰もが納得しやすいわけではありません。幸運を！
リファクタリングではバグも発生することに注意してください（テストではこれをキャッチしますが、それでもバグであり、修正する必要があります）。偶然にNetscapeを引っ張らないでください。「リファクタリング」の個人的な定義に依存します。一部の人にとって、これは「すべてのコードを他の人に書き換える」ことを意味し、「一部の内部を変更する」ことを意味します。自分がどんな人なのかをどのように見分けますか？次の質問を自問してください。
パブリックインターフェイスを変更していますか？
答えが「はい」の場合、再設計を行っています。答えが「いいえ」の場合、リファクタリングを行っており、おそらく特別な承認なしに日常活動の過程でそれを行うことができます。これは、再設計により多くのバグが発生するため、リファクタリングは通常実行しやすいためです（テストは既にパブリックインターフェイスを実行し、それ自体を変更する必要がないため）。
1年前に行われたリファクタリングの有無にかかわらず、Xがどれだけのコストを要するか誰も知らないため、これは難しいケースです。私の経験では、実用的なマネージャーは常にこの種のものを撃shootします：
すべてのそのような数は、最終的には、あなたはそれがかかるだろうと思う量の比較あなたのケースでは、推測に基づいていないあなたはそれがかかるだろうと思いますどのような対リファクタリングするにリファクタリングを。あなたができる最善のことは、推測に何らかの数値的で事実に基づいた根拠があることを示すことです。
長所は、おそらくリファクタリングできるように説得するのに効果的であり、うまくいくとバグの数を減らすことができるということです。
短所は、バグの修正に費やされた時間が少なくともリファクタリングに費やされた時間ほど下がらない場合、おそらくリファクタリングが許可されず、おそらく「無駄な」時間のせいにされるということです。 。
プロジェクト全体の複雑さを軽減したり、機能の追加を容易にしたりすることで得られるデバッグ時間の節約は、測定するのが困難すぎてあまり役に立たないかもしれませんが、それらが存在することは言うまでもありません。