プログラマーはプロジェクトの開発時間をどのように見積もるのでしょうか?

プロジェクト時間の見積もりは、プロジェクトの成否を左右する重要な要素です。プロジェクトの時間管理には、プロジェクトを期限内に完了するために必要なさまざまなプロセスが含まれます。しかし、実際のプロジェクトでは、プロジェクトの遅延が発生したり、見積もりが著しく不正確になったりすることがよくあります。

時間を見積もること自体が困難です。プログラマーごとの見積もりは、実際に必要な時間とは若干異なります。推定時間は短く、いくつかのこと (コンパイル、テスト、コードの送信) が無視されていることを示しています。時間が超過したということは、タスクが大きすぎて理解するのが難しいことを示していると推定されます。

若手プログラマーにとって、この見積もりエラーは混乱を招くことがよくあります。一部のタスクを過小評価し、若干難しいタスクを過大評価します。経験豊富なプログラマーの場合、タスクの時間は 30 分から 24 時間の間であるべきで、24 時間を超えるタスクは分割する必要があると思います。プログラマーが頭の中で考えると、60 時間かかると思うかもしれませんが、実際には、経験豊富なプログラマーでも、タスクを制御可能なモジュールに分割し、分析して意思決定を行う必要があります。

認識すべきもう 1 つの重要な点は、プログラミングの経験は時間見積もりの​​経験と同じではないということです。期間の見積もりを行ったことのないプログラマは、時間の見積もりが得意ではありません。実際の所要時間と予想時間を比較しなければ、他のフィードバック情報から正確に時間を見積もるという経験は得られません。

すべてのプログラマーは評価テクニックを使用します。このスキルを向上させるために、引き受けるすべてのタスクについて練習することができます。タスクの開始時に開発にかかる時間を見積もって、最終的に実際にかかる時間と比較します。こうすることで、タスクの詳細の理解が深まるだけでなく、時間の見積もりスキルも向上します。

ホフスタッターの法則: ホフスタッターの法則を考慮したとしても、常に予想より時間がかかります。

PM は、なぜ会社の開発者が自分のプロジェクト時間を決して見積もることができないのかとよく不満を言います。 ！ただし、賢明なプログラマーは長い間これに慣れてきました。 2 日で完了するはずだったプロジェクトが最終的に 4 か月かかったという例も見たことがありますが、これは「時間が 2 倍になる」という経験則から見てもかなり大げさです。大まかに言えば、問題は、エンジニアと PM、またはその他の人々が、時間の見積もりについて異なるアプローチや考え方を持っているということです。

ほとんどのエンジニアの最初の反応は、すべてが計画通りに進んだ場合にプロトタイプを作成するのにかかる最小限の時間です。 PM やその他の下流担当者が知りたいのは、プロジェクトの準備がいつ完了するのか、そしてリリースまでにどれくらいの時間がかかるのかということです。したがって、これらはまったく異なる 2 つの話です。

したがって、エンジニアにとって時間の見積もりを習得することは必須のスキルであり、これはあなたがプロフェッショナルで安定した効率的な開発者であることを意味します。

なぜ時間の見積もりが必要なのでしょうか?

#外部依存関係

単独では有効なことは何も起こりません。プロジェクトには通常、機能チーム (財務、広報、カスタマー サポート) とのコミュニケーションや顧客とのコミュニケーションなどの外部依存関係があります。これらの外部依存関係を調整するのは、多くの場合 PM または CEO の仕事です。つまり、時間の見積もりを作成するのに最も適した人 (エンジニア) が、これらの見積もりを最も必要とする人ではないことを意味します。この非対称性が根本的な緊張を生み出します。

優先順位

優先順位を決定するには、時間の測定も重要です。エンジニアリング分野では費用対効果は重要な指標です。たとえ、取り組んでいる機能が世界で最も強力であっても、時間を計算して実装に時間がかかることが判明した場合、その機能の優先順位は低くなります。高すぎる。

たとえば、完了後に Web サイトを 50% 高速化するプロジェクトに取り組んでいますが、同時に 2 つのプロジェクトを完了すると、それぞれのプロジェクトで Web サイトが 40% 高速化する可能性があります。時間をかけて事前計算をしないと、どこでより高速な Web サイトを構築できるかわかりません。

主要な時間の見積もり

時間の見積もりが非常に重要であるという合意に達したと仮定して、引き続き見積もり方法を見てみましょう。 。多くの場合、私たちは「プロトタイプを書くのにどれくらい時間がかかるだろう」と考えて、どれくらいの時間がかかるかを過小評価してしまいます。

