project-planning - コーディングタスクの非常に迅速な (そして汚い) 見積もりを行うにはどうすればよいでしょうか?

Question

つまり、あなたはボスにその場に置かれたのです。15 分以内に、いくつかの新機能を追加するための概算見積もりを作成してください。あなたの上司は (幸いなことに) あなたがその時間内に正確な見積もりを提供できないことを認識しているので、適切な桁数の何かを期待しています。

問題は、時間枠内で桁違いに正確な見積もりを出すにはどうすればよいかということです。

これは、このような質問から期待されるものではなく、簡単で汚い見積もりであることを意図していることに注意してください

score 17 · Accepted Answer

指を口に入れ、舐め、手を振り、過去の経験に基づいて数字を作ります。次に、それを2倍にします。

本当に、それは重要な経験です。あなたはその仕事があなたに何をすることを要求するかを想像し、それをするのにどれくらいの時間がかかるかを知っています. 予期しないアイテムの場合は 2 倍にします。これが、ジュニアプログラマーにそのような見積もりを決して求めない理由でもあります。

score 7 · Accepted Answer

最善の方法は、すべての主要なサブコンポーネントの簡単な内訳を試すことです。

データモデルスクリプトの更新 (2 つのテーブルに 3 つの項目)
入力画面の変更（新規入力3件）
入力の確認 (3 つの新しい入力)
データを更新します。
表示結果など...
ビルド単体テスト

これらのそれぞれに大まかな推測を割り当てます。最も単純な項目でも少なくとも 1 時間かかる可能性があるため、少なくとも 2 時間置くことができない場合は、2 倍にすることで不確実性が考慮されます。

少なくとも、実行しなければならないすべての項目について考えているので、要求されたとおりの適切な順序になります。

score 5 · Accepted Answer

過去に行った同様のタスクと、それにかかった時間を思い出してください。

これまでまったく似たようなことをしたことがない場合は、タスクをサブタスクに分割してみてください。次に、可能な限り単純にプロトタイプを作成するのに 1 ～ 2 日以上かかると思われるサブタスクがなくなるまで、各サブタスクをさらに細かくします。仕方; 見積もりが 3 日を超えるタスクを分割できない場合、これは通常、そのタスクの実行に何が関係しているのかを本当にわかっていないことを意味します。簡単な調査を行います。すべてが十分に分割されたら、合計し、結果を 2 倍にして、それを見積もりとして出します。

上記のことを行うのに十分な問題へのアプローチ方法がわからず、上司が首をかしげているため、そこで調査できるとは思わない場合は、代わりに、上司にどれくらいの時間かかるかを見積もってみてください。彼に適切な見積もりを与えるのに十分な問題を理解するために必要な調査を行うようにあなたを連れて行きます。

score 3 · Accepted Answer

本当に見積もりがまったくできない状況は想像できません。多くの場合、合理的にトリミングできるさまざまなものに応じて、プロジェクトのタイムフレームが大きく異なる結果になる複数のシナリオを想像できる場合があります。上。嘘をつきたくないのですが、上司に対してできる最悪のことは、ただでっち上げをすることです。

そこで、それぞれの可能性について説明します。もちろん、これは理解のある上司に対してのみ機能しますが、上司が無知または愚かで完全な説明を聞くことを拒否する場合、別の問題が発生します。

たとえば、実際にこれを行う必要があった最近のケースで私が行った方法を次に示します。

私が取り組んでいるビデオエンコーダーである x264 は、実装が非常に簡単であるという理由だけで選択された、非常に原始的な形式のインターレースコーディングを実装しています。このコーディングの完全な形式を実装したかったのですが、単純化されたバージョンで行われた仮定のどれだけがそのような場合に失敗するかわかりませんでした.

