見積もりを求められた場合の対応方法

プログラマとして、私たちは常に「どれくらいかかるか」と尋ねられていますか？

そして、ご存知のように、状況はほとんど常に次のようなものです。

• 要件は不明です。すべての影響を詳細に分析した人はいません。
• この新機能はおそらく、コード内で行ったいくつかの仮定を破り、リファクタリングする必要のあるすべてのことをすぐに考え始めるでしょう。
• 過去の課題から他にやることがあり、その他の作業を考慮に入れた見積もりを考え出す必要があります。
• 「完了」の定義はおそらく不明です。いつ実行されるのでしょうか。コーディングを終えたときのように「完了」、または「ユーザーが使用中」のように「完了」
• あなたがこれらすべてのことをどれほど意識していても、「プログラマーのプライド」によって、本来考えていたよりも短い時間が与えられたり受け入れられたりすることがあります。締め切りと経営陣の期待のプレッシャーを感じるときは特に。

これらの多くは、組織的または文化的な問題であり、単純で簡単に解決することはできませんが、実際には、見積もりを求められており、合理的な答えを期待しています。それはあなたの仕事の一部です。単純に言うことはできません：私は知りません。

その結果、私はいつも私が後で達成できないことに気づくと見積もりを出すことになります。それは何度も起こりました、そして、私はいつもそれが再び起こらないことを常に約束します。しかし、そうです。

見積もりを決定して配信するためのあなたの個人的なプロセスは何ですか？どんなテクニックが便利だと思いましたか？

以下からの実用的なプログラマー：ジャーニーマンからマスターへ：

見積もりを求められたときに何を言うか

あなたは「私はあなたに戻ってきます」と言います。

プロセスを遅くし、このセクションで説明する手順を実行するのに時間を費やすと、ほとんど常に良い結果が得られます。コーヒーマシンで与えられた見積もりは（コーヒーのように）戻ってきてあなたを悩ませます。

このセクションでは、著者は次のプロセスを推奨しています。

• 必要な精度を決定します。期間に基づいて、異なる精度で見積もりを見積もることができます。「5〜6か月」と言うことは、「150日」と言うこととは異なります。7か月目に少しスリップしても、まだかなり正確です。しかし、180日目または210日目にすれば、それほど多くはありません。
• 何が求められているかを理解してください。問題の範囲を特定します。
• システムをモデル化します。モデルは、メンタルモデル、図、または既存のデータレコードです。このモデルを分解し、コンポーネントから推定値を作成します。各値に値とエラー範囲（+/-）を割り当てます。
• モデルに基づいて推定値を計算します。
• 見積もりを追跡します。推定する問題、推定、および実際の値に関する情報を記録します。
• 見積もりに含める他のことは、要件または要件仕様の変更の開発と文書化、設計文書と仕様の作成または更新、テスト（ユニット、統合、および承認）、変更を伴うユーザーズマニュアルまたはREADMEの作成または更新です。2人以上が一緒に作業している場合、コミュニケーション（電話、メール、会議）およびソースコードのマージのオーバーヘッドがあります。時間がかかる場合は、配達日を選択する際に、他の仕事、休暇（休日、休暇、病欠）、会議、その他のオーバーヘッドタスクなどを考慮してください。

ソフトウェアの見積もりは、ソフトウェアエンジニアリングで最も難しい単一のタスクです。2番目の要件は要件の引き出しです。

それらを作成するための多くの戦術があり、それらはすべて最初に良い要件を取得することに基づいています。しかし、あなたの背中が壁にぶつかり、より良い詳細を提供することを拒否した場合、Fake It：

1. あなたが持っている要件をよく見てください。
2. 彼らが望むもののあなたの最良の推測に基づいてギャップを埋めるために仮定を行います
3. すべての仮定を書き留めてください
4. 彼らに座って、あなたの仮定を読んで同意させてください（または、運が良ければ、彼らに屈して実際の要件を与えてください）。
5. これで、詳細な要件を見積もることができます。

私の子供の頃、母が「急いで服を着る、またはあなたのために着る」と脅していたようなものです。

正確な推定値を求めることに非常に強い人のために開発を行いました。私たちが解決したのは非常にうまくいきましたが、これは次のとおりです。

• 見積もりに費やしたすべての時間に対して請求しました。私が請求した金額の約20-25％に達しました。
• 私はタスクを非常に詳細に調べました。腰からの射撃はありません。コードを調べて、どの行を変更する必要があるか、プログラムの他の部分がどのような影響を与えるか、物事が機能することを確認するためにどれだけのテストをする必要があるかを考えました。各ピースを.1時間（6分）の単位で見積もります。
• 詳細な内訳とともに、各タスクの見積もりを彼に送りました。

