Ashによって投稿された「<a href="https://stackoverflow.com/questions/549597/dealing-with-awful-estimates/553200#553200">ひどい見積もりに対処する」に答えながら、私が学んだいくつかのヒントを共有しました。弱い見積もりを見つけるために個人的に使用します。しかし、私はもっとたくさんあるに違いないと確信しています！
サードパーティ (同僚、ビジネス パートナー、または外部企業) によってまとめられたソフトウェア プロジェクトの見積もりを迅速に評価する必要がある場合、シナリオで使用するヒューリスティックは何ですか?
目の前のタスクに関する詳細な知識がなくても発見できる、弱いソフトウェア推定の明らかな兆候とそれほど明白ではない兆候は何ですか?
誰も言っていないので、そうします。明らかな答えは、ソフトウェア スケジュールの見積もりがある場合、それは非現実的な数値の確かな兆候であるということです。はい、ソフトウェアを見積もる方法はたくさんありますが、形や形を問わず正確な方法はありません。通常、締め切りが設定されます。タスクが過大評価されている場合、結果を改善するために余分な時間が費やされます。タスクが過小評価されている場合は、納品を満たすために何かが犠牲になります (テストや機能など)。
この答えは人々が信じたくないものであることはわかっていますが、見積もりは常に推測です。多くの場合、開発者は 1 日の終わりまでにどれだけの成果を上げられるかを予測することさえできません。何が実際に関係しているのかまだわからないことについて、彼らが何ヶ月も何年も先のことを推測することを期待しています。
あなたの質問に対する唯一の実用的な答えは、非現実的な結果をもたらす傾向がなく、あなたの会社での過去の履歴に基づいて推測できるワークシートを使用することです。残念ながら、それは推定器が見逃したタスクを考慮していません。少なくともこれは大まかな数字を与えるかもしれません。
まったく同じシステムの模造品を何度も開発しない限り、これを理解したと思っている人は、自分をだましていることになります。関連する変数が多すぎます。
見積もりには、タスクの見積もりとプロジェクトの見積もりの 2 種類があります。これらを大きな写真と小さな写真として見ることができます。
プロジェクトの見積もりは必然的に高レベル (粒度は通常、数日以上) であり、次のようなものを含める必要があります。
欠けているものが多いほど、見積もりは非現実的 (または危険) になります。
2 番目の種類のタスク見積もりで、通常ははるかに低いレベルです。この種の見積もりの場合は、単純にタスクの内訳にする必要があります (たとえば、5 日を超えるタスクはありません)。
これらは上記の項目に対処する傾向はありませんが、まだ行われていない決定に関する仮定 (製品ハードウェアなど) など、関連するものもあります。また、関連する経験、背景知識、またはスキルのためにタスクを実行できる人とできない人を特定することも価値がある場合があります (その人またはそれらの人が過度にコミットする可能性があるため)。
他の投稿では、テスト時間は開発時間と同じかそれを超える必要があると述べています。私はこれに強く反対します。私は、8 時間の開発タスクで 100 時間以上のテスト時間がかかり、80 時間の開発タスクで 2 時間未満のテストになることを見てきました。どちらの場合も、テスト時間はまったく妥当なものでした。両者の間に絶対的な相関関係はありません。せいぜい、接続が緩んでいるだけです。
うわー...ツールキットの答えが本当に好きです。
また、プロジェクトが見積もられたときに実際に見積もりを行うよりも、見積もりを行う人が問題を解決する方法の手がかりをはるかに多く持っていることを前提としているため、見積もりにはまったく欠陥があることに同意します。ただし、始める前に、少なくとも山のサイズを見積もる必要があると思います。やろうとする価値があるかどうかは、どんな努力よりも優先されるべきであり、それが見積もりの本質であるべきだと考える人もいました.
危険な見積もりの指標をさらにいくつか思いつきました。
良い経験則の 1 つは、テスト時間が開発時間とほぼ同じかどうかを確認することです。それは見積もりの良い兆候です。
彼らが見積もりの内訳をあなたに与えることができないなら、それは悪いことです. 通常、忘れられている可能性のある多くのささいなことの兆候. 完全な元の内訳を提供する必要はなく、次のような内訳のみを提供する必要があります。
標準テンプレートを使用して見積もりを計算する必要があります。すべての列に番号を入力する必要はありませんが、考えられるすべてのタスクを一覧表示するためにテンプレートを使用します。そうすれば、テンプレートを使用して、見積もりを作成するときに人々の心を揺さぶることができます。
見積もりが過度に正確である場合、たとえば 0.25 時間刻みの場合、それは私にとって悪臭です。
要件の取得、テスト、展開、運用グループへの引き継ぎなど、不足しているものがある場合は? それらのいずれかが欠けている場合、それは戻ってきてあなたを噛むようなものです.
編集:注意すべきもう 1 つのことは、古い「90% 完了」タスクです。進行状況の更新後に、タスクが「90% 完了」としてリストされ、進行状況が更新されます。それは良いことではありません！
HTH
乾杯
見積もりの編集者は利用可能であり、他の上級プロジェクトメンバーとそれについて話し合う用意がありますか？そうでない場合、それはしばしば懸念事項です。
開発スタッフの経験とスキルがわかる前に、見積もりが顧客に送信されましたか。2点推定が役立つ場合がありますが、ある程度しか役立ちません。
（ちなみに、私の質問に答えてくれてありがとう。）
私はダンクに完全に同意します。悪い見積もりの最初の兆候は、大規模で詳細な事前スケジュールの単なる存在です。見積もりはまさにそれであり、概算です。そうでない場合は、正確な模倣と呼びます。したがって、プロジェクトの管理に単独で使用しないでください。
考慮すべき最も重要な点は、見積もりの正確さではなく、一貫性です。サードパーティがあなたのために見積もりを行っていた場合は、彼らの成功または失敗の履歴を確認し、過去のクライアントと話し、彼らの信頼性を判断するように依頼します。
とはいえ、アジャイルの観点から、プロジェクト中に一貫性のある見積もりを取得しようとする方法のいくつかは次のとおりです。
これらの見積もり方法を使用している企業と取引している場合は、一貫性のある、したがってより良い結果が得られる可能性があります。
目の前のタスクに関する詳細な知識がなくても発見できる、弱いソフトウェア推定の明らかな兆候とそうでない兆候は何ですか?
目の前のタスクについてあまり詳細な知識がない状態で与えられる見積もりは、一般的には適切ではありません。
おそらく、一般的なアプローチは、要件の項目が見積もりの項目に対応していることを確認することです。相対サイズをすばやく確認したい場合は、100,000 語の要約に 100 語の見積もりが与えられている場合、それが正しい可能性はありません。
また、（他の人が言ったように）分析、コーディング、デバッグ、テスト、統合、不測の事態などが言及されていることを確認してください。そこに何らかの思いが込められていることを示しています。
さまざまな段階で成功と承認の基準があることは、優れた兆候です。少なくとも 10% 完了している定義済みのポイントがあれば、見積もりが間違っていても、早い段階でわかり、適応するチャンスがあります。「終了」までチェックポイントがなければ、その日が来るまで遅れていることに気付かないかもしれません。
3、6 、または 12 か月 (基本的に任意の概数) の形式の見積もりは、推測の悪臭を放ちます。通常、予想よりも大きなラウンド数を選択すると、四半期、半年など、通常の容疑者となります。私は、実際の開発イテレーション (サイズに関係なく) の観点から見積もることを好みます。
見積もりを出す人は、仕事をしている人とどのくらい親しみがありますか?
チームが非常に異なるバックグラウンドを持つ個人で構成されている場合でも、一般的な人が仕事をしているという見積もりをよく見てきました。ほとんどの場合、タスクと専門分野が完全に一致せず、GUI またはデータベースのいずれかを実行することになる C++ サーバーサイド プログラマーを取得します... 時々、チームのマネージャーはチーム メンバーの強みをあまり評価しないことがあります。彼のチームが前のプロジェクトで多忙なため、彼が自分で見積もりを出すように頼まれた場合、問題の仕事は実際にはチームの一部にしか適していないことがわかります (やる気がない、スキルが不足しているなど)。
見積もりを評価するもう1つの便利な方法は、同様の種類の以前のプロジェクトに費やされた実際の作業と比較することです。比較に最適なデータは、組織が行った以前のプロジェクトの作業データです。組織の履歴データがない場合は、業界全体のベンチマークに対して見積もりをベンチマークすることができます。
また、見積もりが単一の絶対数（たとえば、180日）として提示されている場合、それは良い兆候ではありません。単一の絶対数は、指定されたデータに対して100％の確率でタスクが終了するという見積もりを示します。範囲（たとえば、130〜180日）で提示された見積もりは、タスクを完了できる範囲を示します。
私が上で書いたことの多くは、それを本に帰するものです：
ソフトウェアの見積もり：スティーブマコネルによるブラックアートの謎を解き明かす
適切な見積もりには、プロジェクトのすべてのフェーズを含む、適切な内訳があります。
ほぼ確実に、ビジネスにとって都合の良い日に終了することはありません。
これには、さまざまな種類のリスクが含まれます。
暗黙的（10〜12か月）または大きな単位（約4分の4）を使用して、信頼区間の観点から提示されます。
それは、プロジェクトを遂行する責任のある誰か、できれば複数のそのような人によって作られます。
開始時に遅延がある場合は、終了時に遅延が発生します（開始から10〜12か月、または今開始する場合は2010年第1四半期頃、プロジェクトがまだ開始されていない2010年1月のようなものではありません）。
仮定と依存関係が明確かつ目立つようにリストされます。
編集：これの一部は、プロジェクトの段階によって異なります。特に信頼区間が割り当てられていない場合、早期の正確な見積もりは警告サインです。それはプロクラステスの見積もりの悪臭です。
また、他の開発方法論にも注意してください。タイムボックス化されたプロジェクトは、厳密で任意のスケジュールを持つことができますが、機能セットは柔軟になります。
「4 ～ 6 週間」、より短いタスクへの分割を伴わない場合...
人員に対して見積もりをチェックします。非常に正確なヒューリスティックではありませんが、大規模な作業に 1 人または 2 人の開発者が割り当てられている場合、そのタスクが正しく見積もられていないことは明らかです
次のいずれか: