14

ソフトウェアの見積もりを正確に行うのは難しいことは誰もが知っていますが、私は正確を求めているわけではありません。スタートアップで何人の人を雇うべきかを知るために、プロジェクトのおおよその人時数を導き出せるようにしたいと考えています。

したがって、次のものがあると仮定します。

  • .NET プラットフォーム (C#、ASP MVC など) 上に構築された Web アプリケーション
  • 簡単なユースケースと複雑なユースケースが混在する定義された数のユースケース (このプロジェクトでは、70 のユースケース。ただし、複雑なケースと複雑でないケースの良好なベルカーブを与えるのに十分な数のユースケースを含むプロジェクトを想定しています)
  • 定義済みのデータベース スキーマ (この場合も 50 ほどのテーブルがありますが、7 つのテーブルを持つ典型的な書籍の例よりも多くのことを行う Web アプリケーションを想定しています :) )
  • 迅速で正確な現時点での推定を希望し、それが契約を締結するものではないことを理解しており、ソフトウェア開発の経験があり、ソフトウェア (およびその理解) がバージョンアップして進化することを理解しているパートナー
  • 堅実で熟練した開発者のプール

関係する時間数をすばやく推測するために使用する経験則はありますか?

更新: 測定可能だが大まかな要件に基づいた大まかな推定ルールを求めています。「4 ～ 6 週間」という回答は楽しく、気の利いた回答ですが、実際に仕事の簡単なバロメーターをいくつか確立したことのある人の意見を聞きたいです。

4

15 に答える 15

8

私は常に、達成する必要があるタスクの詳細なリストを作成しています。そこから、個々のタスクの時間をより適切に判断し、それらの数値を合計します。その後、合併症が発生した場合に備えて、25 ～ 50% 余分に追加します。

私がタスクのリストを言うとき、私は次のようなことを意味します: (これは一例です。特にサイトマップでは、人間的に可能な限り詳細にしてください)

  • データベース
    • テーブル
    • ビュー
    • ストアド プロシージャ
  • サイトマップ
    • ホームページ
    • ページについて
    • お問い合わせフォーム
  • 開発から本番への移行
    • セルフテスト
    • 顧客テスト
    • バグ修正

私はいつも時間を時間で見積もっています。(15 ～ 30 分のブロックではありません)

于 2010-01-27T03:31:28.767 に答える
5

大まかな推測が非常に間違っているのは非常に簡単です。提案されたアプリを可能な限り詳細とタスクに分解し、個々のタスクを見積もり、それを合計することをお勧めします。次に、忘れていたすべてのタスクに時間を追加します。

于 2010-01-27T03:21:50.807 に答える
5

大まかな要件に基づく信頼できる見積もりなどは事実上ありません。実際、私の経験では、1 日以上と推定される単一のタスクは、そのタスクをさらにサブタスクに分割する必要があることを強く示しています。

1週間の見積もりでさえ、通常はうまくいきません。私の経験では、詳細なしで 1 週間と見積もられたほとんどのタスクは、最終的に 2 ～ 3 週間かかり、大規模なプロジェクトでは問題が悪化するだけです。

それは主に心理的なものです。私たちは、プログラマー/デザイナー/アーキテクトとして楽観主義者であることを知っています。長く漠然としたターゲットを自分自身に与えると、実際にはそうでなくても、ゲームをリードしているように感じるのは信じられないほど簡単です. あと4週間？そして、先週機能していた壊れた検索機能を修正するだけでいいのですか? 簡単だ！それはさておき、楽しい Ajax フェード エフェクトに取り組みましょう。

そうは言っても、封筒の裏側の見積もりに私がよく使用する特定のヒューリスティックがあります。顧客やマネージャーが常に尋ねる質問は、「では、やりたいとしましょう<some_vague_project>。どのくらいの時間がかかると思いますか?」というものです。

最初に、プロジェクトの特定の側面を特定します。つまり、次のとおりです。

  • 期待される寿命 - 一度だけ実行、一時的、または永続的?
  • プロジェクトの独創性 - 以前にそのようなことをしたことがありますか?
  • 必要なドメイン知識と既知のドメイン知識のレベル - 仕様には学習曲線がありますか?
  • ボラティリティ - スコープ/所有権はどの程度明確で、変更される可能性はどの程度ですか?
  • 影響 - 重要なビジネス機能をサポート/置き換えますか?
  • UI の複雑さ - 5 画面未満、20 未満、またはそれ以上?
  • 顧客対応ですか？（もしそうなら、無数の改訂を経る必要があります）
  • 他のシステムと相互運用する必要がありますか?

