7

私はこの 2 か月間 Flex に取り組んできましたが、実際に Flex を行うのはこれが初めてだったので、プロジェクトのタスクを過小評価してしまい、遅れが生じました。では、新しいテクノロジーに取り組んでいるときに、プロジェクトのタイミングをどのように見積もればよいのでしょうか?

4

12 に答える 12

10

できません。

あなたはそれを研究と見なさなければならず、研究は評価することはできません。

于 2008-12-05T12:27:10.370 に答える
6

私は、特定の日に何かを提供することを約束する前に、実験して新しいテクノロジーを学ぶための一定の期間を自分自身に与えます.

その最初の期間の後、いくつかの大まかな見積もりを作成し、上司が実際にどれだけ大まかであることを確認してください.

于 2008-12-05T12:26:07.250 に答える
3

中規模の開発チームを.Netに切り替えるプロジェクトで働いていたとき、完全な変換を見積もることができる唯一の方法は、最初の調査フェーズを許可することでした。これにより、一部の開発者はテクノロジに精通し、機能のごく一部を完全に実装できるようになりました。作業中のシステムの一部が生産基準に達していることが非常に重要であることがわかりました。

また、技術に精通したコンサルタントを雇うことも議論されました。これはコストの関係で決定されましたが、.NETプロジェクトの経験がある人が私たちを正しい方向に向けてくれることは非常に役に立ちました。

追加する他の唯一のことは、この種のプロジェクトに取り組むときは、他の開発者をスピードアップするのにかかる時間も見積もることが重要であるということです。明らかに、これは調査段階にかかった時間よりも短くなります。ただし、プロトタイプに取り組んだ開発者は、現在新しいテクノロジーを採用している人々を支援するために手元にいる必要があります。

総括する:

  • 実際の見積もりを出す前に、新しい技術を習得する時間を自分に与える必要があります。
  • プロジェクト全体の経験に基づいて、生産基準に基づいて見積もりを行う必要があります。
  • ベストプラクティスをすばやく学ぶために、経験豊富な請負業者を雇うことを恐れないでください。
  • 生産コードを解き放つ前に、誰もがこのテクノロジーを学ぶ必要があることを忘れないでください。
于 2008-12-05T12:37:21.207 に答える
2

このスレッドも参照することをお勧めします:関数ポイントを扱う人はいますか?

ファンクション ポイントは、何かを実行するのにかかる時間を見積もるための "業界標準" (それが何を意味するにせよ) です。ほとんどの場合、彼らはプログラムが何をするかを計画しようとします、そしてあなたはそれらを次のようなアルゴリズムに入れます:

long GetManHoursForProject()
{
    long   Count_of_Function_Points = GetFunctionPointCountFromAnalyticalPhaseOfSDLC();
    double Average_Complexity       = 1;  // .8 for easy, 1 for normal, 1.2 for hard
    long   Programming_Language     = 130; // for C++ (higher level languages have higher values)


    double Man_Months = Count_of_Function_Points * Programming_Language * Average_Complexity;


    long   Man_Hours = Man_Months * 20 * 8; // 20 days per month, 8 hours per day

    return Man_Hours;
}

上からリンクしたスレッドは、ストーリー ボード ポイントについて話しています。これは、それ自体で興味深い会話です。どちらがあなたに適しているかを見つけるために、これらの両方の主題を調べます.

関数ポイントとストーリー ボード ポイントの良いところは、言語乗数があることです。すべての言語で同じ考え方が使用されます。

新しい言語を学習している場合、特定のシステムの複雑さは高くなります。

于 2008-12-05T15:20:21.237 に答える
1

少し前まで、私はFlexでプロジェクトに取り組む必要があり、これまでFlex(またはFlash)を使用したことはありませんでした。また、このFlexアプリケーションでウィジェットの特定のサードパーティライブラリを使用することを余儀なくされました。Javaのような合理的な言語でかかると思った時間を見積もり、新しい言語の学習を考慮して約2倍にしました。問題は、Flexが合理的ではなく、文書化されておらず、標準ライブラリに多くのバグがあり、サードパーティライブラリも標準ライブラリのすべての設計機能を真摯に受け止めていたためです。壊れた。最終的に、機能が半分で、割り当てられた時間にわたって、パフォーマンスの低い製品になりました。ありがたいことに、経営陣は私たちがしばらくの間それに取り組むことを許可しました(彼らは要件を変更していました、だから彼らは私たちにそれだけの借金を負っています)そして私たちはそれを本当に良い形にしました。それでも私たちが望んでいたことをすべて実行するわけではありませんが、パフォーマンスの最悪の問題を軽減するなど、ライブラリのバグのほとんどをハックしました(つまり、UIComponentのインスタンス化には長い時間がかかるため、起動時にすべてを実行するのではなく、必要に応じて実行します。これは、サードパーティのライブラリとは関係ありません)。

つまり、要するに:

  • 新しいシステムを学習するために、常に多くのスピンアップ時間を見積もります。言語を学ぶだけでなく、特異性を学ぶ必要があります。これを正確に見積もることはおそらく不可能です
  • 可能な限りフレックスは避けてください。ライブラリの大部分を共有しているので、ストレートFlashがこれ以上優れているとは想像できません。
于 2008-12-05T13:48:46.383 に答える
1

私は通常、学習に費やす時間と実装に費やす時間を別々に見積もっています。つまり、私はプロジェクトの難しさに基づいて自分が何をしているかを知っているかのようにプロジェクトを見積もりますが、新しいテクノロジーを習得するのにかかる時間を見積もります。

于 2008-12-05T13:22:30.210 に答える
1

私の経験則では、所要時間は 2 倍になります。解決に時間がかかる予期しない問題が常に発生することがわかりました。

于 2008-12-08T16:11:49.760 に答える
0

過去に新しいテクノロジーを使用したことがある場合(つまり、新しいテクノロジーがプロジェクトの実施の中心であった場合)、次のように見積もることで良い結果が得られました。

New Project Time = Project Time * 1.5

...しかし、言うまでもなく、これは経験則とYMMVです。

于 2008-12-05T12:48:26.643 に答える
0

誰かを雇うか見積もりをしない以外にできることの1つは、タスクの相対的な複雑さを見積もり、実際の実装時間を複雑さのレベルと比較することです。時間の経過とともに、比率は安定した値に向かって収束します。

于 2008-12-05T13:00:06.043 に答える
0

ある程度の規模のプロジェクトの場合は、プロジェクトの代表的な部分のかなり単純でありながら完全であり、自明ではないプロトタイプを作成する時間をとってください。その後、テクノロジーをいじる時間があり、それを使って何かを作成するのにかかる時間に関して貴重な洞察を得ることもできます。

于 2008-12-05T12:27:22.083 に答える