従来のコードベースでの時間コストの見積もり

最近、非常に古いモノリシックアプリケーションをマイクロサービスベースのアーキテクチャに移行するプロジェクトに取り組み始めました。

レガシコードベースは非常に乱雑（「スパゲッティコード」）であり、見かけ上単純な関数（例：「multiplyValueByTen」と呼ばれる）はしばしば「3つの異なるスキーマにまたがる10個のテーブルを含む数千行の検証コード」として現れます。

今、私の上司は、新しいアーキテクチャで機能Xを作成するのにどれくらいの時間がかかるかを（正しく）尋ねています。しかし、現実的な見積もりを思い付くのは困難です。多くの場合、上記の理由によりタスクを非常に過小評価しており、時間内に終わらないので困惑しています。

賢明なことは、実際にコードに入り、すべてのブランチと他の関数の呼び出しに注意して、時間コストを推定するように見えるかもしれません。しかし、古いコードを文書化することと、実際に新しいバージョンを書き留めることの間には、ごくわずかな違いがあります。

このようなシナリオにどのようにアプローチすればよいですか？

レガシーコードのリファクタリングの仕組みを完全に理解していますが、私の質問は「リファクタリング/リライトの方法」ではありません。しかし、「パートXのリファクタリング/リライトにどれくらい時間がかかるか」に対する現実的な答えを与えることについては。

ボブ・マーティンの「Clean Coder」（および「Clean Code」をご覧ください）をお読みください。以下はメモリからのものですが、自分でコピーを購入することを強くお勧めします。

必要なのは、3ポイントの加重平均です。作業ごとに3つの見積もりを行います。

• 最良のシナリオ-すべてがうまくいくと仮定する（a）
• 最悪のシナリオ-すべてがうまくいかないと仮定する（b）
• 実際の推測-おそらく何がかかると思うか（c）

推定値は（a + b + 2c）/ 4です

• いいえ、正確ではありません。推定のより良い方法がありますが、この方法は迅速で理解しやすく、最悪の場合を考慮することで楽観主義を緩和します。
• はい。マネージャーに、コードに不慣れであり、予測を改善するために毎回コードを調査するのに長い時間を費やすことなく、正確で正確な見積もりを行うのはあまりにも予測できないことをマネージャーに説明する必要があります（ただし、あと何日かかるかをしっかりと見積もるためにn日が必要だと言います）。あなたが「JuniorDev」である場合、これは合理的なマネージャーにとって受け入れられるはずです。
• また、ベストケース、ワーストケース、および可能性のあるケースに基づいて推定値が平均化されていることをマネージャーに説明し、エラーバーも表示する数値を提供する必要があります。
• 見積もりについて交渉しないでください-あなたのマネージャーがすべての見積もりに対して最高のケースを使用しようとすると（彼らはばかです-しかし、私はそのようなものに会ったことがあります）、いじめ/締め切りに間に合うように動機付けます時々がっかりするでしょう。推定の背後にある理論的根拠（ベストケース、ワーストケース、および可能性のあるケース）を説明し続け、ほとんどの場合、加重平均に近づいていくと、問題ないはずです。また、独自の目的のために、見積もりの​​スプレッドシートを保持し、完了したら実績を追加します。それはあなたの見積もりを調整する方法のより良いアイデアを提供する必要があります。

編集：

私がこれに答えたときの私の仮定：

1. OPは、ジュニア開発者です（選択したユーザー名に基づきます）。したがって、提供されるアドバイスは、開発環境の成熟度に応じて、より洗練された見積もりを実行できると期待されるプロジェクトマネージャーまたはチームリーダーの観点からではありません。
2. プロジェクトマネージャーは、提供に数か月かかる予定のかなり多数のタスクで構成されるプロジェクト計画を作成しました。
3. OPは、プロジェクトプランに入力し、進行状況を追跡するために使用する合理的な正確な数（確率曲線ではなく）を必要とするプロジェクトマネージャーによって割り当てられたタスクの見積もりを提供するよう求められています。
4. OPには各推定値を生成するための週がなく、過度に楽観的な推定値を与えることで以前に燃やされており、空中に指を刺して「コードが特に不可解である場合を除き、2週間」と言うよりも正確な方法が必要です以上"。

