この記事では、皆さんが長い間知っていることについてお話します。 <？Xml：namespace prefix = o ns = "urn：schemas-microsoft-com：office：office" /> <o：p> </ o：p>
あなたがソフトウェア業界に慣れていない場合、マネージャーは時々、時間や仕事の見積もりに突然興味を持っている段階にいることに気づきます...そして、通常、とにかくではなく、ファッショナブルなテクニックに従っています。 まだ発見されていないバグや、まだ設計が完了していない機能にかかる時間を1週間以内に通知するように求められます。1分ごとに不可能な場合は、計画された作業を1時間以内に確実に分割する必要があるという事実は言うまでもありません。 .. <o：p> </ o：p>
通常、プロジェクト時間はどのように見積もられますか？ 大きなピースを評価することは実際上不可能であることは誰もが知っているので、小さなピースに分割され、これらの小さなピースは、たとえば、ガントチャートまたはカレンダーやExcelでまとめられます。<O：p> < / o：p>
今日は、この手法の根底にある2つの完全に誤った仮定についてお話したいと思います。<O：p> </ o：p>
そもそも、プロジェクト時間またはプロジェクトステップの推定値は何ですか？<O：p> </ o：p>
いいえ、いいえ、私は、経営者を見越して、カッサンドラとして、あなたは絶対に正確に未来を予測しなければならないことを理解します。共産主義の若いビルダーの道徳的なコードのようなもの-それによれば、私たちは毎年強制訓練をしています）。 一般的に、誰もがこれは難しいことを理解していますが、あなたの予言は「十分に良い」はずです。すべての観点から<O：p> </ o：p>
まあ、マネージャーがそれを言うとき、それは理解できます。 しかし、私たちはマネージャーではなく、エンジニアであり技術者です。 「十分に良い」ことは非常に不明瞭なものであることを知っています。 また、エンジニアリングの分野の一部であるためには、概念は数で測定可能でなければなりません。 つまり、この問題を何らかの形で測定して、はっきりと「十分」または「十分ではない」と言いたいのです。 そして、エンジニアが何かを測定したい場合、そのような有害な科学-数学を使用します。 彼女は、マネージャーについて自分の考えを常に語り、さらには正しいことさえわかっているため、有害です... <o：p> </ o：p>
それで、数学、より正確には数学的統計と確率理論の推定値は何ですか。 そして、これは、与えられた確率で予想されるランダム変数が入る間隔です。 ランダムな値とは、プロジェクトにかかる時間、または別のプロジェクトステップが存在することです。 医師が処方する必要があるようですが、与えられた確率でどうするか？<O：p> </ o：p>
マネージャーにアプローチして、「80％の確率でこのプロジェクトは1か月で完了する」と言ってみてください。
ええ、あなたはすでに少しmal怠感を感じましたか？ さらに良い。 彼は「確かに」を望んでいますが、数学は何と言っていますか？ ポアソン分布または正規ガウス分布などの習慣的な分布の図を想像してください。 ヒットする可能性が100％の間隔はどのくらいですか？ ああ、そうです、もしマネージャーが保証された評価を望むなら、数学的には常に無限です。 まあ、または実際には、プロジェクトが単純に破られる用語。 どのプロジェクトでも失敗する可能性があります。 良い成績を収めることが許可された優秀なエンジニアの場合、この失敗の可能性は低く、悪い成績の場合ははるかに大きくなりますが、状況によってはゼロに等しくなりません。<O：p> </ o：p>
つまり、volens-nolensはあなたの成績を取り去り、これはあなたの約束と見なされますが、実際には80、90、95％の確率の成績になります... <o：p> </ o：p>
したがって、プロジェクトまたはプロジェクトステップの評価は、あなたにとって快適な確率で適合する時間間隔です。 または、快適なリスクがあるとは言えません。<O：p> </ o：p>
80パーセントを選択したと仮定します（それぞれ、20パーセントに満たないリスクがあります）。 はい、非常にリスクが高いように聞こえますが、プログラマーを自然な状態で見ると、大多数の80パーセントでさえ過度に高いと感じました。 通常、スマートマネージャーは、開発者の評価を少なくとも半分から2倍にします<O：p> </ o：p>
したがって、プロジェクトがあり、2つのステップがあります。 各ステップには80パーセントの確率で2日半かかると推定しました。 これは、プロジェクト全体が80パーセントの同じ確率で1週間かかることを意味しますか？ Theorverから少なくとも少し覚えていれば、あなたはすでに「いいえ」と答えました。自然界では通常起こらない、特にエキゾチックな分布を除き、確率は完全に異なります。<O：p> </ o：p>
たとえば、正規分布の例を参照してください。 大きな青い縦線は、80％の確率で達成可能な同じプロジェクト時間です。 写真は同じ値t 0で前後に偏差を示し、斜線部分はそれぞれそのような偏差の確率を示します。 ご覧のように、緑の領域はピンクよりもはるかに大きいため、一定の時間に遅れをとるのは、同じ一定の時間だけプロジェクトを追い越すよりもはるかに簡単です。 事実は、誰にとっても直感的に驚くべきことではないでしょうか？
<o：p>
</ o：p>
そのような量の最も一般的な分布-ポアソンの場合、画像は同じになります。 一般的に、人生で出会うほとんどの分布のように。 これは、t 1およびt 2として80％の確率で2つのプロジェクトステップの推定値を与えた場合、t 1 + t 2は80％の確率でプロジェクト全体の推定値ではないことを意味します。<O：p> </ o： p>
抽象的な問題で頭を惑わさないために、もう少し実用的な質問も見てみましょう。 しかし、人が予定より早く仕事を終えることは起こりますか？ まあ、時々それは起こりますが、彼らが言うように、無視できる量です。 結局のところ、早く終了したとしても、解放された時間を使ってコードをきれいにし、テストし、もう一度確認してください。 実際、マーフィーの法則に捧げられたコレクションに広まっている日常の知恵は、「どんな仕事にも、それに割り当てられたすべての時間がかかります」と言っているだけです。<O：p> </ o：p>
この修正により、すべてがさらにばかげたものになります。 作業が計画よりも短くないと仮定すると、プロジェクトがt 1 + t 2に収まり続けるには、 両方のタスクが計画時間内に完了する必要があるため、思い出すと、80％の確率で推定されました。 今度は、数学に関する学校の教科書を引き出して、プロジェクト全体がProjectでカウントされた時間を満たす可能性を計算するか、以下を追加することで計算します：<o：p> </ o：p>
P（T1＆T2）= P（T1）* P（T2）= 0.8 * 0.8 = 0.64 <o：p> </ o：p>
つまり、プロジェクトを2つの部分に分割し、それぞれ80パーセントの確率で評価した場合、その量の「信頼性」はわずか64パーセントになります。 宿題として試してみてください。プロジェクトが10のステップに分かれている場合はどうなりますか？ 試しましたか？ うん。 10パーセント強。 90パーセントの各ステップの見積もりでエンジニアを揺さぶったとしても、10ステップのプロジェクトの可能性は35パーセントにすぎません。<O：p> </ o：p>
ちなみに、エビデンスに基づいたスケジューリング（ http://www.joelonsoftware.com/items/2007/10/26.html ）のジョエル・スポルスキーは、推定値を追加するのではなく、モンテカルロ法によるステップ推定値から取得するべきだと主張しているのはそのためです。 。<o：p> </ o：p>
もちろん、個々の評価の質が全体の評価の質に大きく影響することがわかります。 したがって、ステップの見積もりを80から90パーセントに改善すると、プロジェクトの評価が10ステップから10から35パーセントに改善されました。 しかし、正直に言って、35％があなたに合っていますか？ また、わずか10ステップでプロジェクトを実行する頻度はどのくらいですか？ そして、100ステップで、各ステップの確率が99％の非常に高品質のステップ推定であっても、最終的にプロジェクト全体のチャンスが40％未満になります。 40パーセントに満足していますか？ そして、100人のうち1人だけが、1日コメントを書くのに1日もかからないのに、エンジニアが間違っているのをどこで見つけますか？<O：p> </ o：p>
もちろん、公平を期すため、このような成功の可能性の「崩壊」は、クリティカルパスのステップに対してのみ発生することに注意する必要があります。 ただし、リソース（人）を効果的に使用する場合、遅延が十分に小さい場合でも、どのステップもクリティカルパスになる可能性があることを忘れないでください。 したがって、状況は上記の例ほど悪くはないかもしれませんが、私たちが望むほど良くはありません。 しかし、あなたもすでにこれを知っています... :-) <o：p> </ o：p>
もちろん、今は自然な質問がありますが、どうすればよいでしょうか？ 何かが可能です。 しかし、これはすでに別の記事の主題であり、1つではありません。<O：p> </ o：p>
そして、この記事で私が言おうとした「i」について、簡潔に説明します。<o：p> </ o：p>
1. 評価は、プロジェクトが完了した時点ではありません。 これは彼が与えられた確率で会う時間です。 マネージャーまたはエンジニアがこれを知らなくても、それは存在し、エンジニアの楽観と遅れているものに対するマネージャーの攻撃性に依存します。<O：p> </ o：p>
2. 経営陣は、プロジェクト評価に桁違いの大きなエラーを導入し、エンジニアよりも個々のステップの推定値を追加し、これらの個々のステップを評価します<O：p> </ o：p>
3. 個々の手順を評価する際の小さなエラーでさえ、プロジェクト全体の評価の信頼性を大幅に低下させる可能性があります<O：p> </ o：p>
4. いつものように、電卓は脳やMicrosoft Project-管理の技術に置き換わるものではありません<O：p> </ o：p>
5. ああ、もう1つ。自分をアイドルにしないでください。 ファッショナブルなテクニックを含む<O：p> </ o：p>
<o：p> </ o：p>