主任開発者として、私は新しいプロジェクトの仕様書を受け取ることが多く、関連する作業のプログラミング側を完了するのにどれくらいの時間がかかるか (時間単位) を尋ねられます。
他の開発者がこれらの時間を正確に計算する方法を知りたいのですが?
ありがとう！
ああ、これが論争的な質問と見なされないことを願っています。私はただ最高のテクニックを見つけることに興味があるだけです!
6177 次
6 に答える
20
見積もりはしばしばブラックアートと見なされますが、実際には人々が考えるよりもはるかに扱いやすいです。
インテックでは、契約ソフトウェア開発を行っています。ほとんどの場合、固定費に対抗する作業が含まれます。私たちの見積もりが絶えずずれていたら、すぐに廃業するでしょう。
しかし、私たちは15年間事業を行っており、利益を上げているので、明らかにこの見積もり全体が解決可能です。
入門
推定は不可能だと主張するほとんどの人は、大げさな推測をしています。これは、最小のプロジェクトでは散発的に機能する可能性がありますが、確実に拡張性はありません。一貫した精度を得るには、体系的なアプローチが必要です。
数年前、私のメンターは彼のために何がうまくいったかを教えてくれました。これは、 Joel Spolskyの古い推定方法によく似ています。これについては、JoelonEstimationを参照してください。これはシンプルでローテクなアプローチであり、小規模なチームに最適です。大規模なチームでは、通信とプロセスのオーバーヘッドが各開発者の時間のかなりの割合を占め始めるため、故障したり、変更が必要になる場合があります。
一言で言えば、私はスプレッドシートを使用して、テストからコミュニケーション、ドキュメントまですべてを考慮に入れて、プロジェクトを小さな（8時間未満）チャンクに分割します。最後に、予期しないアイテムやバグに対して20％の乗数を追加します（30日間無料で修正する必要があります）。
誰かが考案に関与していないと推定するのは非常に困難です。チーム全体で各項目を見積もり、最大数で行くことを好む人もいます。少なくとも、悲観的な見積もりをして、チームがあなたがオフだと思ったら、チームに発言する機会を与えるべきだと思います。
学習と改善
改善するにはフィードバックが必要です。つまり、実際に費やした時間を追跡して、比較を行い、見積もりの意味を調整できるようにすることを意味します。
現在、インテックでは、大きなプロジェクトに取り掛かる前に、スプレッドシートの広告申込情報がかんばんボードの付箋になり、プロジェクトマネージャーが毎日その進捗状況を追跡しています。私たちが調べたり、考慮しなかったアイテムを持っているときはいつでも、それは小さな赤い粘着性として上昇し、それは私たちのバーンダウンレポートにも入ります。これら2つのツールを組み合わせることで、チーム全体に貴重なフィードバックが提供されます。
これは、小さなプロジェクトのほぼ半分にある、典型的なかんばんボードの写真です。
列ヘッダーを読み取ることができない場合がありますが、Backlog、Brian、Keith、およびDoneと表示されます。バックログはグループ（管理領域など）ごとに分類され、開発者には、作業中のアイテムを示す列があります。
よく見ると、これらのメモにはすべて推定時間数が含まれています。私の列のメモは、合計すると約8時間になるはずです。これは、私の1日の作業時間数だからです。1日に4つあるのは珍しいことです。キースのコラムは空なので、おそらくこの日は外出していたでしょう。
スタンドアップミーティング、スクラム、バーンダウンレポートなど、私が何について話しているのかわからない場合は、スクラムの方法論を見てください。手紙には従いませんが、見積もりを行うだけでなく、新しい作業が追加され、見積もりが見落とされたり、満たされたり、超過したりしたときにプロジェクトがいつ出荷されるかを予測する方法を学ぶための素晴らしいアイデアがいくつかあります（実際に起こります） ）。バーンダウンレポートと呼ばれるこの素晴らしいツールを見て、次のように言うことができます。実際に1か月で出荷できます。バーンダウンレポートを見て、どの機能を削減するかを決定しましょう。
FogBugzには、エビデンスベースのスケジューリングと呼ばれるものがあります。これは、上記の利点を得るためのより簡単で自動化された方法である可能性があります。今、私は数週間で始まる小さなプロジェクトでそれを試しています。組み込みのバーンダウンレポートがあり、スケジュールの不正確さに適応するため、非常に強力になる可能性があります。
更新：簡単なメモ。数年が経ちましたが、これまでのところ、この投稿のすべてが今日でも維持されていると思います。上の画像は実際にはかんばんボードなので、かんばんという言葉を使用するように更新しました。
于 2010-08-06T12:03:36.127 に答える
4
一般的なテクニックはありません。あなたの (そしてあなたの開発者の) 経験に頼る必要があります。すべての環境変数と開発プロセス変数も考慮する必要があります。そして、これに対処したとしても、何かを見逃す可能性が大いにあります.
プログラミング時間だけを見積もっても意味がありません。開発プロセスは非常に相互に関連しているため、一方の側面だけを見積もっても価値のある結果は得られません。プログラミング、テスト、展開、アーキテクチャの開発、ドキュメント (テクニカル ドキュメントとユーザー マニュアル) の作成、Issue Tracker でのチケットの作成と管理、会議、休暇、病欠 (場合によっては待つのは面倒です) など、すべてを見積もる必要があります。男、次にタスクを別のタスクに割り当てます）、セッションの計画、コーヒーブレイク。
例えば、卵をフライパンに落としてから3分で焼き上がります。しかし、目玉焼きを作るのに3分かかると言ったら、あなたは間違っています. 見逃した:
- フライパンを取る（準備はできていますか？1つずつ行かなければなりませんか？このフライパンの列で待つ必要がありますか？）
- 火を起こす (オーブンはありますか? 暖炉を作るために丸太は必要ですか?)
- オイルを入手する (持っている? 買わなければならない?)
- 卵を得る
- それを揚げる
- プレートにサーブします (準備はできていますか? きれいにしますか? 洗いますか? 購入しますか? 食器洗い機が終わるのを待ちますか?)
- 調理後の後片付け（フライパンが汚れませんよね？）
これは、プロジェクトの見積もりに関する優れた出発点です。
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
いくつかの推定手法に関する適切な説明があります。数時間の読書で目が覚めます。
于 2010-08-10T06:42:04.877 に答える
2
FogBugzを使用している場合、そのエビデンスベースのスケジューリングにより、完了日の見積もりが非常に簡単になります。
そうではないかもしれませんが、おそらくEBSの原則を適用して見積もりを出すことができます。
于 2010-08-06T12:10:37.043 に答える
2
良い見積もりには経験が必要ですが、まったくない場合もあります。
私の現在の仕事では、私の2人の同僚（明らかに私よりもはるかに多くの経験を持っていた）は、通常、8倍（はい、8倍）過小評価していました。私、OTOHは、過去18か月に1回だけ、当初の見積もりを超えました。
なぜそれが起こるのですか？どちらも、コード的には実際に何をしているのかわからないように見えたので、文字通り親指をしゃぶりました。
結論：
過小評価しないでください。過大評価する方がはるかに安全です。後者を考えると、必要に応じていつでも開発を「スピードアップ」できます。すでに厳しいスケジュールになっている場合、できることはあまりありません。
于 2010-08-06T12:03:06.250 に答える
1
これはおそらくITビジネスの大きな謎の1つです。数え切れないほどの失敗したソフトウェアプロジェクトは、これに対する完全な解決策がまだないことを示していますが、これを解決するために私がこれまでに見つけた最も近いことは、FogBugzに組み込まれた適応推定メカニズムを使用することです。
基本的に、マイルストーンを小さなタスクに分割し、それらを完了するのにかかる時間を推測します。タスクは約8時間を超えてはなりません。次に、これらすべてのタスクを計画された機能としてFogbugzに入力します。タスクを完了するときは、FogBugzで時間を追跡します。
次に、Fogbugzは過去の見積もりと実際の消費時間を評価し、その情報を使用して、次のいくつかのマイルストーンを達成するウィンドウ（確率付き）を予測します。
于 2010-08-06T12:10:26.367 に答える
0
過大評価は過小評価よりもむしろよい。これは、「未知」のものを知らないためであり、(ほとんどの場合) ソフトウェア開発ライフサイクル中に仕様が変更されるためです。
私の経験では、(アジャイル方法論のように) 反復ステップを使用してタイムラインを決定します。プロジェクトをコンポーネントに分解し、それらのコンポーネントを過大評価します。これらの見積もりの合計が使用され、回帰テストと展開、およびすべての適切な作業に余分な時間が追加されます....
過去のプロジェクトから戻って、それらの過ちから学び、どうすれば賢明に見積もれるかを確認する必要があると思います。
于 2010-08-06T12:26:17.907 に答える