この場合、3点加重平均はうまく機能します。それは非技術的で迅速かつ包括的であり、いくつかの推定値は平均して精度に近いものになるはずです。特に、OPが見積もりと実績の記録を保持することについて私のアドバイスを受け取った場合。実際の「最悪のケース」と「最良のケース」がどのように見えるかがわかったら、最悪のケースが思ったより悪い場合は、実際の値を将来の見積もりに反映し、プロジェクトマネージャーの見積もりを調整することもできます。

実際の例をやってみましょう：

• 最良のケース、経験から、私が実際に行った最も速いものは、週の開始から終了まででした（5日間）
• 最悪の場合、経験から、どこにでもリンクがあり、6週間（30日間）かかったことがありました
• 実際の見積もり、おそらく2週間（10日）かかります

5 + 30 + 2x10 = 55

55/4 = 13.75これはPMに伝えるものです。たぶん、あなたは14日間に切り上げます。時間が経つと（10個のタスクなど）、平均化されるはずです。

数式を調整することを恐れないでください。たぶんタスクの半分は悪夢に終わり、10パーセントだけが簡単です。estmateをa / 10 + b / 2 + 2c / 5にします。あなたの経験から学びましょう。

注：PMの品質については何も仮定していません。悪いPMは、承認を得るためにプロジェクトボードに短い見積もりを出し、プロジェクトチームをいじめて、彼らが約束した非現実的な期限に到達しようとします。唯一の防御策は、記録を残すことです。これにより、見積もりを出し、それに近づくことができます。

これは、準アジャイルアプローチを導入する良い機会かもしれません。時間/日で見積もる代わりに、フィボナッチタイプのスケールを割り当て、各タスクにその大きさに基づいた値を与えた場合：

• 0-インスタント
• 0.5-クイックウィン
• 1-簡単な変更
• 2-いくつかの簡単な変更
• 3-より挑戦的
• 5-について考える必要があります
• 8-かなりの量の仕事
• 13-おそらく分解する必要がある大きな作業
• 20-間違いなく分解する必要がある大量の作業

次に、このような一連のタスクを見積もったら、それらに取り組みます。アジャイル環境では、「速度」を開発します。これは、たとえば1週間で達成するポイント数の尺度です。数週間のテストと学習を行ったら（プロセスの一部としてこれをマネージャーに販売できます-「数週間のテストが必要です。推定プロセスを理解するために学習します」）毎週プッシュできるポイント数に自信があるため、ポイントの見積もりをより簡単に時間に換算できます。

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

セレモニーを伴わないので、これは本当にアジャイルではありませんが、私は彼が彼自身であるという考えをOPから得ています。うまくいけば、このアプローチがより信頼できる推定値を提供するかもしれません。

あなたが最初に行うことは、今何かを成し遂げるのにどれくらいの時間がかかるかに関するデータの収集を開始することです。チームのパフォーマンスに関するデータが多いほど優れています。それは全面的に行われますが、今は心配しないでください。それは真実であり、あなたはあなたの上司の現実を示す必要があります。

それから、あなたは数冊の本を買いに行きます。

1. ソフトウェアの推定：Steve McConnellによるブラックアートの謎解き
2. マイケルフェザーズによるレガシーコードを効果的に使用する

McConnellの本では、データの収集を開始してから、それを使用してより正確な推定値を取得する方法を説明しています。常に3ポイントの見積もりをしてください！常に。コードの品質が悪いと見積もりがどの程度低下するかについて説明している本の部分を強調してください。上司に見せてください。

正確な見積もりが会社にとって重要である場合、Featherの本から学んだことを適用し始める必要があることを説明します。すばやく、スムーズに、そして予測どおりに進みたい場合は、コードのリファクタリングを開始して、テストハーネスに組み込む必要があります。私はあなたがいる場所に正しかった。開発時間は完全に予測不可能です。何が壊れるかわからないからですよね…。テストハーネスに入れます。これらのテストを実行するCIサーバーも害はありませんでした。

