見積もりを求められた場合の対応方法
プログラマーとして、私は常に「どれくらい時間がかかりますか」と尋ねられていますか？
そして、ご存知のように、状況はほとんど常に次のようなものです。
- 要件は不明確です。すべての影響について詳細な分析を行った人はいません。
- 新しい機能はおそらく、コードで行ったいくつかの前提を破り、リファクタリングする必要があるかもしれないすべてのことをすぐに考え始めます。
- あなたは過去の課題から他にやるべきことがあり、その他の仕事を考慮に入れた見積もりを考え出す必要があります。
- 「完了」の定義はおそらく不明確です。いつ完了するのでしょうか。コーディングを終えたばかりのように「完了」しますか、それとも「ユーザーが使用している」のように「完了」しますか？
- これらすべてのことをどれほど意識していても、「プログラマの誇り」によって、当初想定していたよりも短い時間で授受できる場合があります。特に、締め切りと経営陣の期待のプレッシャーを感じたとき。
これらの多くは、単純で解決しにくい組織的または文化的な問題ですが、結局のところ、見積もりを求められ、合理的な回答を求めているのが現実です。それはあなたの仕事の一部です。あなたは単純に言うことはできません：私は知りません。
その結果、私はいつでも自分が実現できないことに後で気づくような見積もりを出すことになります。それは何度も起こりました、そして私はいつもそれが再び起こらないと約束します。しかし、そうです。
見積もりを決定して提供するための個人的なプロセスは何ですか？どのようなテクニックが役に立ったと思いますか？
From The Pragmatic Programmer：From Journeyman to Master ：
見積もりを求められたときの発言
「折り返しご連絡いたします。」
プロセスを遅くし、このセクションで説明する手順を実行する時間を費やすと、ほとんどの場合、より良い結果が得られます。コーヒーマシンで与えられた見積もりは、コーヒーと同様に、あなたを悩ませます。
このセクションでは、著者は次のプロセスを推奨しています。
- 必要な精度を決定します。期間に基づいて、さまざまな精度で見積もりを見積もることができます。 「5〜6か月」と言うことは、「150日」と言うこととは異なります。 7か月目に少しずれても、それでもかなり正確です。しかし、180日目または210日目に入ると、それほど多くはありません。
- 何が求められているかを理解してください。問題の範囲を判別します。
- システムをモデル化します。モデルは、メンタルモデル、図、または既存のデータレコードの場合があります。このモデルを分解し、コンポーネントから推定値を作成します。各値に値とエラー範囲（+/-）を割り当てます。
- モデルに基づいて推定値を計算します。
- 見積もりを追跡します。推定している問題、推定値、および実際の値に関する情報を記録します。
- 見積もりに含めるその他の事柄は、要件または要件仕様の変更の開発と文書化、設計ドキュメントと仕様の作成または更新、テスト（ユニット、統合、および承認）、ユーザーマニュアルの作成または更新、および変更を伴うREADMEです。 2人以上が共同で作業している場合、コミュニケーション（電話、電子メール、会議）とソースコードのマージのオーバーヘッドがあります。長いタスクの場合は、他の仕事、休暇（休日、休暇、病気の時間）、会議、および配達日を選択する際のその他のオーバーヘッドタスクなどを考慮してください。
ソフトウェアの見積もりは、ソフトウェアエンジニアリングで最も難しい単一のタスクであり、2番目の要件は要件の抽出です。
それらを作成するための多くの戦術があり、すべては最初に適切な要件を取得することに基づいています。しかし、あなたの背中が壁にぶつかっていて、彼らがあなたにもっと詳細を与えることを拒否したとき、偽物：
- あなたが持っている要件をよく見てください。
- 彼らが望むもののあなたの最良の推測に基づいてギャップを埋めるための仮定を行います
- all仮定を書き留めます
- それらを座って読んで、あなたの仮定に同意します（または、運が良ければ、彼らに譲ってもらい、実際の要件を与えます）。
- これで、見積もり可能な詳細な要件が得られました。
子供の頃、私の母が脅迫していたようです。「急いで服を選んでください、または私があなたのためにそれらを選んであげます！」
私は、正確な見積もりを求めることを非常に強く求めていた人のために開発を行いました。私たちが解決したのは非常にうまくいったもので、これは次のとおりです。
- 見積もりに費やした時間はすべて請求されました。それは私が請求したものの約20-25％になりました。
- 非常に詳細な調査を行いました。腰からの撮影はありません。コードを調べて、どの行を変更する必要があるか、それがプログラムの他のどの部分に影響を与えるか、問題がまだ機能していることを確認するためにどれだけのテストを行う必要があるかを考えました。私は、0.1時間（6分）の単位で各部分を推定します。
- 各タスクの見積もりと詳細な内訳を彼に送りました。
課金の20-25％は、とてもよく聞こえます。
しかし、彼は私にXYZを変えるように頼みました、それは約2時間かかると思いました。 1時間の詳細な見積もりでは、8.5時間かかると判断します。それで、彼はそれが8.5時間の給料の価値があるかどうか決定しました。そうでなければ、私が見積もりなしでそれをしたとしたら、彼はそれが彼にかかったであろうものより7.5時間節約しました。
そして、もし彼がdid 8.5時間を投資したいのであれば、私が見積もりのために行った詳細な作業は、とにかくやらなければならなかったであろう作業でした。
この方法を使用すると、大幅に過大評価することなく、ほとんどのタスクを予定どおりに、または早期に実行できることがわかりました。時間が細かく分解されていたので、滑っていたのか早い段階でわかりました。 3時間後に8.5時間のタスクが12になることがわかるように障害物にぶつかった場合は、さらに時間が経過する前に彼に話しかけ、コストを心配している場合は機能を再評価してヤンクできるようにしました。 。
彼は無頓着でしたか？いいえ、私はそれを彼が彼に最も利益があると思ったところに彼のお金を適用させると見ました。そして、私はいつもひどいものだった見積もりの経験を得てうれしかった。
ミーティング中に、彼らが何をしたいのかについて非常に広くて価値のあるアイデアが与えられる会議中に、「概算」をしばしば求められます。私はいつも「今日の回答が必要な場合は1年で100万ドルです。もっと多くの詳細と時間をとって確認したい場合は、それらの数値を調整します。」
彼らはほとんど常にポイントを得ます。
見積もりの目的によって異なります。
ビジネスケースの初期の高レベルの見積もりの場合、重要な点は次のとおりです。
- 速度。どの方法を使用する場合でも、迅速である必要があります。要点は、プロジェクトを実施する価値があるかどうか関係者がわからないということです。そのため、ビジネスケースの数値が必要になります。ビジネスケースがしっかりしていれば、見積もりは必要ありません。これらのプロジェクトの大部分は先に進まないので、見積もりを提供するために過度の労力を費やさないことが重要です。
- 範囲を指定します。広くしてください。要件の分析、関係者とのワークショップ、仮定の検証を行う時間はありませんでした。 「ソフトウェアプロジェクトは当然複雑でリスクが高いため、適切な見積もりが必要な場合は、詳細と時間を増やす必要があります」と、広範囲に渡って見積もりを受け取ります。単一の数値または狭い範囲を与えることの問題は、実際の分析が行われる前に期待値を設定することによって、あなたを隅に追いやることです。
私は、同じように「感じる」同等のプロジェクトを選ぶための最良のテクニックを見つけます。 「フィール」は完全に主観的ですが、この種の見積もりでは、私の経験から、客観的な測定値が見つからないことがわかります。次に、広範囲を提供します。 -50％から+ 100％の範囲が良いと言っている本をいくつか読んだことがありますが、それは多くの要因に依存します。
詳細な低レベルの見積もりの場合：
- ベースラインが必要です。ベースラインが安定していない場合、推定値は無意味です。
- ボトムアップがベストです。詳細な作業の内訳を取得し、各コンポーネントを見積もり、それをより大きな数にロールアップします。ここでポーカーを計画することは素晴らしいテクニックだと思います。
- 不測の事態を文書化します。不測の事態（ある場合）が追加されている場所を明確にします。各広告申込情報に追加されますか？または全体の見積もりに？または特定のリスクに？または何もありませんか？
- 想定を述べる。指定された時間枠で可能な限り多くを検証します。
- 見積もりに含まれるものと除外されるものを明示します。たとえば、レビューは含まれていますか？技術的な遅延は含まれていますか？
難しい方法を学んだ人からのダークサイドからのいくつかのアドバイス。
要件は不明確です。すべての影響について詳細な分析を行った人はいません。
この時点では見積もりを行わないでください。敵の数についての手がかりがなく、戦闘に勝つために必要な兵士の数は推定しません。見積もりはスカウト後に行われます。これは、あなたがすでにこの敵と戦った場合を除いてです。
新しい機能はおそらく、コードで行ったいくつかの前提を破り、リファクタリングする必要があるかもしれないすべてのことをすぐに考え始めます。
これは、他の人がこの分野に関する専門知識を持っていることを期待しない限り、考慮に入れるあなたの責任です。
あなたは過去の課題から他にやるべきことがあり、その他の仕事を考慮に入れた見積もりを考え出す必要があります。
上記と同じですが、slobチームがあなたの隣に作成した予期しない作業でも、ほとんど存在しないテスト手順であなたの隣にいるため、コードを誤動作させて、完全に事前に予測することはできません。天気予報です。
「完了」の定義はおそらく不明確です。いつ完了するのでしょうか。コーディングを終えたばかりのように「完了」しますか、それとも「ユーザーが使用している」のように「完了」しますか？
ここでユーザーエンドの要件を理解し、ユーザーのように考えます。ユーザーが許容できないベアボーンワークフローの一部の基本機能が"done"と見なされるため、ピアが何かを "完了"と推定した場合は、ピアが行うことを行わないでください。ユーザーの観点から考えてください。これは、見積もりを作成するクライアントが通常理解するすべてのクライアントであるためです。ベアボーンの技術要件ではなく、完全なユーザーエンド要件に向けて見積もります。そして、見積もりを求めるクライアントは、言葉の言い方やあなたの言うことの技術的側面を理解することに関して、ここでは完全に不正確であることを理解してください。
これらすべてのことをどれほど意識していても、「プログラマの誇り」によって、当初想定していたよりも短い時間で授受できる場合があります。特に、締め切りと経営陣の期待のプレッシャーを感じたとき。
これを行わないでください！あなたは自発的なハードワーカーのように聞こえ、おそらく強制的に簡単に屈服する人のように聞こえます。
ここでの問題は次のとおりです。あなたとジョーが同じタスクの時間の見積もりを作成したとします（ただし、2人の別々の従業員の間で、両方の見積もりを一度に認識していません）。 "1週間"を大胆に見積もります。週100時間以上、無給の残業で働いても構いません。今、あなたは3日遅れています。
一方、ジョーは5ヶ月と推定しています。これはばかげていると思います。1週間でこれをやめることができると思います。 Joeはどのくらい機能しますか？週10時間？ ...彼が正確に5ヶ月で時間通りに終了することを除いて。
誰がジャッカスとして知覚されると思いますか？そうです、あなた。ジョーは素晴らしい労働者のようです、あなたは今信頼できないようです。それはそれほど重要ではないので、ジョーが費やした時間の約7％でさらに良い結果が得られたかもしれません。重要なのは、1週間の見積もりから3日ずれていたことです。
より厳しい見積もりの側に決して誤りません。より緩い見積もりの側のエラー。あなたの会社で築くべき評判があり、それはあなたの見積もりの長さに基づいてあなたの見積もりの正確さとほとんど同じではありません。見積もりが長すぎると、正確になるのは簡単です。問題に取り組む時間を増やし、それをよりよく解決するだけです。見積もりが短すぎると、呼吸の余地がまったくなくなり、必死にそれを満たすか、ねじ込まれます。
"二週間！"
真剣に。私の最初の見積もりは常に2週間です。なぜなら、2週間はすべてのように聞こえると思うような奇妙な精神的ブロックがあるからです。
私はそれを回避しようとします、本当にしようとします 思う どれくらいの時間がかかるかについて、正確に見積もるにはブラックボックスが多すぎるように見える潜在的な問題のスポットとビットをすべて特定しようとします。そして、私の答えが「2週間！」である場合、私はおそらくそうできなかったことを認識してみてください。
私が経験した優れたマネージャーのほとんどは、「2週間！」応答として穏やかな口頭のポン引きを要求する答えとして。
ブログエントリ には、以前の見積もりがどれだけ正確に記録されているかを記録する方法の概要が示されています。次に、誰かに「2週間になります」と言ったときに、過去の履歴を見て、最後に「2週間になる」と言ったときに実際にかかった時間を確認してください。
私自身は試していませんが、見積もりがどれほど正確かを確認したいと思います。
それは組織と見積もりの使用方法によって異なります。
見積もりが、いつ完成するかについての一般的なアイデアを提供するだけの場合は、通常、自分の経験に基づいて簡単な見積もりを行うことができます。多くの場合、変更がシステムの他の領域にどのように影響するか、および必要な回帰テストの範囲に加えて、推定値に不確実性または考えられる変動を含めます。
見積もりが契約に使用されている場合、またはより正確なタイミングが必要なシナリオで使用されている場合、私は完全な作業分解を行います。これはより多くの作業であり、システムの設計と変更についてより深く考える必要がありますが、特に大規模な作業の場合ははるかに正確です。
どちらの場合も、継続的なコミュニケーションが重要です。予期せぬ事態に遭遇した場合は、締め切りまで待つのではなく、そのときに知らせてください。要件が明確でない場合は、要件の理解と提供する予定の機能を文書化してください。これは、想定することにも役立ちます。そして、競合する優先順位については、1つの作業が別の作業にぶつかった場合、それがスケジュールにどのように影響するかを明確にします。
何のための見積もり？小さなタスクまたは完全なソリューション。
後者はめったに行いませんが、推測して少し追加し、マネージャーに少し追加して範囲内にします。その横に、上記は推測であると記載されています。
小さなタスク- Planning poker うまく機能していることがわかりました（完璧ではありません。1ポイントのタスクの方がはるかに長くかかったり、5ポイントのタスクの場合は数分かかったりしますが、結局すべてが均等になります）。
今日知っていることに基づいて範囲を提示します。 Cone of Uncertainty を使用して、初期推定値の範囲を提供します。
毎週、やるべきことの残りを計算し、あなたが知っていることに基づいて再見積もりします。毎週の作業量のサンプルサイズが十分になったら、プロジェクトの進行に伴って（通常）狭まる日付範囲と残りの作業量（うまくいけば）を与えるために、残っているものに90％の信頼区間を提供します。 ）縮小します。
自信あり。見積もりを出すときにプロ意識を持たないことで、クライアントとの最初のミーティングを何度失敗したかはわかりません。あなたが薄い空気から数を吹き飛ばしている場合でも-あなたは常に周りにいくつかの見積もりを保つようにしてください。とはいえ、自分を穴に入れないように注意してください。さまざまなものを組み合わせるには、さまざまな時間、労力、およびリソースが必要です。これを行うには良い方法があります：
それら：いくらかかりますか？
Me：それはあなたが私に何をしてほしいかに依存します。一般的に、私はこの種のプロジェクトをおよそ$ Xから始めます。
特にソフトウェアプロジェクトの見積もりについて話しているときは、見積もりがあなたとあなたのチームにとって非常に困難な場合があります。
ソフトウェア推定プロセスに関する私たちの経験と知識を共有し、4つの異なるタイプの推定 ：を定義すると、
- 球場図
- サービス見積もり
- 機能推定
- 成分推定
もちろん、これらのタイプは区別されます。Ballparkは「guesstimate」と呼ばれるものです。したがって、コストの一般的な考え方を提供するおおよその数または範囲であり、見込み客がさらに議論を進めるかどうかを判断するのに役立ちます。
原則として、クライアントはプロジェクトの最初に大まかな数字が必要です。そして、私たちのアドバイスは：プロジェクトの議論と野球場の数値の提供は、構成要素の見積もりを受け取るための良いステップでなければなりません（これは柔軟性があり、開発プロセス全体のコンポーネントタイプの見積もり。機能、サービスなどを追加、削除、または置換する場合、ゼロから再見積もりする必要はありません。
誰もがソフトウェア開発の見積もりに伴うリスクを覚えておく必要があります：過小評価、過大評価、総エピック失敗シナリオなど
あなたは私たちのブログでもっと読むことができます！
http://blog.lemberg.co.uk/project-management/software-estimation-process/
この情報がお役に立てば幸いです。
私はいつも、後で実現できないことに気づく見積もりを出すことになります。それは何度も起こりました、そして私はいつもそれが再び起こらないと約束します。
見積もりではなく、コミットメントを求められているようです。これらは異なるものですが、コミットメントを確実に管理できれば、それは本当にあなたの信頼とキャリアに役立ちます。
私の10年以上の経験に基づくいくつかのアドバイス：
- 常に範囲（つまり、下限と上限）を指定します。これはあなたの不確実性のレベルを伝えます
- 非常に大きな不確実性がある場合は、延期を依頼します（例：分析を行うために1日、その後、より狭い範囲を提供します）
- タスクが大きすぎる場合は、分割して、各ピースに範囲を指定します
最初に、いくつかのタスクが割り当てられた場合、それをサブタスクに分割します。各サブタスクの時間を推定します。おそらくサブタスクを使用すると、問題のある領域を見つけることができるので、それがどれだけ長く続くかを予測できます。ある程度取る。
しかし、それでもすべての計画はある程度までしか役に立ちません。コーディングを開始して初めて、正確な問題を見つけることができます
同じボスまたはクライアントに対して多くのプロジェクトを行う場合、おそらく数週間または数か月ではなく、Tシャツのサイズで、複雑な大まかなストロークで見積もることができます。いくつかの過去のプロジェクトを特定し、それらにサイズS、M、L、XLを割り当てます。
そして、自問してみてください：どのプロジェクトが範囲内で似ているように聞こえますか？そして、「2か月」と答える代わりに、「私にはLのような音」で答えることができます（または、プロジェクトの調整結果が何であれ）。
これは非常に理解しやすく、それらの推測には多くの不確実性があることも明らかです。
そして、要件が変更されると、「その変更によりXLのように聞こえるようになります」と言うことができます。
少し遅れましたが、私が軍にいたとき、PERTを使用して推定値を決定するように指示されました。それはあなたの分野でのある程度の経験と目の前の仕事を必要とします。電子機器（複雑なラジオや衛星通信機器）を保守および修理する際に予想される完了時間を決定するとき、それは驚くほど正確でした。他のユニットは通信機器を受け取るまで操作できない可能性があるため、推定は重要でした。私が使用したものはこれです 無料のオンラインPERT計算機