次に、通常、これらのそれぞれに「ポイント」を割り当てます（これは「システム」ではないことに注意してください。これはすべて頭の中で発生し、通常は微調整が必​​要です）。おおよそのプロジェクト サイズのポイントを集計します。

  • ノーポイント：1～2日（台本）
  • 1点：1～2週間
  • 2点：2～4週間
  • 3点：1～2ヶ月
  • 4点：3～6ヶ月
  • 5点：6～12ヶ月
  • 6点以上：手がかりがない。

ここで私が行っていることに注意してください。複雑さとともに、多かれ少なかれ指数関数的な成長率があります。アプリが顧客向けであるなどの新しい問題を追加すると、プロジェクトに少し余分な時間が追加されるだけでなく、時間が2 倍または3 倍になります。言語、法律、ルックアンドフィールなどを精査します。重要なビジネス機能を置き換える場合も同じ考えです。あらゆる不測の事態に備えて、すべてのコンポーネントを防御的に記述する必要があります。

繰り返しますが、これは実際のプロジェクト計画では実用的ではなく、仕様全体を最大 1 ～ 2 日のタスクに分割せずにプロジェクトのタイムラインに実際にコミットすることはありません。これは、顧客/マネージャーが頭の中で計算するように効果的に要求し、「わからない」という答えを受け入れたくない場合に、すぐに使える簡単な質問に答えるためだけのものです.

繰り返しますが、全員が私の話を聞いていることを確認 するために、この方法を使用して実際のプロジェクトの見積もりを作成しないでください。 せいぜい、プロジェクトの最小基準となる「規模」を考え出すのに役立ちます。これは、取締役会で、点線に署名せずに期待に似たものを設定するために言うことができるものです。

于 2010-01-27T05:38:42.300 に答える
3

アジャイル推定手法は、次の手法を提案します。

  • 識別された「機能」のそれぞれに相対的なサイズの測定値を割り当てます。レイヤー/タスク（クレデンシャルを保持するテーブル）ではなく、機能（ログイン）を考えます。Tシャツのサイズはうまく機能します-S、M、L、XL

  • Mサイズの機能を使用して、チームが目的のテクノロジーですでに提供しているものを特定します。これを、予想される調整手段として使用します。つまり、チームの歴史は、2週間でM機能を提供できることを示しています。S = 1 / 2M、L = 2M、XL = 4Mを使用して、予想されるプロジェクトの長さを計算します。

  • チームが同等のことをまだ行っていない場合。機能を選択して、一緒に実装します。

  • 計算を特定の時点として引用しないでください。常に範囲として引用してください。範囲が大きいほど、確実性が低くなります。（MSがどの年に何かがリリースされるかを予測するだけであることに注意してください！）

そうは言っても、間違った質問をしている可能性があると考えたことはありますか？どのくらいのリスクを冒しても構わないと思いますか？

予測不可能なことを予測しようとするのではなく、できるだけ小さなチームから始めて（通信のオーバーヘッドを減らして）、市場に参入するための最小限の機能セットを提供してください（ビジネス/市場のニーズの早期検証）。

それがうまくいけば、より大きなチームで将来の機能を見積もるためのより多くの実際の情報が得られます。

お役に立てば幸いです。

于 2010-01-27T04:22:54.833 に答える
1

まず、あなたが何をしてもあなたの見積もりは間違っていると言って、これを前置きさせてください。あなたはすでにこれを知っていると思うので、それを念頭に置いて、プロジェクトを見積もるときに私が何をするかを詳しく説明しようと思います。

  1. プロジェクトを機能に分割します。各機能は、具体的で、測定可能で、達成可能で、現実的です。
  2. 各機能にTシャツのサイズを指定します：極小、小、中、大、xl、xxl。
  3. この時点で、可能であれば、お客様と交渉して、XL機能の数を最小限に抑えます。
  4. 各機能をサブタスクに分割するサブタスクを作成します。
  5. 各サブタスクのTシャツのサイズ。
  6. 今回は手順2〜5を繰り返して、大きなサイズの機能の数を減らします。バージョン1に必要な最小限の量になるまで、これを実行します。
  7. それぞれの機能を調べて、それぞれに時間の見積もりを与えます。
  8. 見積もりを合計します。