最後に、しばらくの間、物事はまだ少し予測不可能であることを上司に説明してください。おそらく数年ですが、その開発は毎日より簡単になり、データが多くなりコードが改善されると推定値はより正確になります。これは会社にとっての長期投資です。私は最近これを経験しましたが、ほとんど予測可能になるまでに2年近くかかりました。

推定よりもコードの改善について話したことは知っていますが、難しい真実は、レガシーコードベースを使いこなせるようになるまで、推定がお粗末になるということです。それまでは、過去のパフォーマンスを使用して、所要時間を測定します。時間が経つにつれて、コードを既に見積もりの​​仕様に達しているかどうかを考慮する必要があります。

今、私の上司は、新しいアーキテクチャで機能Xを作成するのにどれくらいの時間がかかるかについての見積もりを正しく求めています。しかし、現実的な見積もりを思い付くのは困難です。多くの場合、上記の理由によりタスクを過小評価し、時間内に終了できないために自分自身を恥ずかしく思います。

おそらく、1つの見積もりを提出することを考えているのでしょう。レガシーコードで作業する必要があり、より正式な見積もりを行う場合、通常2つまたは3つを作成します。

1. 一次見積もり-掘り下げるのに時間がかかりますが、アーキテクチャによって必要な変更が許可されると仮定します
2. Angelic Estimate-すべてが透明で見つけやすいと仮定し、わずかな変更を加えるだけです（特に、特定のコードベースに悪魔しかいないことがわかっている場合は、これは時々省略します）。
3. Abyssal Estimate-レガシーコードの基本構造が要求された機能と互換性がないと想定し、物事を機能させるために主要なリファクタリングを行う

3つの推定値はすべて、機能自体の強さ、それ自体、その一般的なコードベースでの経験、および変更についての私の直感（非常に正確であることがわかった）を考慮に入れています

これらの見積もりが出た後、私はマネージャーが対処しているように見えるマネージャーについて最新の状態を保ちます。私たちが深featureの機能を見ていることが判明した場合、それを犠牲にする必要があるかもしれません-それは起こりました。レガシーコードの特定のチャンクに深a機能があることを上司が受け入れられない場合、非常に困難でイライラする人生があるため、幸運を祈ります。

この種の問題に直面したとき、見積もりに範囲を与えることに頼りました。私は上司に「このコードベースですぐに使える見積もりをするのは難しい。あなたがそれを求めれば、それは非常に広い見積もりになるだろう」と言い去りました。私は「3日から3年」を一度見積もりとして与えました。言うまでもなく、それは一般的な見積もりではありませんでしたが、私が与えたものです。

これの鍵は、作業が進行するにつれて見積もりを更新するという合意です。「XYZの実装、どれくらい時間がかかりますか？」私の答えは「1日から4か月の間のどこかです。しかし、実際にコードを数時間見てもらえば、そのウィンドウの不確実性を減らすことができます」。次に、コードを見て、「2〜4週間」で戻ってきます。それはまだ理想的なウィンドウではありませんが、少なくとも管理できるものです。

これにはいくつかのキーがあります。

• 作業中にタスクがどのように見えるかについて詳しく知ることができるため、これらの見積もりは会話として扱われる方がよいと上司に確信させます。これは、上司が単一の見積りを要求しただけでは得られない情報を入手する機会です。
• トレードコードの開発速度と見積りの改善のどちらを進めるかについてのオプションを提供します。彼らが回すことができる余分なノブを与えます。上司は、タスクを完了する必要があるだけで、大まかな見積もりだけが必要なことを知っている場合があります。また、タスクの長所と短所を実行している場合もあり、見積もりを調整する機能は貴重です。
• 可能であれば、シナジーボーナスも提供します。多くの場合、多くのタスクにメリットがあるアーキテクチャの改善があります。10個のタスクがあり、そのすべてが「1〜2か月で、アップグレードXで2週間かかる」場合、アップグレードXにかかる20週間を売る方が簡単です。