そこで私は、変更しなければならない可能性のあるさまざまなレベルのことを考え、見積もりを範囲にしました。そして最悪の場合、変更する必要のあるものが山ほどあります。そこで私は上司に、仕様が非常に複雑で、その複雑さについては何も知らなかったにもかかわらず、プログラムに関連するコードが大幅に不足していることを考えると、ここで最悪の事態を想定したほうがよいのではないかと上司に話しました。その複雑さは実際に実装されました。結局、私は正しかった - 必要な変更は非常に複雑になり、H.264 のインターレースコーディングの複雑さについてより専門的な専門知識を持つ請負業者にプロジェクトを外注した.

score 3 · Accepted Answer

必要な内訳に加えて、Pragmatic Programmers から学んだアドバイスは、15 日を超える見積もりを週単位で、8 週間を超える見積もりを月単位で表すことです。単位が推定の精度を反映するようにします。30週以上は十分注意してください。

すでに行った同様のタスクに基づいて見積もりを行うこともできます。

score 2 · Accepted Answer

非常に迅速な見積もりが本当に必要な場合は、1〜2日以内にすべてのタスクで作業分解図を作成し、この見積もりの後、最小および最大の見積もり値を提供することですべてのタスクを見積もります。

最小値と最大値の合計は、タスク全体の間隔を指定します。これにより、上司にリスクに関する情報が提供され、常に非常に役立ちます。

ある程度の間隔、たとえば12〜15日または5〜30日が得られます。これは、前述の間隔の代わりに16日よりもはるかに便利です。

これは、Steve McConnel Software Evaluation：Demystifying theBlackArtによる優れた本に役立つ可能性があります。

score 2 · Accepted Answer

数字を考えて、それを 2 倍にしてから、さらに 2 倍にします (つまり、頭に浮かんだ最初の数字の 4 倍)。

上司がプロジェクトを「完了するまでの時間」と言うとき、彼はそれが完了してユーザーにライブで展開される時間を意味します。プログラマーは (当然のことながら) プログラミングを完了するのに必要な時間 (問題の解決策を物理的に入力する時間) しか考えないため、通常は過小評価されます。

経験則は次のとおりです。

「最初の数字」は、今説明したタスクの範囲に基づいて、タスクを完了するのにかかると思われる日数です。(しかし、もちろん、すべてを伝えられたわけではありません)。

最初の倍数は、上司に与えられた最初のデモ/プロトタイプの後に再コーディングするために必要な余分な時間であり、彼は「良い、素晴らしい。でも追加できますか...」と言います。

2 番目の倍数は、生産のための正しい標準まで再コード化を再コード化するのに必要な時間です。

3 番目の倍数は、テスト、ドキュメント作成、展開、および実際に製品をリリースして稼働させるために必要なその他すべての管理作業の時間です。

そして、4 番目の倍数は、上記の不測の事態です。

これにより、安全な見積もりが得られるはずです。もちろん、より綿密な計画と見積もりの実行を主張する必要があります。

score 1 · Accepted Answer

私は最近アジャイルの見積もりと計画を読んでいますが、それを十分に推奨することはできません。

score 1 · Accepted Answer

手元の主題を適切に調査するのに十分な時間がないのに見積もりを提供することを余儀なくされた場合、私は大幅に過大評価する傾向があります。ほとんどの場合、修正は私が思っているよりも難しいです。何かが1日かかると思うなら、私は2日と言います。私が何かが1時間かかると言うなら、私は1日と言います。私がこれらのコメントで説明しようとしているのは、スペルミスのような最もありふれたタスクを除いて、小さなコード変更でさえ丸一日に爆発する可能性があるということです。1日以上かかると思うものについては、見積もりを2倍にします。これを行うのは難しいかもしれません。経営陣は少数を望んでいます。あなたは他の開発者の前でスマートで有能に見えたいと思っています。ScottyFactoryも参照してください。