請求の20〜25％が多くのように聞こえます。

しかし、彼はXYZを変更するように頼み、約2時間かかると考えました。1時間の詳細な見積もりで、8.5時間かかると判断しました。それで、彼はそれが8.5時間の価値があるかどうかを決めました。そうでない場合、彼は私が見積もりなしでそれをやった場合、それが彼にかかったであろうものを7.5時間節約しました。

そして、彼が 8.5時間を投資したいと思った場合、私が見積もりの​​ためにした詳細な作業は、とにかくやらなければならなかった作業でした。

この方法を使用すると、ほとんどのタスクを予定どおり、または早期に、過大評価することなく取り込むことができました。時間が非常に細かく分割されていたため、スリップしているかどうかを早く知ることができました。3時間後に8.5時間のタスクに12時間がかかることを伝えることができるように障害物にぶつかった場合、時間が経つ前に彼に話をして、彼がコストを心配している場合に機能を再評価してヤンクできるようにしました。

彼はニッケルと薄暗いですか？いいえ、私は彼に彼が最も利益を見たところに彼のお金を適用させると見ました。そして、私はいつもひどいことになっていた推定の経験を得てうれしかったです。

私たちは、会議中に「ボールパークの見積もり」をしばしば求められます。そこでは、彼らが何をしたいのかについて非常に広くて膨大なアイデアが与えられます。「今日、1年と100万ドルの回答が必要な場合、詳細を確認し、それらを確認する時間が必要な場合は、これらの数値を調整できます。」といつも言います。

彼らはほとんど常にポイントを得ます。

見積もりの​​目的によって異なります。

ビジネスケースの初期の高レベルの見積もりの​​場合、重要なことは次のとおりです。

1. 速度。どの方法を使用する場合でも、迅速である必要があります。全体的なポイントは、利害関係者がプロジェクトを行う価値があるかどうかわからないということです。そのため、ビジネスケースの数値が必要です。ビジネスケースが堅実だった場合、見積もりは必要ありません。これらのプロジェクトの大部分は先に進まないので、見積もりを提供するためにあまりにも多くの労力を費やさないことが重要です。
2. 範囲を指定します。広くしてください。要件を分析し、利害関係者とワークショップを行い、仮定を検証する時間がありませんでした。幅広い範囲で、見積もりの​​受信者に「ソフトウェアプロジェクトは自然に複雑でリスクが高い-適切な見積もりが必要な場合は、詳細と時間を追加する必要があります」と伝えます。単一の数値または狭い範囲を与えることの問題は、実際の分析が行われる前に期待値を設定することにより、隅にあなたをペイントすることです。

同じように「感じる」同等のプロジェクトを選択するための最良の手法を見つけました。「感じ」は完全に主観的です-しかし、この種の見積もりでは、私の経験から、客観的な測定値が見つからないことがわかります。次に、広範囲を提供します。私は-50％から+ 100％の範囲が良いと言っている本をいくつか読みましたが、それは多くの要因に依存します。

詳細な低レベルの見積もり：

1. ベースラインが必要です。ベースラインが安定していない場合、推定値は無意味です。
2. ボトムアップが最適です。詳細な作業の内訳を取得し、各コンポーネントを見積もり、それをより大きな数にロールアップします。ここで、ポーカーのプランニングは素晴らしいテクニックであると思います。
3. ドキュメントの偶発性。偶発事態（存在する場合）が追加される場所を明確にします。各広告申込情報に追加されますか？または全体の見積もりに？それとも特定のリスクですか？または何もありませんか？
4. 仮定を述べてください。指定された時間枠でできるだけ多くを検証します。
5. 見積もりに含まれるものと除外されるものを明示的に記載してください。たとえば、レビューは含まれていますか？技術的な遅延は含まれていますか？

困難な方法を学んだ人からのダークサイドからのアドバイス。

要件は不明です。すべての影響を詳細に分析した人はいません。

この時点では推定を行わないでください。敵の数について何の手がかりもない戦いに勝つために何人の兵士が必要かを推定しません。見積もりはスカウト後に行われます。これは、すでにこの敵と戦った場合を除きます。

この新機能はおそらく、コード内で行ったいくつかの仮定を破り、リファクタリングする必要のあるすべてのことをすぐに考え始めるでしょう。

これは、他の人がこの分野に関する専門知識を持つことを期待しない限り、考慮に入れるあなたの責任です。

過去の課題から他にやることがあり、その他の作業を考慮に入れた見積もりを考え出す必要があります。

上記と同じように、あなたの隣のずさんなチームメイトがほぼ存在しないテスト手順で作成した予期しない作業であっても、事前に完全に予測できないというコードの不具合を引き起こします。天気予報です。