この時点で、工数/日での超非現実的な魔法のベストケースの見積もりが得られます。少なくとも2を掛けることをお勧めします。

これを、自由に使用できる開発者リソースの数で割って、出荷日数を取得できます。

この情報を取得して、（fogbugz）[www.fogbugz.com]のようなものにすることを強くお勧めします。次に、実際の時間を推定時間に対してマークして、出荷日が実際にいつになるかをより正確に把握できます。

ソフトウェアの見積もりは推測にすぎませんが、適切な追跡を行うことで、目標に近づくにつれてその推測を絞り込むことができます。あなたがそれを測定することができないならば、あなたはそれを管理することができません。

プロジェクトで頑張ってください、私はそれが時間通りに出荷されることを願っています！

于 2010-01-27T04:27:18.997 に答える
1

見積もりに永遠に費やす必要はありません。

  • すべてをタスクに分割してみてください。最長でも 1 週間以内に収まるようにしてください。
  • 1 日 1/2 未満の機能はありません
  • 誰も思いつかなかったもの (既知の未知) に対して、ランダムな数の未知のタスクを追加します。
  • すべてを合計し、結果に3を掛けます。

さらに、プロジェクトに参加する人数が多ければ多いほど、一人の人間の効率が低下することを忘れないでください。

いっそのこと、アジャイルに行きましょう。

于 2010-01-27T04:32:38.040 に答える
1

私が引き継ぐルールはありません。サムが言うように、見積もりしようとしているプロジェクトのサイズと複雑さによっては、これらの大まかな見積もりを間違ってしまうのは非常に簡単です。ほとんどの適切な見積もりは、見積もりを作成し、見積もりが間違っていた理由を調べ、次に見積もりを行うときに補正するという、ある種の反復プロセスから得られます。

また、プロジェクトとタスクを指定するときは、詳細を示すようにしてください。「何かをする、30時間」のようなタスクがある場合は注意が必要です。私は通常、1 作業日 (5 ～ 7 時間) を超える見積もりを分割しようとします。

あなたはまた、あなたが見積もっている人々の専門知識のレベルさえ知らないと言いました。もちろん、非常に保守的である可能性もありますが、そうすると、遅刻するのではなく、過剰雇用のリスクを負うことになります。ですから、自問する必要があると思います。遅刻するか、プロジェクトに参加する人が多すぎるか。スタートアップとして

于 2010-01-27T03:55:01.473 に答える
1

あなたが求めているものは、Function Point Analysisと呼ばれる古い推定手法に幾分似ています。各要件は特定され、タイプ (入力画面など) として特徴付けられます。これらには、高、中、低の複雑さの評価が割り当てられました。数値がタイプと複雑さに割り当てられ、ロット全体が合計されて、システムの機能ポイントの合計が得られました。

次に、関数ポイントの合計に修飾子を適用して、それを時間の労力に変換しました。修飾子は、使用されているツールと、(潜在的に) 開発者のスキルを考慮に入れます。

このシステムは理論的には優れていました。トリックは、正しい修飾子を考え出すことでした。実際には、3 つまたは 4 つのプロジェクトを実行した後にのみ妥当な見積もりが得られ、過去の経験に基づいてモディファイアを計算できます。

現在のプロジェクトに関しては、少し単純化されていますが、同様のシステムを使用することをお勧めします。各表をシンプル、中程度、または複雑に評価し、Web 画面ごとに同じことを行います。シンプルに 1 点、ミディアムに 2 点、複雑に 3 点を割り当てます。合計を合計すると、これが関数ポイントの合計になります。

次に、これを乗算して見積もりを出すための修飾子を見つける必要があります。これを考え出す最善の方法は、同じチームによって開発された古いシステムでファンクション ポイント分析を行うことです。実際に働いた時間をそのプロジェクトの機能ポイントの合計で割ると、モディファイアがあります。

これは非常に大雑把な見積もりにすぎませんが、おそらく得られる最高のものです。このような方法を使用すると、少なくとも見積もりをどのように考え出したかをクライアントに示すことができます.

于 2010-01-27T04:13:59.110 に答える
1

