より良い推定を行う方法を学ぶには？
私は見積もりが下手です。誰かに何か時間がかかると私に尋ねられたとき、私は完全にマークから外れるので、私はあえて推測することすらしません。通常、私は楽観的すぎるので、おそらく私の推測にいくつかの大きなX係数を掛ける必要があります...
どのようにすれば、より良い見積もりを立てることができますか？それは私の大学で教えられていません、そして私たちにはすべての労働の締め切りがありますが、私は何かが実際にどれくらいかかるかについて決して考えません。どちらにするか。みんなのために（特に私のもの）。
私はまだ得意ではありませんが、タスクの見積もり時間と実際にかかる時間を追跡することは大きな助けになることがわかりました。そうすれば、自分が通常どれだけ離れているかをしっかりと把握できます。時間追跡機能付きの問題管理ソフトウェア（私の場合はJira）またはスプレッドシートがこれに大きく役立ちます。
何よりもそれは体験的なものだと思います。
マーフィーの時間管理の法則：何かwillがかかる時間を把握するには、それがshouldがかかる時間を把握し、2倍にします。
次に、1つ上の時間単位に移動します。したがって、1日のプロジェクトに2週間を割り当てます。
Steve McConnell（MS Press）によるソフトウェアの見積もりは良い読み物です。
ソフトウェア見積もりの主なものは次のように要約されます
履歴情報がないと、見積もりは役に立ちません。
これが、反復型プロジェクトが大規模な段階的滝プロジェクトよりもはるかに成功する理由の1つだと思います。彼らは一度に1年の計画を立てようとしているのではなく、ブラックボックスブードゥーのあるべき姿の情報以外はほとんど情報がありません。すべての反復で、それらは再推定/再計画を行っており、推定の基礎となる最後のいくつかの反復があります。
覚えておくべきその他のポイント：
- 遅いだけを取得します。 80/20ルールを適用するということは、プロジェクト管理がvery統制されていない限り、より困難な作業が後で行われることを意味します。
- 見積もり！=計画。見積もりは、何かを成し遂げるために必要な努力を把握するプロセスです。計画は、それをスケジュールに合わせるプロセスです。
- 60％の効率は、期待できるすべてのものです。 70％はユートピアです。日単位で見積もる場合は、これを組み込みます。時間単位で見積もる場合は、後で適用することを忘れないでください。
- ロングテール を思い出してください。推定値は、ある程度のリスクと未知数を調整するのに「おそらく」かかる時間の概算です。必要な実際の作業量が0未満になることはないため、ロングテールが関係します。私の元ボスは「すべての見積もりは+/- x％であり、決してマイナスになることはない」と述べています。
あなたはそれらをまとめてすることで学ぶことができます。
私はPlanning Pokerを使用しています。それは consensus-based を推定するための手法です。
見積もりを追跡し、効果的に行ったものと比較する必要があります。 Velocityを取得します。
何かを推定するたびに、最近の速度を掛けて正確な推定値を取得します。
Robert Martinの The Clean Coder に記述されているPERTスタイルの推定手法について誰も言及しなかったことに驚いています。その方法では、楽観的（O）、公称（N）、および悲観的（P）の3つのシナリオにかかる時間を見積もります。次に、予想される期間= (O+4N+P)/6であり、標準偏差は(P-O)/6。
これはかなりうまくいくようで、管理者が何かにどれくらい時間がかかるか本当に気にかけているときに、私はそれを数回使用しました。
他の人がコメントしたように、履歴データを調べて見積もりも出しました（「この同様のことを行うのにどれくらい時間がかかりましたか？」）。
しかし、私のお気に入りの方法は、時間の推定をまったく行わず、点の推定のみを行い、反復の速度を取得することです。チームが作業（ユーザーストーリー）のサイズ設定と完了にかなり一貫している場合は、それぞれにかかる時間を尋ねることすらしないことで、時間を大幅に節約できます。
時間の見積もりは非常に難しいため、物事を効果的に測定するのに十分な小さなチャンクに分解するには、多くの作業が必要です。そしてそれでも、変数が多すぎて病気、休暇、または気晴らしのようなものを説明するのを忘れているため、それらが正しいことはほとんどありません。
時間の見積もりを行う必要がある場合は、反復内の小さめのタスクに対してのみ行うようにします。私はそれが少なくなる可能性があることを知らない限り、すべてを半日の見積もり（4、8、12時間）で測定します。しかし、私はめったに1時間未満で何かを推定しません。
最初かつ最も重要なことは、プロセスを定義してそれに従う必要があることです。プロセスの各フェーズの最後に計画の改訂を含めます。プロセスを改訂することもできますが、整然とした方法で行います。
次に、何らかの設計を行います。設計は計画の最初のステップです。図面なしで家を建てることはありません。
3番目に、時間（努力）を追跡します。少なくとも区別する必要があります。
- 分析
- 設計
- コード
- 単体テスト（欠陥の修正を含む）
- 統合テスト（欠陥の修正を含む）
ユーザーによる受け入れテスト（欠陥の修正を含む）
テストの種類ごとに欠陥修正の労力を測定できればすばらしいと思いますが、複雑さが増すため、後で行うことができます。
4番目に、推定するための主要な基本項目を特定します。例：
- 自動化するプロセスの数（分析）
- ドメインモデルエンティティの数（設計）
- フォームとレポートの数（コード）
5番目に、基本アイテムと作業量を関連付けます。例：
- 分析工数= X工数/自動化プロセス
- 設計工数= Y工数/ドメインモデルエンティティ
- コードの工数= Z工数/フォーム（またはレポート）;フォームの数= A *ドメインモデルエンティティ
- ユニットテストの労力= M％*コードの労力
- 統合テストの労力= N％*コードの労力
- 受け入れテストの取り組み= P％*コードの取り組み
6番目に、パフォーマンスと各プロジェクトの推定値からの偏差を追跡します。したがって、相関係数を微調整できます。
7番目、繰り返して改善します。最初のプロジェクトの終わりに多くの洞察を得ます。推定。
http://en.wikipedia.org/wiki/Personal_Software_Process をご覧ください。実際に機能します。
上記のように最小のタスクに分割するプロセスを実行して、それぞれを計算し、その見積もりを2倍にするのが最も簡単だと思います。次に、それらを合計して50パーセント追加します。これにより、理想的な条件でのプロジェクトのおおよその時間を得ることができます。作業が実際に他の作業と並行して行われる場合は、さらに長く必要になります。他の人を待たなければならない場合は、2倍の時間がかかると予想してください。コンテンツやフィードバック、その他の情報を待つことは、多くの場合、考えられるよりもはるかに長くかかります。
私が作業する場所では、プロセスの各ステップのベストケース/予想されるケース/最悪のケースの見積もりを算出します。これは、ガイドとして、また見積もりがどのように機能したかを評価するためにも役立ちます。
プログラマーのタスクを過小評価する誘惑と闘うことができる必要があることを除いて、このテクニックはそれほど重要ではありませんが、重要なことは、何かを提供できるときについて保守的であることです。何かを構築するのに7週間かかり、8週間を約束した場合、少し早く来て、見栄えをよくするか、追加のテストを行って、信頼性を保証できます。 6週間を約束した場合、それは完全にあなたのせいではありませんが、悪く見えることがあります。疑わしい場合は、控えめに推測してください。
見積もりの問題が発生した場合は、それらをより小さな部分に分割するようにしてください。次に、それらに類似したものをすでに実行しているかどうかを確認します。あなたが持っている場合、あなたはすでに各ピースがどれくらいの時間を要するかについての公正な考えを持っているはずです。そうでない場合は、さまざまな種類のタスクにかかった時間を積極的に追跡し始める必要があります。これは、将来の見積もりに役立ちます。
統合とテストにはある程度の時間が必要なので、必要な合計時間は個々の部分の合計よりも長くなります。
同様のことをまだ行っていない場合は、おそらく他の人の経験に頼って、それらから見積もりを得ることができます。ただし、これを額面どおりに受け取らないでください。経験が好きなことを教えてくれるものはありません。
ターゲットを撃つようなものです。推定時の以前のショットは、あなたがどのようにマークから外れているのかを教えてくれるので、それを修正することができます。
私のために働くときに働く式：
todoを1〜4時間の粒度に分解します。私は通常これらで正確だと思います
「未知数係数」：未知数の数に2を掛けた係数を掛けます。つまりcouchdbアプリケーションを開発する予定であるが、javascriptとhttpについて何でも知っている場合は、マルチ係数として2 ^ 2を追加します。
context-switch-factor：完璧な環境（自宅で勉強コーナーなど）で作業する場合は1.5倍、不完全な環境（オフィス/混雑した場所など）で作業する場合は2.5
これは実際にかかった時間の+/- 20％以内であることがわかりました!!
それについて本を書くのではなく、見積もりの「分解」方法の使用方法について少しアドバイスを提供します。
割り当てを小さなコンポーネントタスクに分割します。各タスクを可能な限り最適に見積もります。
計画と設計のタスクを追加します（これには、現在実行している作業が含まれます）。見積もりを行います。
まだ持っていない場合は、「タスクを1つにまとめる」ためのタスクを追加します。このタスクは、最初は役に立ちません。ただし、この「内訳」の推定方法を使用する場合、「タスク間のフォール」と「タスクをまとめる」には常に時間がかかります。これは推定が難しい場合があります。あなたのベストを尽くす。
テストとドキュメント化のためのタスクを追加します。割り当てには多くのテストとドキュメントが必要ない場合がありますが、少なくとも少し時間をかけてそれについて考える必要があります。
タスクの見積もりを合計して、全体的な見積もりを取得します。
先に進んで、その合計見積もりに2を掛けます††。これはあなたにパディング時間を与えます：
- 元のタスクリストで見落としたものを仕上げる
- 始めるまで知らなかった事を終える
- 他の人からのフィードバックを組み込み、変更を加える
- 会議など、あなたの周りで起こっている他のことに邪魔される
- 予測よりも前に終了するよりも頻繁に終了する
そして最後に、重要なことですが、恐らく完全に間違っている自分の見積もりをスケッチすることを恐れないでください。場合によっては、どれほど極端に不正確である可能性があっても、すべてをスケッチするだけで、何が関係しているかをより理解するための道のりを始めるのに役立ちます。
††ますます経験を積むにつれて、この「ファッジファクター」は、個人のスタイルや作業環境に合わせて調整できます。
リストで繰り返される特定の事柄にどのような乗数があるかを知るのに十分なレコードを構築するために、さまざまなタスクの見積もりと実際の実績の実績を構築することもできます。これは試行錯誤によるものですが、私には問題なく機能しているようです。また、パターンが明らかになる前に、多くの試験で言われるべきこともあります。これは他の多くの答えと似ていると思われます。私たちのほとんどがスキルを開発した方法です。見積もりをするときにどれほど間違っているかを見るのは大きな痛みですか？はい、しかし見積もりが良くなれば、最終的に誰もが幸せになることができます。
プロジェクトをより小さなタスクに分解し、それらの推定を行うことができれば、全体としてより正確になります。数日を超えるタスクはさらに分解する必要があります。あなたがおそらく要件のギャップを持っているよりもそれをさらに分解することができない場合。 1行の要件に対してナプキンの裏返しの見積もりをうまく行う必要がある場合、何も実際に役立つことはありません。悲しいことに、多くの店がほとんどの場合この方法で働いています。
あなた自身のバイアスを学びなさい。最後の見積もりが2倍に低すぎた場合は、次に、最初の見積もりを2倍にします。 （もちろん、ホフスタッターの法則により、正しく実行することは困難です...）
また、前の作品の最初のリリース後にどれだけの作業が必要であったかを思い出し、それを次の見積もりに追加することも常に良い考えです。例えば。最後のタスクが完了するまでに2か月かかりましたが、稼働後、サポート、修正プログラム、および追加の変更によりさらに1か月かかるため、次回は同様のタスクで3か月を見積もります。
オープナーについては、Barry Boehmによる「ソフトウェアエンジニアリングの経済学」とTom DeMarcoによる「ソフトウェアプロジェクトの制御」を読んでください。これら2つを読んで消化したら、Barry Boehmによる「COCOMO 2によるソフトウェアコストの見積もり」を読んでください。
次に私が言わなければならないことについては、LOTが確率と統計のクラス、基本的なクックブックのクラスでさえも取るのに役立ちます。
見積もりは完璧ではありません。早く来る確率と遅れる確率があります。 Boehmの最初の詳細なCOCOMOモデルは、実際の結果の30％以内、つまり60％の時間よりも良い予測を与えました。それは彼が本を書いて出版したときの一般的なものよりもはるかに優れていました。
最良の推測をすると（そしてそれがすべての見積もりです）、それらの確率が含まれます。見積もりを引き込むと、遅れて来る可能性が高まります。見積もりを増やすと、早い時間に到着するか、時間どおりに終了する可能性が高くなります。どれだけ引き込むか、または引き出すかによって、確率がどのように変化するかが制御され、必然的に、早いか遅いかのペナルティに依存する必要があります。 （ここにホラーストーリーを挿入してください。何年にもわたってホラーストーリーがたくさんあります。）
DeMarcoはこれにある程度対処しています。彼はまた、「不可能領域」があることを指摘します。どのような英雄的行動が試みられようとも、いくつかのスケジュールは、あまりにタイトで作成することができない。