「完了」の定義はおそらく不明です。いつ実行されるのでしょうか。コーディングを終えたときのように「完了」、または「ユーザーが使用中」のように「完了」

ここでユーザーエンドの要件を理解し、ユーザーのように考えてください。ユーザーが許容できない可能性のある最低限のワークフローを備えた基本的な機能が「完了」とみなされるため、「完了」と推定される場合は、ピアが行うことを実行しないでください。ユーザーの観点から考えてみてください。これは、通常、見積もりを作成しているすべてのクライアントが理解できるからです。最低限の技術的要件ではなく、完全なユーザーエンド要件に向けて見積もります。そして、見積もりを求めるクライアントは、ここで彼らがどのように物事を表現し、あなたが言うことの技術的側面を理解するかについて完全に不正確になることを理解してください。

あなたがこれらすべてのことをどれほど意識していても、「プログラマーのプライド」によって、本来考えていたよりも短い時間が与えられたり受け入れられたりすることがあります。締め切りと経営陣の期待のプレッシャーを感じるときは特に。

これをしないでください！あなたは自発的な働き者であり、恐らく強制に容易に屈する人のように聞こえます。

ここでの問題は次のとおりです。あなたとジョーが同じタスクの時間を見積もったとしましょう（ただし、2人の従業員の間で、一度に両方の見積もりを知らない）。「1週間」と勇気を持って見積もります。週に100時間以上、無給の残業で働くと思います。今、あなたは3日遅れています。

一方、ジョーは5か月と見積もっています。あなたはこれはばかげていると思う、あなたはこれを一週間でやってのけることができると思う。ジョーはどのくらい働いていますか？週10時間？...ただし、彼はちょうど5か月で時間通りに終了します。

誰がジャッカスとして認識されると思いますか？そうです、あなた。ジョーは偉大な労働者のように見えますが、あなたは今信頼できないようです。Joeがかかった時間の約7％でさらに良い結果を達成できたかもしれないほど重要ではありません。重要なのは、1週間の見積もりから3日間の休みがあったことです。

厳密な見積もりの​​側で決して間違えないでください。緩い見積もりの​​側のエラー。あなたの会社で築く評判はありますが、それはあなたの見積りの長さを見積りの正確さにほぼ基づいているわけではありません。見積もりが長すぎて正確であるのは簡単です。問題に取り組み、より適切に解決するためにより多くの時間を得ることができます。推定値が短すぎると、呼吸の余地がまったくなくなり、必死に会うか、ねじ込まれます。

"二週間！"

真剣に。私の最初の見積もりは常に2週間です。なんか奇妙なメンタルブロックがあるので、すべてが2週間になるように思えます。

私はそれを回避し、何かがかかると思う時間を本当に考え、正確に推定するにはブラックボックスのように見える可能性のあるすべての潜在的なトラブルスポットとビットを特定しようとします。そして、私の答えが「2週間！」である場合、私はおそらくそうしなかったことを認識しようとします。

私が経験したほとんどすべての優秀なマネージャーは、「2週間！」応答として軽度の口頭ヒモを必要とする答えとして。

以前の見積もりがどれだけ正確になったかを記録する方法を説明するブログエントリがあり、次に誰かに「2週間になる」と言ったときに、以前の履歴を見て、その期間を確認できます。実際に「2週間になる」と言ったときに最後にかかった

私は自分で試したことはありませんが、見積もりがどれほど正確かを確認したいと思います。

それは組織と見積もりの​​使用方法に依存します。

推定がいつ準備ができるかについての一般的なアイデアを提供するだけである場合、私は一般に私の経験に基づいて迅速な推定を行うことができます。多くの場合、変更がシステムの他の領域にどのように影響するか、および必要な回帰テストの範囲とともに、不確実性または考えられる変動を推定値に含めます。

見積もりが契約上のもの、またはより正確なタイミングが必要なシナリオで使用される場合、私は完全な仕事の内訳を行います。これはより多くの作業であり、システムの設計と変更についてより深く考える必要がありますが、特に大きな作業の場合ははるかに正確です。

いずれの場合も、継続的なコミュニケーションが重要です。予期しない何かに遭遇した場合は、期限まで待つのではなく、その時に知らせてください。要件が明確でない場合は、要件と提供予定の機能に関する理解を文書化してください。これは、あなたが行うあらゆる仮定にも役立ちます。競合する優先順位に関しては、ある作業が別の作業にぶつかった場合、それがスケジュールにどのように影響するかを明確にしてください。

何の見積もり？小さなタスクまたは完全なソリューション。

後者はめったに行いませんが、ちょっと推測して、少し追加して、マネージャーに少し追加して、範囲に入れてください。

