私はソフトウェア工学の観点から質問に対処しますが、学んだ教訓の多くは他のプロジェクトにも適用されます。 正確なプロジェクト見積もりを作成することは、ソフトウェアエンジニアリングで行うのが最も難しい作業の一つであり、ほとんどのエンジニア（私自身を含む）がうまく行う方法を知らないことが多い見落とされがちなスキルです。 また、以前にプロジェクトの完了時間を見積もる必要がなかった人は、難易度を過小評価し、少なくとも2倍の見積もりを誤って取得する傾向があ 任意のスキルのように、一つだけの練習で良くなります。
プロジェクトの見積もりについての私の最も鮮明な記憶は、エンドツーエンドのオンラインビデオプラットフォームを提供したスタートアップであるOoyala 2008年、同社が設立されてからわずか一年以上後、エンジニアリングチームは製品のFlashベースのビデオプレーヤーの書き換え作業を開始しました。 私たちの目標は、プレイヤーをよりモジュール化し、より高性能にし、よりクリーンでテストされたコードベースを持つことでした。 3人の最初のチームは、自分自身と10人のエンジニアリングチームの残りの部分を引っ張る前に、いくつかのコアインフラストラクチャを設計し、書 彼らはプロジェクトが完了するまでの4ヶ月を推定し、CTOとプロダクトマネージャーは、作業の内訳と依存関係を要約したガントチャートを作成しました。 2009年5月9日に完全移籍で加入した。
私たちは、ハードワークや才能のあるエンジニアの不足のためではなく、目標を逃しました;チームのほとんどの人が70-80時間の週を引っ張った月がありました(推奨されていません)。 プロジェクトの途中で、私たちも苦労して私たちはかなり細かいタスクに毎時見積もりを割り当てた演習の数日の価値を経ました。 最大の遅延は、ほとんどの場合、最初の見積もりで考慮できなかった多くの外部要因に起因していました:
- 優先度の高い顧客取引が署名され、エンジニアがカスタム作業にコンテキストスイッチする必要がある、
- Adobeのflash playerコードのバグ、
- ビデオが実際にいつ一時停止され、バッファリングされ、再生されたかを正確に判断することが困難になった、
- 再現が困難なビデオ破損IEで特定のビデオフレームを求めたときにプレーヤーがクラッシュするバグ、
- 製品開発を再開する必要がある4現在の顧客基盤を満足させるために、プロジェクトに数ヶ月間、
- スケーラビリティの問題に対処する必要がありました。 分析データが増加し、
- 初期のエンジニアがプロジェクトの途中でチームを離れ、コードベースの主要部分の大量の知識転送、
- などが必要になりました。
プレイヤーの書き換えは会社にとって間違いなく必要でしたが、引き出した予期せぬ方法は初期のスタートアップに大きな犠牲を払った。 私が取り組んだ他のプロジェクト、中古品を見た、または他のエンジニアと話をした他のプロジェクトは、実際の完了時間がしばしば元の見積もりを倍にする同様のパターンに従っています。
ここでは、これらの経験からこれまでの私の持ち帰りレッスンのいくつかがあります：
可能な限り、タスクの見積もりを作成する人々は、それに取り組 これはイアン-マカリスターのBプレイヤー推定値を使用するポイントに似ています-タスクがかなり細かくても、タスクのリストが自分自身にかかる時間を正確に予測することはすでに信じられないほど困難です。 Ooyalaのplayer rewriteの間に、初期の見積もりの多くは非常に積極的であり、彼があまり精通していなかったコードベースの部分でエンジニアのランプアップ時間を無視していたことが明らかになりました。
第二システム効果に注意してください。 神話のMan-Monthでは、Frederick BrooksはIBMでの彼のプロジェクトの経験から、第二のシステムを過度に設計する人間の傾向が、再設計プロジェクトのタイムテーブルを:
建築家の最初の仕事は、余裕があり、きれいになりがちです。 彼は自分が何をしているのか分からないことを知っているので、慎重に、そして大きな拘束を持ってそれをします。
彼が最初の作品をデザインすると、彼にはフリルの後のフリルと装飾の後の装飾が起こる。 これらは”次の時間を使用するために離れて格納されます。”遅かれ早かれ最初のシステムが完成し、建築家は確固たる自信とそのクラスのシステムの実証された習得を持って、第二のシステムを構築する準備
この第二は、男が今までに設計した最も危険なシステムです。.. 一般的な傾向は、最初のシステムで慎重に脱線したすべてのアイデアやフリルを使用して、第二のシステムを過剰に設計することです。
特に、既存のソフトウェアを書き換えるプロジェクトでは、コードベースを書き換えるつもりなら、チームがそれを行うかもしれないという議論を使用して、 複雑さの増加は、大幅に後になるまで、書き換えや新機能の起動につながる可能性があります。
プロジェクトのタスクにかかる時間と、プロジェクトが完了するまでの時間を混同することに注意してください。 プロジェクトにかかる時間が長いほど、外部環境変数が機能し、プロジェクト全体のタイムラインを拡張する可能性が高くなります。 Ianが言及する定期的なドラッグは、プロジェクトのタイムラインに貢献しますが、予期しないイベントも同様です。 今年の初めにQuoraで作業したプロジェクトでは、次の累積時間コストのために、多くのプロジェクトが予想よりも起動に時間がかかりました。:
- 予期せぬ複数日のAWS停止への対応と回復、
- サイトを維持するためのペリオイドページャーデューティアラートの処理、
- かつてはプロジェクトから遠く離れていたが、それと重複してしまった休暇のスケジュール、
- 募集イベントの準備と出席、
- コンテキストの切り替え、
- 当初の予想よりもトリッキーであることが判明しました。
どのプロジェクトでも、個々には起こりそうもない、または目立たないかもしれないが、集合的に発生し、十分に長い時間枠で追加される可能性のある、任意の数のイベントや気晴らしをリストアップすることができる。 プロジェクトが長くなればなるほど、より多くの気晴らしがあり、外部の未知の要因のために予算バッファ時間を確保することが重要です。
統合関連のタスクのための十分な時間を予算します。 特に、多くの相互に関連するコンポーネントを持つプロジェクトでは、多くのエンジニアは、1)エンドツーエンドの統合タスクを最後まで延期し、2)すべてのピースを作業システムに統合するのに必要な時間を大幅に過小評価する傾向があります。 統合は非常に遠く離れている傾向があり、リスクは一般的に不明であるため、統合時間による仮定は、すべてのコンポーネントが正常に分離して動作す プロジェクトは、通常、プロジェクトのリスクの高い側面の一つであり、以前のマイルストーンと比較して、チームメンバー間のコミュニケーションのオーバヘッドが大幅に増加するにもかかわらず、エンドツーエンドのテストのために、プロジェクトの総時間のごく一部しか割り当てられないことがよくあります。
これの帰結は、統合のリスクと問題を早期に特定し、それらに対処するのに十分な時間があるように、エンドツーエンドのテストを可能な限り早期に開始することです。
あなたや他の誰かがそれらを取ることを望むどのくらいに基づいていない、実際にどのくらいの時間がかかるかに基づいて推定します。 常に自分から、あなたのチームメンバーから、管理から、または顧客から、より速くプロジェクトを完了するための圧力があるだろうし、多くの場合、その圧 心理的に誰も他の人を失望させたくないし、あなたが少し難しく、またはより効率的に働くならば、あなたは特定の期限を満たすことができると自 特に長いプロジェクトのために、しかし、希望的観測のこのタイプは、最終的に持続不可能です。
プロジェクトが進行するにつれて、プロジェクトの見積もりを定期的に再訪し、改訂します。 最も優れたソフトウェアがどのように構築され、段階的に改善されるかと同じように、プロジェクトの見積もりも同様です。 プロジェクトの見積もりを再訪し、推定ミスを表面化し、以前に予期せぬリスクに基づいてスケジュールを修正するために助けを取った実際の時間
プロジェクトの見積もりは、ほとんどの場合、過大評価ではなく過小評価される傾向があります。 プロジェクトの推定が難しいことを認識し、特定のプロジェクトで見積もりが間違っていた理由を反映すると、後続のプロジェクトで見積もりエラーが小さくなるように案内されます。
正確な見積もりを作成するだけではなく、プロジェクトを実行することにはもっと多くのことがあります。 エンジニアであり、成功に彼らのプロジェクトを回すのに上のソフトウェアエンジニアが使用する技術を習得したいと思えば私の本の自由な、サ これは、すべてのシリコンバレー全体の指導者からの物語、洞察力、および実用的な戦略の何百も詰め込まれています。
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html