コードをテストするQAチームのメンバーがいる場合でも、コードをテストするのはあなたの仕事であることを覚えておく必要があります。見積もりには必ずそれを考慮に入れてください。これは、多くの開発者が見積もりプロセスから除外しているのを私が見たものです。

score 1 · Accepted Answer

要因 1 は未知数です。そのとおりです。すべてを知ることはできません。ただし、通常、その時点では誰も答えられないいくつかの主要な質問を知っているでしょう。

要因 2 は、手元にあるツールとリソースの難しさと入手可能性です。

結果 = 見積もりの約 2 倍

score 1 · Accepted Answer

タスクを部分に分割し、各部分に時間を割り当てます
1日1/2以上の単位で作業してください。これにより、マイクロスケジューリングが防止されます
プロジェクト見積もりの大きな問題は過小評価です。タスクをよく知っていて、コードをほとんど見ることができる場合は、タスクに 1 の重みを付けます。不確実性がある場合、またはタスクに未知のテクノロジが必要な場合は、不確実性のレベルに応じて、より高い係数を掛けます。
各パーツの精度は気にしすぎないでください。本当に重要なのは総継続時間だけであるため、エラーは相殺される傾向があります

楽観的な時間スケールを取り、それにPIを掛けるという古き良きスタンバイが常にあります。必要以上に頻繁に機能します。

score 0 · Accepted Answer

0

答えはいつも「6〜8週間」だと思います。

于 2009-07-01T08:07:24.457 に答える

score 0 · Accepted Answer

適切な大きさで見積もるには、次のものが必要です。

必要な機能のための新しいテクノロジーやフレームワークの導入がない。
純粋な開発時間と開発者 (および顧客とテスター..;
以前の見積もりに対するフィードバックを得る。
安全な推定範囲内の特徴のサイズ (2 倍の人数で 2 倍の大きさではない)
安定した開発チーム。
プロジェクトの起動オーバーヘッドはありません。
自分で行う作業のみを見積もります。

score 0 · Accepted Answer

私は通常、タスクをいくつかの部分に分割しますが、この種のことを半日未満の時間ブロックで見積もることはしません。内訳後に機能に少なくとも 5 つまたは 6 つの部分がある限り、エラーはほとんどの部分でバランスが取れていることがわかります (一部のタスクには 1 時間未満かかるなど)。

もちろん、ある程度の快適さを得るために必要な最小の時間分割とピースの数は、問題のドメインによって異なります。最近私が尋ねられたものには、少なくとも 5 または 6 の半日チャンクが適切なようです。ただし、数か月ごとに見直す必要があります。

他の誰かに代わって見積もりを依頼された場合、私はもう少し抵抗し、寛大なパディングシステムを使用して同様の慣行に従います (上記の「2 倍して x を追加する」は、おそらく適切な近似値です)。

score 0 · Accepted Answer

私は個人的にこの種のことを拒否します。しかし、私は自分のために働いているので、上司には答えません。ただのクライアントですが、その場では難しいことを理解してもらいやすいです。

score 0 · Accepted Answer

そんな時、私はマッケンジー兄弟のメートル法への変換に関するルールを思い出します。「2 倍して 30 を加える」

私は通常、あることを行うのにかかると当初考えていた速度を考え出し、それを 2 倍にして、使用している単位に応じて、テストのために 30 を追加します。

score 0 · Accepted Answer

「6 ～ 8 週間」は非常にうまく機能します。もう 1 つの機能は、データモデルに基づいています。

アプリケーションに必要なデータベーステーブル (または同様のもの) の数を想像してください。これに、各テーブルのモデル、CRUD、UI などをコーディングするのに必要な日数を掛けて、30% から 50% の時間を追加します。それ。

project-planning - コーディング タスクの非常に迅速な (そして汚い) 見積もりを行うにはどうすればよいでしょうか?

17 に答える 17

Related

Reference

project-planning - コーディングタスクの非常に迅速な (そして汚い) 見積もりを行うにはどうすればよいでしょうか?