23
  • プロジェクトの計画と、新しいプロジェクトの時間見積もりの​​作成に関して、どのような経験がありますか?

  • 使用しているアプローチは何ですか? また、それがうまくいった、またはうまくいかなかった理由は何ですか?

  • 考慮すべきベストプラクティスはありますか?

4

7 に答える 7

21

見積もりタスク

私が使用しようとしている原則は次のとおりです (常に機会があるとは限りません)。

  • 段階的な改良
  • 3 点推定
  • リスク分析

段階的な改良

見積もりを行うときは、適切な粒度で見積もりを行い、見積もりに自信が持てるまで継続的にタスクを分類して追加することが重要です。多くの場合、見積もりを行うと、より洗練されたリスク分析が必要になる可能性のある、時間のかかるクリティカル パス タスクが浮き彫りになります。

リスク分析

各タスクのどこにリスクが潜んでいるかを突き止めようとすると (何かにリードタイムがあるか? 知識が不足していないか? 競合他社に打ち負かされる可能性があるか? など)、見積もりに対する自信を判断するのに役立ちます。それらの見積もりをどのように扱うかを決定します。リスク分析は、さらに段階的な改善が必要かどうかを判断するのにも役立ちます。

3 点推定

各タスク (設計、開発、テスト、バグ修正を含む) の最善、可能性、最悪の見積もりを指定すると、リスク分析と計画に役立ちます。見積もりを使用して、そのタスクの特定の成功率に到達する可能性が最も高い期間を計算できます。他の関連タスクに関する情報やリスク分析とともに、プロジェクト マネージャーは、リスクや、システム テストなどの他の既知の要素を見積もりに織り込んで、より信頼性の高い見積もりを得ることができます。

もちろん、見積もりの​​粒度も重要です。ほとんどのタスクでは、時間数を見積もっても意味がありません。ソフトウェアでは、通常は数日が最適ですが、場合によっては数週間または数か月になることもあります (作業のブロックをアウトソーシングしている場合など)。プロジェクトのすべてのタスクに適した時間の粒度を選択します (通常、要件の把握と機能仕様のフェーズに数日を使用し、その後、タスクとそのサブタスクについてさらに学習するために半日を使用します)。

結論

これら 3 つの項目はすべて相互に作用するため、多くの場合、各ステップを何度も調整する必要があります。たとえば、要件の段階で突き刺され、次に機能仕様の段階で、さらに設計仕様の段階で突き刺されることがあります。

見積もりは習得したスキルです。やればやるほど上手になります。リスク分析は、知らないことについて学ぶほど向上し、3 点推定は、知っていることについて学ぶほど向上し、段階的改良は、設計プロセスの各ステップを経るにつれて向上します。

時間がある場合は、タスクを完了した後に元の見積もりに戻って、実際の時間が 3 点の見積もりとプロジェクト計画とどのように一致するかを確認してください。異なる場合は、どこで時間が失われたか、または得られたかを確認し、将来のプロジェクトのためにそこから何を得ることができるかを学びましょう。

見積もりは困難な作業であってはなりません。私はいつも、見積もりを行う前よりも自分の仕事についてより多くのことを知っているように感じます。

于 2008-11-20T17:00:14.050 に答える
9

Steve McConnell著の「Software Estimation: Demystifying the Black Art」という本を強くお勧めします。それは本当にこの質問をよくカバーしています。

于 2008-11-20T15:25:00.077 に答える
7

The Pragmatic Programmerには、これに関する優れた情報がいくつかあります。彼らは、130 日を 6 か月と見積もるよりも、適切な時間単位を使用することを勧めています。また、最も重要なタスクに集中するようアドバイスしています。また、部分見積もりに基づいて見積もりを作成することは避けてください。

個人的には、タスクを理解できるチャンクに分割して、適切に見積もると便利だと思います。タスクが大きい場合、思いがけない問題を隠すことができる隅々が多すぎます。より小さなチャンクの詳細に集中することで、潜在的な問題をより適切に評価できます。

于 2008-11-20T15:26:59.200 に答える
2

あなたの質問はNP完全問題です:)見積もりを出すために使用されるアルゴリズムはたくさんありますが、それらは常に単なる推測であり、正確ではなく、多くは実行に時間がかかります。時間の見積もりを忘れて、スクラムまたはその他のアジャイル フレームワークを使用します。プロジェクトの見積もりを開始時に数時間で行うことは、単に人に嘘をつくことです。

機能を構築する直前まで時間ベースの見積もりを作成しないでください。機能の進行に合わせて、これらの見積もりを継続的に更新してください。

見積もりにはテストの時間を含めることを忘れないでください。

于 2008-11-20T15:59:18.027 に答える
1

練習、練習、練習。安全のために、見積もり能力を磨くときに過大評価してください。もちろん、あなたがコンサルタントであるならば、これはあなたにビジネスを犠牲にする可能性があります。あなたがビジネスを失うことを恐れているならば、見積もりの​​下で、しかしあなたがあなたの自由な時間/収益から余分な時間を補うであろうことに注意してください。

于 2008-11-20T16:05:20.167 に答える
1

RE: ビジネスを失うことを恐れている場合は、見積もっていませんが、余分な時間を自由時間/収益から補うことになることに注意してください。

クライアントに提示する時間をいじるよりも、時給を下げたほうがよいでしょう。少なくともこの方法で、クライアントに付加価値の外観を提示します。

LM

于 2008-11-29T22:56:48.090 に答える
0

実際のプロジェクトに費やされた時間を記録し、次のプロジェクトの計画に役立てます。PSP / TSPはそれを行う方法を提供します

于 2008-11-20T18:57:30.740 に答える