進行中に更新される範囲を受け取ることに不安を感じている上司がいる場合は、単一の番号と方法論を伝えます。私の方法論は、若い開発者として言われた経験則と、ホフスターダーの法則の組み合わせです。

タスクにかかる時間を見積もってから、その数を4倍にして、見積もりとして与えます。

そして

Hofstadterの法則：「Hofstadterの法則を考慮しても、常に予想よりも時間がかかります。」

賢明なことは、実際にコードに入り、すべてのブランチと他の関数の呼び出しに注意して、時間コストを推定するように見えるかもしれません。しかし、古いコードを文書化することと、実際に新しいバージョンを書き留めることの間には、ごくわずかな違いがあります。

これが問題の解決策です。要件がない場合は推定できません。コーディングを開始する前に、これを行う必要があることを上司に伝えてください。いくつかの関数とモジュールを実行した後、それらがすべて一貫してコード化されている（この場合は不十分）ことに気付く可能性があります。コーディングが悪化することがわかった場合は、必ず見積もりを調整してください。

あなたの上司が見積もりを望んでいることは承知していますが、この情報がどのように使用されているかを知らなければ、見積もりがどの程度正確である必要があるかわかりません。彼と会話をして、調べてください。上司に渡すために数字が必要な場合は、見積もりをわずかに膨らませて数字を入力します。これが完了するまでコードの支払いを待っているクライアントの場合は、確定納期が大幅な収益をもたらすかどうかを確認してください。

このような状況では、良い推定値を出すことは不可能だと思います。基本的な問題は、多くの場合、それを行うための大きな部分が、何をする必要があるかを正確に把握することです。

私はこのようなケースに対処するために、必要と思われるものに基づいて推定値を提供しますが、洞窟では驚きがありそうです。私はレガシーコードの方法であまり対処する必要はありませんでしたが、入力を扱う非常に厄介な驚きがありました-数時間は数週間になり、これは不可能になりました（後かなり掘り下げて、特定のケースで十分なデータがなかったことがわかりました。図面に戻ります。）幸いなことに、上司はそのような推定値をいつ伝えるかを理解しています。

まあ、推定は、一部の人々がよく学ばないスキルです。たとえ良い見積もりを思い付かなくても、開発者として役に立たないわけではありません。たぶん、チームメイトや経営陣がギャップを埋めるでしょう。私はそれでひどいですが、ほとんどのチームは私と一緒に仕事をするのが好きでした。落ち着いてチームを組み、リファクタリングを続けます。

技術的な借金はあなたにちょっとした挑戦を与えますが、借金を生み出すことになった会社/チームは、チームの精神や経営に変化がなければ借金を生み出し続けることを忘れないでください。コードは単に社会問題を反映しているだけなので、実際の問題に注目してください。

ブラウンフィールドプロジェクトの機能を推定するためにヒューリスティックを使用しました。グリーンフィールドプロジェクトにその機能を実装するのに、何も実装されていなかった場合にどれくらいの時間がかかるかを推定しました。次に、その推定値に2を掛けて、すでに存在する破片をクリーンアップしました。

この係数は結合の量と全体のコードサイズに依存しますが、この方法でいくつかの機能を実行する場合、実際の証拠に基づいてその係数を補間できます。

私はあなたが上司と一緒に座って、目で彼を直接見て、言うべきだと思う：

「ボスを聞く！ここでリファクタリングしています。提供する新しい機能はなく、その機能を待つ顧客もいません。期限はありません。これには時間がかかる限り、それを行う必要があるかどうかを判断する必要があります。」

指をさすようなしっかりした断定的なジェスチャーを使用して、椅子に座ってください。

あるいは、彼を幸せにするためにいくつかの数字を作ることもできます。しかし、あなたが仕事の途中に来るまで、あなたの見積もりはかなり不正確になるだろう、それに直面することができます。