ソフトウェアスケジュールの見積もりが難しいのはなぜですか。
重複の可能性：
ソフトウェアスケジュールの定義が難しいのはなぜですか？
ソフトウェアの見積もりがなぜ難しいのか、そして私たちの予備的な見積もりがしばしばはるかに遠いのはなぜ上級管理者に説明する必要があるのですか。橋を架けるような数学的に正確な工学ではない理由を知りたいと思う人もいるでしょう。
この件に関連するいくつかの点をリストすることで私を助けることができます。どうもありがとう！
ソフトウェアの見積もりは、他のタイプの作業の見積もりよりも実際には難しくありません。それが推定されている条件がより難しいので、それはちょうどそうです。たとえば、ソフトウェア会社が自動車会社に課せられたものと同様の仕事を課されたとしましょう。同じものを何十年もの間存在していて、マイナーなバリエーションのみで何度も何度も構築します。さらに、プロジェクトの最初から完全かつ詳細な仕様から作業し、開発が始まるとフリーズします。このような状況では、ソフトウェアの見積もりは簡単です。
私はSOのどこかからこの答えを盗んでいます。元の作者を見つけることができないようですが、答えは私に付きまとっていました。
先のとがった髪のマネージャー：これにはどのくらい時間がかかりますか？
従業員：一ヶ月とは言い難いですか？たぶん1ヶ月半？
PHM：より正確な見積もりが必要です
E：ほら、車で通勤するにはどのくらいかかりますか？
PHM：えっ？なぜ30分？
E： 30分プラスまたはマイナス何ですか？
PHM： +-トラフィックに応じて5分
E：したがって、1つの境界のある未知の変数を使用して以前に何百回も実行したタスクを17％以内に見積もることができます。タスクにかかる時間を見積もると、 [certified-professional/contractor/whatever-qualification-you-have]を雇う必要があるので、これまでにないことを行うには複雑で、千未知数の20％を超えると、あなたはそれで十分ではないと言います！？
PMH：ああ...
プロジェクトの最後の20％は通常80％の時間がかかるからです。最初の概要はおそらく、プロジェクトの詳細を理解せずに、コアメカニクスに基づいて合計時間を基準にしていることが多いためです。私の意見では、これはプログラミングの問題ではなく、心理的な問題の問題です。あなたは人にヘリコプターまたはロックがどのように機能するかを尋ね、彼らはおそらく1つまたは2つの主要な機能を細かい機構の大部分を省いていると考えます。プログラミングも同様です。プログラマーが何か新しいことをしている可能性が高いため、システムを正確に理解していない可能性が高いため、システムを機能させるコアコンポーネントのみが連携します。
また、プログラミングでは最初の段階で何かが動作することはめったになく、デバッグには長い時間がかかり、遭遇する問題を知ることはほとんどありません（またはそれらに遭遇しないでしょう：P）。
役立つリンク： http://www.apa.org/monitor/feb03/overestimate.aspx
これもあります： http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect しかし、プログラミングはかなりクリエイティブなタスクであるため、完全に同意しません
編集：心理学のこの研究がかなり面白くて新しい側面であるのと同じように、それは私たちの文化全体（西洋）が未来の視点から自分自身を見て、私たちの能力を過大評価する傾向があるモチベーションとうつ病に大きく関係しています、（米国は教育水準がかなり低いと評価されていますが、信頼性が最も高いと評価されているため、パフォーマンスが低いにもかかわらず、驚くほどパフォーマンスが高いと考えています）。 「社会主義がアメリカに根付いたのは、貧困層が搾取されたプロレタリアートではなく、一時的に困惑した億万長者であると考えているためです。」ジョン・スタインベック。とにかく、接線については申し訳ありませんが、この視点では、異なる文化（東と西）間で時間の見積もりに差異が生じる可能性があります。
推定する潜在的に無限の変数があり、ユーザーが何を望んでいるのか本当にわからない（または正確に何を望んでいるかを表現できない）ユーザーがいるからです。
「私のために車を設計してください」。あなたは車をデザインしますが、彼らは本当にトラックを意味しました。まあ、それは車輪を持っています、そうです...
見積もりを行う場合、最初の見積もりを25％以内に、2番目の見積もりを詳細設計後に10％以内に収めようとします。
私たちはそれを要件からの見積もりとさえ呼んでいません...私たちはそれをスワッグと呼んでいます（ばかげた野生の推測）。
実行するには、歩かないで ソフトウェア推定：黒のアートの謎を解く スティーブマッコネル。最初のいくつかの章はあなたが尋ねている正確な質問への答えでいっぱいです。
他に何も考え出せない場合は、ほとんどの組織で見積もりの定義がになる可能性がゼロではない最も楽観的な予測であるというTom DeMarcoの観察を認めてください。正しい。これの最大の推進力の1つは、聞きたいことを人々に伝えたいという欲求です。さらに、多くのマネージャーは、動機としてスケジュールを使用しようとします。 （これは逆の効果がありますが、マネージャーが試行するのを妨げるものではありません。）
プレゼンテーションに関して、マネージャーに理解してもらうことを目指すべき重要な教訓は次のとおりです。
- 正確な見積もりを作成するには、次のことを行う必要があります
- プロジェクトを、ほんの数時間の必要なすべてのタスクに分割します。それよりも大きなタスクは正確に見積もることができません。
- 人の病気などによる避けられない遅延のオーバーヘッドを見積もりに組み込みます。
- 組織の見積もりと現実がどのように相関して、これらの見積もりを修正したかに関する過去のデータを入手してください。
- 機能のリクエストは以前の見積もりを無効にすることを受け入れます。
- プロジェクトが大きくなると、見落としが生じやすくなるため、見積もりが悪化します。通常、見積もりは100％以上ずれています。
- 組織的な経験がないタイプのプロジェクトは、起こりそうな落とし穴が何であるかわからないため、見積もりが困難です。
- 見積もりには、いくつかの可能な目的があります。見積もりを何に使用しているかを明確にする必要があります。主な可能性は次のとおりです。
- 特定の機能が実行される可能性が高い時期を把握する。
- 特定の日付に何かを表示することを目指しています（たとえば、会議でそれを発表できるようにします）。
- 開発者が一生懸命働くよう動機付けるツールとして。 （推定値はこのように頻繁に使用され、これは通常逆効果です。）
- 実行中のプロジェクトの正確な見積もりを取得することは悪名高いほど困難です。ほとんどの組織では、プロジェクトが軌道に乗っていないというニュースは、オーバーランの期間に関係なく、期日の約2週間前に届きます。なぜ？
- 人々は知っている限り、常に現実に最も楽観的なスピンを与えたいと思っています。
- 人々は常に最も楽観的な方法で自分の話を聞きたいと思っています。
- いくつかの層の後、現実と伝達されているものとの間に完全な分離があります。どのようにShit Happensは、この切断がどのくらいの速さで発生するかを示す、楽しくて驚くほど現実的なデモです。
- 誰もスケジュールが守られないという悪い知らせを我慢したくない。これにより、拒否が機能しなくなるまで、集団的拒否の状態になります。
- 追跡プロジェクトを改善するためにできることがある。
- 可能な限り、1つの大きなプロジェクトではなく、複数の小さなプロジェクトを実行してください。小さなプロジェクトは本質的に追跡が容易です。
- 明確で明確な定義を使用して、「100％完了」のマイルストーンを設定します。すべきでないことの例は、「90％コーディングが完了していること」です。中途半端なときに90％完了していると人々はよく思っています。何をすべきかの例は、「モジュールXは作成され、そのユニットテストに合格しています」です。
- 反復的な開発プロセスを使用します。各反復には、具体的で測定可能な成果物が必要です。イテレーションが終了したら、所要時間を最初の計画と比較し、それに応じて調整します。推定と測定の間の不一致は比例すると仮定します。したがって、3回の反復に6週間と8週間かかると想定されている場合、「追いつく」ことができると想定しないでください。代わりに、最初の見積もりよりも1/3多い時間で最終プロジェクトを完了する予定であることをすぐに通知します。
- プロジェクトに対する「トップリスク」のリストを常に更新し、積極的にそれらに対処します。これにより、後のプロセスで盲目的な状態になる可能性が低くなります。
問題は、顧客が何を望んでいるのかを知らないことです。彼らは漠然とした考えしか持っていません。
ただし、見つけるには、ソフトウェアの構築を開始する必要があります。その後、ソフトウェアを変更します。
あなたがソフトウェア開発のようにしたいのはAnalysis > Design > Implementation。
これは、たとえば、建設がどのように機能するかです。 60階建ての建物をボックスではなく円柱にすることを半分だけ決めることができないので、だれも「ああ、構築を開始して、建設の進捗に応じてフィードバックを提供します」とあえて言いません。 。
したがって、ソフトウェア開発はAnalysis > Design > Implementation > Evaluation > Redesign > Reimplementation > Evaluation > ...。どこに行くのかわからない場合は、いつそこに行くかを言うのは難しいでしょう。
橋の建設はそれほど正確ではありません。実際、彼らは通常予算も超過しているに違いない。私は計画されたトンネルb/w NJとNYがつい最近キャンセルされたb/cのオーバーランを知っています。そして、最近作成されたすべての（アメリカン）フットボールスタジアムについて考えてみましょう。これらの例のいくつかを手に取り、実際に目に見えるものを構築すること、そして私たちが目にすることができる他のものと非常に似ているものを構築することは依然として危険であるということを理解してください。それが本当に似ていない場合、さらに見ることができないものはどれくらいですか？
Construxは、この現象について The Cone of Uncertainty と呼ぶ非常に良い説明をしています。基本的にビジネス上の問題は、大規模なプロジェクトの結果を知ることができるよりも、プロセスの早い段階で見積もりおよび多くの場合コミットメントを行わなければならないことです。これに対処するのに役立つさまざまな手法があります。そのため、リスクをより効果的に管理するために、業界はより短い反復でより小さな成果物（別名「アジャイル」）に移行しています。
他のプロジェクトの見積もりには適用されないことが多い、ソフトウェアの見積もりに適用されるいくつかの要因があります。
- カスタム（新しい）要件。
- 要件の変更。
- プロジェクトの範囲が不明確。
- 新しいツールとテクニック。
- 一貫した方法論の欠如。
- 熟練したリソースを専門知識以外の領域に交換する。
- 個人による生産性のばらつきが大きい。
- 必要なツールなしでプロジェクトを開始します。
ほとんどのプロジェクトにはある程度のこれらの要因がありますが、ソフトウェアプロジェクトには多くの場合、これらの要因の多くが高度に含まれています。
ほとんどの組織では、カスタムの作業を行うためにより多くの時間が必要です。カスタム要件を簡単に処理できるものでも、限られた範囲内でカスタマイズを制限できます。許容範囲外のカスタマイズを行うと、カスタマイズに必要な時間が大幅に増加します。
要件の変更には、やり直しが必要です。場合によっては、すでに完了した作業を元に戻す必要があります。建設のさまざまなポイントで家の部屋を再配置するコストを考慮してください。
プロジェクトの範囲が不明確または変化している可能性があります。スコープを変更すると、コストが大幅に変わります。トラックのコストを見積もるように頼んだら、2万から3万ドルを提案するかもしれません。セミトラックとトレーラーが欲しい場合、見積もりはどうなりますか。
ソフトウェアツール、言語、および技術は依然として急速に進化しています。開発チームは、進むにつれて学ぶ必要があるでしょう。この学習曲線により、作業の速度が変わります。一部の見積もりでは、十分に熟練するまでに10,000時間かかることが示唆されています。 Pythonの見積もりは、完全に熟練するまでに数か月かかることを示唆しています。
多くのプロジェクトでは、方法論の方法がほとんどありません。これが方法論であっても、十分に実装または変更されていない可能性があります。その結果、チームは継続的に物事のやり方を学んでいる可能性があります。これにより、パフォーマンスが低下します。最近のレポートでは、方法論を使用すると生産性が向上することが示されています。
ソフトウェア開発者は互換性のないスキルセットを持っています。多くの組織は、ある開発者は別の開発者と同じであると考えています。開発者を互換性のあるものとして扱うと、開発者はスキルセット外のタスクに取り組み、結果としてパフォーマンスの変動が生じます。あなたが持っているすべてが配管工と電気技師であるならば、家を建てることへの影響を考慮してください。
プログラマの生産性に関する調査によると、一部のプログラマは他のプログラマの26倍もの生産性を発揮する可能性があります。このレベルの生産性のばらつきは、見積もりに大きな影響を与える可能性があります。
多くのプロジェクトは、いくつかの基本的なツールを必要とせずに始まります。多くの場合、プロジェクトを開始するには、ハードウェアとソフトウェアの両方が必要です。これらのツールの選択と設定には、プロジェクトチームにはないスキルが必要になる場合があります。標準的なツールセットとプロジェクトセットアッププロセスを備えた組織では、推定値のばらつきが少なくなる可能性があります。
これは、ソフトウェアの推定がどのように機能するかについてのいくつかの仮定に欠陥があるためです。たとえば、ソフトウェアをタスクに分解してからタスクを推定すると、合計を合計でき、プロジェクトの推定値があるという仮定です。この仮定には2つの大きな問題があります。
最初の目立つものは、すべてのタスクが前もって知られているということです、それは明らかに偽りです。すべてのタスクを事前に知ることができるとあなたに言った人は誰もが嘘をついています。
これに対応できるとしましょう。たとえば、既知のある種のストーリーメトリックを使用して見積もりを拡張するとします。今、私たちは別の誤りに直面しています。これは、すべてのストーリーの見積もりが最終的には均等になるという仮定です。不足していたのとほぼ同じ量が、同様の量で取得されます。しかし、それは通常起こることではありません。
まず、多くの場合、 パーキンソンの法則 が有効になります。 2番目に、パーキンソンの法則に対抗するために、ポイントまたはその他の漠然とした非日数の見積もりを推定したとしてもです。見積もりを下す方法はたくさんあります。しかし、あなたがやって来る方法にほとんど制限はありません。
このように考えてください。毎日の通勤に30分かかるとします。すべてのライトに当たるか、トランジットラインがちょうど上を向いたら、通勤から5分か10分かげれるかもしれません。ただし、事故が発生した場合、またはバスが故障した場合、通勤時間は平均の2倍または3倍になります。
ソフトウェアのスケジュールは難しいですが、不可能ではありません。要件を理解し、システム全体を小さな部分に分割するのに十分な時間を与えれば、スケジュールを完了することができます。
スケジュールを非現実的なものにするのは、通常、次の原因によるものです。
- 要件は確認されていません
- 特定の技術的障壁が十分に研究されていない
- 同様のプロジェクトタイプでの経験不足
この問題を克服するために、プロジェクト管理者は次のことを行う必要があります。
- 要件が最終的なものであることを確認するか、少なくとも変更を理解するために上級管理者に追加コスト（時間/リソース）が発生するようにします
- ソフトウェアの複雑さを予測することが技術的に可能
- 完全なスコープと小さなパーツの両方が完全に調査されるまで、推測せずに分解してください
橋梁建設プロジェクトの入札を読んだことがあれば、ソフトウェアの見積もりが（通常）非常に非現実的である理由がわかります。
過去を見ることで未来を予測します。したがって、見積もりには2つの主な問題があると思います。
- これまでにやったことのないことをするように求められた場合、それまでに行ったことがないので、どれくらいの時間がかかるかわかりません。
- 何かにかかった時間を記録しておかないと、同じようなことをもう一度行うように求められた場合でも、推定するためのデータがありません。
- 機能リクエストを実装するために実行する必要があるすべてのタスクの正確なリストを作成して維持することは困難です。
人々があなたに何をするように求めるかを制御することはできませんが、あなたが彼らの要求にどのように応答するかを制御することができます。
正直で明確なコミュニケーションは本当に重要です。それは難しいことですが、特に誰かが正確な数値を求めている場合は、あなたが信じている見積もりに固執する必要があります。そのため、誰かから非常にあいまいな要求が与えられた場合（たとえば、「パンフレットウェアのWebサイトが必要な場合、おおよそどのくらい時間がかかりますか？」 ）、実際の過去のプロジェクトに基づいて、広い範囲で見積もりを出します—例「設計の複雑さとサイズに応じて、5〜25人日。」
Steve McConnellによる「迅速な開発」 は、これに関して非常に優れています。
ある程度の経験があれば、ソフトウェアスケジュールの見積もりはそれほど難しくなく、以前に行ったことに似ていると思われるタスクに基づいて最良の推測を行うことができます。それで、（私が示唆しているように）プロジェクトのスケジュールを見積もることが難しくないのに、なぜseemそれほど難しいのですか？
まず、質問の2番目の部分に答えることから始めます。ソフトウェアをブリッジビルディングのようなものにしないのはなぜですか？それは、各利害関係者によるインプットのレベルと、ソフトウェアがプロジェクトの途中で簡単に変更できるという関係者全員の認識によるものです。橋の設計を変更すると、重要な材料費と、さまざまなスキルセットを持つ多くの個人を組織化する際に生じるスケジュールの混乱を考慮する必要があります。すべてのソフトウェア開発者は同じように熟練していることを意図しているため、比較するとソフトウェアの方が簡単であるように思われます。通常、克服できない材料やスケジュールの方法は多くありません（IE：遅延は比較的安価です）遅延建設プロジェクトと比較して）。しかし、実際には、ソフトウェアはすべて人を扱い、人の問題の解決策を作成することです。プロジェクトが非常に人に焦点を当てている場合、プロジェクトの精度は低下し、人と人の間で発生する問題の影響が大きくなります。
それはいくつかの要因に起因すると私は信じています、そして現在私の頭に浮かぶ最も明白なものは以下の通りです：
開発者は問題の領域を完全には理解していません。
「自分の心を知らない」ことで顧客を必要なだけ責めることができますが、根本的な問題は、顧客が一般的に、そして真に彼らが何であるかを言葉で説明できないことです[〜＃〜]必要[〜＃〜]。必要とすることは2つの非常に異なるものであり、顧客が最初にwantsと述べていることに単に応答するのではなく、顧客のニーズを引き出すのは熟練した開発者次第です。顧客と母国語で話すことができ、顧客が実際に必要とするものを明確にすると、問題の領域を完全に理解していると主張できます。
さまざまなレベルの経験を持つチームメンバーからの限られた入力。
事実に直面しよう。他の誰かの推定に動かされても、だれもうまくいきません。すべての開発者の経験はいくぶんユニークであるか、少なくとも異なっており、それぞれが異なる個人的な経験からの特定のタスクを表示します。プロジェクト全体を見積もる人が1人だけの場合、実際には見積もりの約25-40％しか正確に得られません。また、経験のない、または誤解されて最終的には難しい困難なことになります。ほとんどの遅延を引き起こしています。最大の遅延は、単一の推定者が比較的些細であると考えたものから生じるとおばさんに賭けることができます。ここでグループの推定が非常に重要になります。あなたはプロジェクトに実際に取り組むすべての人々にすべての見積もりを提供し（計画ポーカーセッションは実際にここで役立ちます）、基本的にこのプロセスを使用して、将来のスケジュールの失敗に対する賭けを効果的にヘッジします。
開発者はソフトウェア開発方法を調整していません
過去20年間、ソフトウェア開発方法論について多くのことが書かれてきました。私はすべてを読んだと主張することはできませんが、私はそこにいるほとんどの経験豊富な人々が少しすべてをサンプリングしたと主張し、それの多くを試したことが好きになることができます。アジャイルであることについて私が非常に熱心になっている理由の1つは、プロセスの調整に重点を置いていることと、プラクティスの適用方法と考え方の両方に適応できることです。場合によっては、顧客のニーズに合わせてメソッドを調整する必要がありますが、多くの場合、最も優れたメソッドの調整はチーム自体で行う必要があります。新しいチームメンバーが参加するときはいつでも、それはプロセスを微調整する機会であり、チームが固まらないときは、さらに調整する必要があります。ほとんどの重大な障害は、チームが1つの単位として効果的に機能せず、メソッドが特定のチームの固有の状況を説明できない（またはできない）ために発生します。個人的な問題から、オフィスの政治、疲労、経験まで、すべてが影響を及ぼしますが、プロセスがチームにとって意味がない場合、プロセスが刺激を受けていない場合、またはチームが感じていない場合彼らの努力によって制御されたり権限が与えられたりすると、チームは失敗し、チームはプロジェクトに失敗することになります。チームメンバーが管理しやすい小さなステージで良い結果を達成しているように感じ、チームメンバーが努力自体でやりがいを感じるのを助けるプロセスは、最終的に顧客に最良の結果を提供するプロセスです。
計画は最も予期せぬことに脱線する
軍事計画担当者が言うように、すべての細かい計画を立ててすべての戦略を練ることができますが、戦闘を開始すると、計画はすべて地獄に放り出されます。確かに、人々が病気になったり、休暇を計画したり、計画された開発期間の真ん中に大規模な見本市がポップアップしたりするなど、遅延の可能性がある見積もりを読み込むことができますが、大規模な計画を常に立てることはできません能力不足、サーバーファーム全体がダウンする、開発チーム全体が同時にベンガルインフルエンザに感染する、サプライヤが突然倒産するなどです。物事は失敗する可能性があり、間違いなく失敗します。指差しは誰の助けにもなりません。ただし、代替のリリーススケジュールを交渉し、顧客へのすべてのリリースが、すべてのリリースでビジネス価値を提供する実用的なソフトウェアを確実に提供できるようにすることで、不測の事態に対処することを計画できます。
したがって、この定義では、プロジェクトを混乱させるのは系統的な障害であり、必ずしもスケジューリングの問題ではありません。スケジューリング自体は、チームが成功を収めるために適切に行う必要がある他のすべてのものに比べて比較的簡単です。
ソフトウェアプロジェクトのサイズを見積もるには、多くの方法があります。サイズを努力に変換することは、ある種の生産性要因に依存します。また、高い保守性や高いスケーラビリティが必要な場合など、特定の技術的な複雑さの要素に合わせて調整する必要がある場合もあります。また、テクノロジーやプロセスにおける開発者の経験や、その動機さえも、環境要因に合わせて調整する必要があるかもしれません。ご覧のように、より正確な見積もりを与える値を正しく選択するために経験を必要とする多くの変数があります。したがって、推定は、推定者が何らかの方法を使用せず、彼の経験のみに依存している場合、推定者の経験はもちろん、推定者の経験に依存します。これが主な問題です。組織内のさまざまなプロジェクトからの文書化された履歴データにさらに依存する必要があります。対策はプロジェクトから定期的に収集され、組織のリポジトリに保存されて、後のプロジェクトの見積もりをサポートする必要があります。
もう1つの問題は、コーディング時間だけを考える傾向があることです。分析、設計、テスト、構成などの他のアクティビティを忘れたり、過小評価したりすることがあります。
pfffは簡単です。
10億の橋を架けると、橋の架け方にどれだけ時間がかかるかがわかります。
10億個のソフトウェアを構築すると、どれだけの時間がかかるかがわかります。
1年前、私はこの問題について簡単な調査を行い、メガプロジェクト（5億ドル以上のコストがかかるプロジェクト）のほとんどが失敗し、その半分がコストを超え、当然です。
この世界で何が起こっても奇跡です。
ここに素敵なプレゼンテーションへのリンクがあります