ただし、納品されるものはプロトタイプよりも大きいことが多く、テスト、デバッグ、最適化に費やす時間も考慮する必要があります。会議やインタビュー、コードレビュー、さらにはメールの送信などにも時間がかかります。

必要な時間を過小評価するもう 1 つの理由は、環境の構成に余分な 1 日の費用がかかる IDE の更新など、十分に考慮されていないことが多い予期せぬ問題です。

これを踏まえると、いわゆる経験や勘はあまり信じないほうがいいでしょう。

ステップ 1:技術計画の作成

重要なプロジェクトを開始する前に、技術計画または設計文書を作成する必要があります。このドキュメントの目的は、あなたが行っていることを他の人に知らせ、フィードバックを得ることができるようにすることです。技術的な詳細に気づくと、たとえば、特定のライブラリを新しいバージョンに更新するのにさらに 1 日かかる場合があるなど、具体的な所要時間がより明確になります。自分でライブラリを作成する必要もあります。

ここでは粒度が非常に重要です。何かが不明瞭に感じられる場合は、それについてさらに詳しく知るか、より詳細な手順に分割する必要があります。一方で、一つのステップが細かすぎると脆弱になり、計画全体が無駄になってしまう可能性があるので、その程度を把握する必要があります。

文書で考慮すべき点について知りたい場合は、AliciaChen によるこの記事を読むことができます。重要なのは、ひっくり返って最初からやり直す必要がないように、PM と明確にコミュニケーションし、曖昧さを排除することです。

#ステップ 2: #各ステップの見積もり時間を追加しますドキュメントの各ステップを実装するのにどのくらい時間がかかりますか? これには、詳細の検討が必要になることがよくあります (これ用のライブラリはすでにありますか?)。したがって、プロジェクトの性質によっては、最初に簡単なプロトタイプを作成すると、潜在的な多くの問題点を明らかにするのに役立ちます。

ステップ 3

:フォールト トレランス時間を追加するこれで、暫定的な時間の見積もりが得られました。 , しかし、考慮すべき要素は他にもたくさんあります。 外出先でのデバッグ: バグは避けられず、特定のコードベースに関する開発者の経験とコードベースの成熟度に依存します。会議と休日: 一般的に、会議や休日にはコーディングをしませんが、実際のコーディングにはどのくらい時間がかかりますか?したがって、時間を見積もるときはスケジュールをよく見てください。最終テスト: 通常はコードを書きながらテストする必要がありますが、多くのチームはリリース前に統合テストも行う必要があるため、見積もりにはこの部分の時間を考慮してください。コード レビュー: このコードベースでは通常何ラウンド行いますか?各ラウンドにどれくらい時間がかかりますか?何人のレビュー担当者を通過する必要がありますか?コードレビューの時間を確保するために、レビュー担当者のスケジュールに注意してください。

配信時間のコストを考慮すると、推定時間はプロジェクトの実際のリリース時間とかなり一致していることがわかります。実際にはもっと長いかもしれませんが、スケジュールを短縮するよう圧力をかけられる可能性があります。しかし、人々はあなたの見積もりがより正確であることを理解すれば、あなたをより信頼するでしょう。

ステップ 4

：リリース後のレビュー時間の見積もりレビューは非常に面倒ですはい、ただし、復習することで次回はより良くできるようになります。すべてのプロジェクトで実際の時間が予想と一致しなかった問題を解決し、その理由を見つけて改善します。

要するに、すべてはコミュニケーションに関するものです。事前に頻繁にコミュニケーションをとり、お互いのスケジュールやニーズの変化を理解しましょう。

PM などの関連参加者とコミュニケーションをとることで、相手から見積もりに影響を与える可能性のある重要な情報を提供される可能性もあります。デザイナーは、アニメーションが完成するまでに 1 週​​間かかるため、カットする必要があると言うかもしれません。別の PM は、このプロトタイプはユーザー調査のみを目的としており、この反復ではあまり多くのバグに対処する必要はないと付け加えることもあります。 エンジニアは、建設期間を短縮するために非現実的な妥協をしないでください。オープンで正直であることがよりプロフェッショナルです。 PM や他の人がこの見積もりを尊重するのはプロセスかもしれませんが、小言を言ってスケジュールを短縮することはないことを知っておいてください。

プロジェクト時間の見積もりは簡単ではありません。適切なコミュニケーション、共感、機能の優先順位付けのみがそれを可能にします。