小さなタスク- ポーカーのプランニングは非常にうまくいくことがわかりました（完璧ではありません。1ptのタスクにはかなり時間がかかり、5ptのタスクには数分かかりましたが、最終的には均等になります）。

今日の知識に基づいて範囲を提示します。Cone of Uncertaintyを使用して、初期推定値の範囲を指定します。

毎週、残りの量を計算し、知っていることに基づいて再推定します。毎週どれだけの作業を行っているかのサンプルサイズが十分になったら、プロジェクトの進行に応じて（通常）常に狭まる日付範囲と残された作業量（できれば）縮小します。

自信を持って。見積もりをする際にプロ意識を身に着けないことで、クライアントとの最初の会議を何回失敗したかはわかりません。たとえあなたが薄い空気から数を吹き飛ばしているとしても-あなたは常に周りにいくらかの推定値を保つようにしてください。とはいえ、穴の中に自分を見積もらないように注意してください。異なるものを作るには、異なる量の時間、努力、リソースが必要です。これを行う良い方法は次のとおりです。

それら：いくらですか？

私：それはあなたが私に何をしてほしいかによる。一般に、私はこの種のプロジェクトを$ X前後から始めます。

ソフトウェアプロジェクトの見積もりについて話している場合は特に、見積もりがチームにとって大きな課題になることがあります。

ソフトウェア推定プロセスに関する経験と知識を共有し、4つの異なるタイプの推定を定義することを決定したら：

• 球場フィギュア
• サービス見積もり
• 特徴推定
• 成分推定

もちろん、これらのタイプは異なります。球場は、しばしば「推測」と呼ばれるものです。したがって、概算の数値または範囲であるため、コストの一般的な考え方が得られ、見込み客が議論をさらに進めるかどうかを判断するのに役立ちます。

原則として、クライアントはプロジェクトの開始時に概観図を必要とします。そして、私たちのアドバイスは次のとおりです。プロジェクトの議論と球場の数値の提供は、コンポーネントの見積もりを受け取るためのステップにすぎないはずです（柔軟性があり、開発プロセス全体でコンポーネントのタイプの見積もりを利用できます。機能、サービスなどを追加、削除、交換したい場合）。

誰もがソフトウェア開発の見積もりに伴うリスクを念頭に置く必要があります：過小評価、過大評価、壮大な失敗シナリオなど。

私たちのブログでもっと読むことができます！

http://blog.lemberg.co.uk/project-management/software-estimation-process/

この情報がお役に立てば幸いです！

私はいつも私が後で達成できないことに気づく推定値を与えることになります。それは何度も起こりました、そして、私はいつもそれが再び起こらないことを常に約束します。

見積もりではなく、コミットメントを求められているようです。これらは異なるものですが、コミットメントを確実に管理できれば、信頼性とキャリアに大いに役立ちます。

私の10年以上の経験に基づいたいくつかのアドバイス：

• 常に範囲（下限と上限）を指定します。これはあなたの不確実性のレベルを伝えます
• 不確実性が非常に大きい場合は、延期を依頼します（例：分析を行うために1日後、より狭い範囲を提供します）
• タスクが大きすぎる場合は、分割して各ピースの範囲を提供します

まず、タスクが私に割り当てられている場合、サブタスクに分割します各サブタスクの時間を推定し、おそらくサブタスクで問題のある領域を見つけることができるので、それがどれくらいの時間になるかを予測することができますある程度取ります。

しかし、それでもすべての計画はある程度しか役立ちません。コーディングを開始したときにのみ、正確な問題を見つけることができます

同じ上司またはクライアントに対して多数のプロジェクトを行う場合、数週間または数か月ではなく、おそらくTシャツのサイズで、複雑さの広いストロークで推定しようとすることができます。過去のいくつかのプロジェクトを特定し、それらにサイズS、M、L、XLを割り当てます。

そして、次のことを自問してください：どのプロジェクトが範囲内に似ていると思いますか？そして、「2か月」で答える代わりに、「私にはLのような音」で答えることができます（またはプロジェクトのキャリブレーションがどうであれ）。

これは非常に理解しやすく、またこれらの推測には多くの不確実性があることも明らかです。

次に、要件が変更されると、「その変更により、XLのように聞こえるようになります」と言うことができます。

少し遅れましたが、私が軍にいたとき、推定値を決定するためにPERTを使用するように指示されました。あなたの分野での経験と手元のタスクが必要です。電子機器（複雑な無線および衛星通信機器）の保守および修理の完了予定時刻を決定する際、驚くほど正確でした。他のユニットは、通信機器を返送するまで操作不能になる可能性があるため、推定は重要でした。私が使ったのはこの無料のオンラインPERT計算機です