私の経験則：

  1. プロジェクトを可能な限り細分化し、各タスクに必要な時間をわずかに悲観的に見積もってから、すべてを合計して合計時間を算出します。

  2. 合計推定時間を少なくとも 2 倍し、最も単純なプロジェクトでも 3 倍または 4 倍します。より大きなプロジェクト、より複雑なプロジェクト、または私が初めて使用するものです。

  3. 一時停止機能付きの「Punchclock」を使用 - 購入せず、ほんの少しの js スクリプト - 3 つのプロジェクトで作業する場合、3 つのパンチ クロックがあるので、費やした時間を測定します。私たちのほとんどは、何かにどれくらいの時間が必要なのか見当がつかないと思うので、驚くべき結果が得られる可能性があります...はい、知っていると思いますが、測定してみてください-自分よりも速いことに気付くかもしれません考える

これは私にとってはかなりうまく機能しますが、経験則がもう少し必要だと感じています。

于 2010-11-30T23:50:01.613 に答える
0

他の人がすでに述べたように、タスク項目を分割し、それぞれを見積もります。次のようないくつかの一般的なタスクを確実に追加するために、それに追加します。

  1. 展開時間 (いくつかを含む; 開発、段階、生産など)
  2. 単体テスト
  3. DBモデリング
  4. ソリューションのセットアップ
  5. ドメイン モデル パターン

大きなプロジェクトでは、開発者が並行して生産的に作業するための基盤を設定するため、これらが最も重要であることがわかりました。

[編集]

また、開発者を新しい大きなプロジェクトにずらして配置するのが最善であることもわかりました。数人の開発者 (あなたの最高の開発者) から始めて、共通のフレームワーク タスクを、他の開発者が機能の作業を並行して開始し、生産的になることができるようにします。私は、彼らが一度に数人の開発者を投入し、それぞれが独自のことを行うプロジェクトに参加してきました。プロジェクトは相反するアイデアの寄せ集めになります。これを行うと、品質と一貫性が向上します。

一般的なタスクを適切に見積もっていれば、次の開発者をずらすタイミングを予測できます。

于 2010-01-27T04:30:27.607 に答える
0

物事をやり遂げる頭の良い人を 1 人雇って、しばらくしてから、指定された期日までに終わらせるにはあと何人必要かを尋ねます。採用するかどうか、または採用する数がわからない場合は、採用しないか 1 名かを選択してください。

于 2010-01-27T03:23:06.107 に答える
0

私見では、アプリのコーディングに約 500 +/- 100 時間、テストのコーディングにさらに 300 時間、テストとアプリを実際に実行するには 500 時間かかります。したがって、熟練した組織化された 3 人の開発者の場合、約 3 か月かかるはずです :) が、これは単なる見積もりです。

于 2010-01-27T04:00:34.650 に答える
0

あなたが持っていることを考えると

迅速で正確な現時点での推定を希望し、それが契約を締結するものではないことを理解しており、ソフトウェア開発の経験があり、ソフトウェア (およびその理解) がバージョンアップして進化することを理解しているパートナー

では、アジャイルな方法でプロジェクトを小さなプロジェクトに分割できますか? 事前に配信スケジュール (3 週間ごと?) を決定し、ユースケースに優先順位を付け、最初の配信を実行できるように時間を調整し、その後のイテレーションについて大まかな見積もりと計画を立てます。イテレーションごとに優先順位を再検討します。いずれにせよ、クライアントは途中で考えを変える可能性があるため、その過程で定期的なフィードバック/ディスカッションを構築することもできます。小さいピースの方がタイミングを合わせやすいです。
それができない場合は、サムのオプションを選択してください。時間をかけて適切な見積もりを作成してください。

于 2010-01-27T04:10:04.060 に答える
0

スタートアップに何人雇うべきか？

バッチが揃うまで、誰かを雇う準備はできていません (語彙、ユーザー ストーリー、機能ポイントなどを選択します)。

したがって、このレベルの分析を行うには、プロジェクト オーナーを雇うことから始める必要があるかもしれません。

次に、2 人を雇ってこのリストでペアとして 2 週間作業させます。彼らは作業リストの「幅」を教えてくれます。幅を埋めるのに十分なペアを雇い、建築家を雇って元のプロジェクト所有者と協力してリストを拡大し続けます.

そして、あなたが作成しなければならないものを正確に説明する方法を人々に直接伝える方法がない限り、これを開始しないでください。

于 2010-01-27T05:32:31.863 に答える
-2

あなたの腸に行き、それに3ヶ月を追加してください

于 2010-01-27T03:20:51.053 に答える