新しいテクノロジーに取り組むときの時間を推定する方法は？ [閉まっている]

StackOverflow https://stackoverflow.com/questions/343652

  •  19-08-2019
  •  | 
  •  

質問

ここ2か月間Flexで作業していましたが、実際にFlexを実行する必要があったのは初めてだったため、プロジェクトタスクを過小評価してしまい、結果として遅延が生じました。では、新しいテクノロジーに取り組んでいるときに、プロジェクトのタイミングをどのように推定しますか？

役に立ちましたか？

解決

このスレッドを参照することもお勧めします。 a>

機能ポイントは、<！> quot;業界標準<！> quotです。 （それが何を意味するにせよ）何かをするのにかかる時間を見積もるため。ほとんどの場合、彼らはプログラムが何をするかをマップしようとします。そして、あなたはそれらを次のようなアルゴリズムに入れます：

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;
}

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

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

新しい言語を学習している場合、特定のシステムでは複雑さが増します。

他のヒント

できません。

研究とみなす必要があり、研究を推定することはできません。

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

その最初の期間の後、大まかな見積もりを行い、上司が実際の粗さを知っていることを確認します。

ホフスタッターの法則を使用：

  

常にあなたよりも時間がかかります   期待します   アカウントHofstadterの法則。

中規模の開発チームを.Netに切り替えるプロジェクトで働いたとき、完全なコンバージョンを推定できる唯一の方法は、最初の調査段階を許可することでした。これにより、一部の開発者はテクノロジーに精通し、機能の一部を完全に実装できました。作業したシステムの一部が生産基準に合わせて完成されていることが非常に重要であることがわかりました。

議論されたのは、テクノロジーに精通したコンサルタントを雇うことでした。これはコストのために決定されましたが、.NETプロジェクトの経験がある人が正しい方向に私たちを指すようにすることは非常に有益だったと思います。

追加する唯一のことは、この種のプロジェクトで作業する場合、他の開発者をスピードアップするのにかかる時間を見積もることも重要です。明らかに、これは研究フェーズにかかった時間よりも短くなります。プロトタイプの開発に携わった開発者は、現在新しいテクノロジーを採用している人々を支援するために手元にいるはずです。

要約すると：

  • 実際の見積もりを出す前に、新しい技術を習得する時間をとる必要があります。
  • 完全なプロジェクトの経験に基づいて、生産基準に基づいて見積もりを行う必要があります。
  • ベストプラクティスをすばやく学ぶために、経験のある請負業者を雇うことを恐れないでください。
  • プロダクションコードを解く前に、誰もがこの技術を学ぶ必要があることを忘れないでください。

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

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

つまり、要するに：

  • 常に新しいシステムを学習するための多くのスピンアップ時間を見積もります。言語を学ぶだけでなく、特異性を学ぶ必要があります。これはおそらく正確に推定することは不可能です
  • 可能な限りFlexを使用しないでください。ライブラリの大部分を共有しているため、ストレートFlashの方が良いとは思いません。

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

特定のサイズのプロジェクトの場合、プロジェクトの代表的な部分のかなり単純ではないがまだ完全なプロトタイプを作成する時間を与えてください。そうすれば、このテクノロジーを使って遊ぶ時間ができます。また、それを使ってものを作成するのにかかる時間に関して貴重な洞察を得ることができます。

過去に新しいテクノロジーを使用したとき（つまり、新しいテクノロジーがプロジェクトの配信の中心であったとき）、次のように推定することで良い結果が得られました：

New Project Time = Project Time * 1.5

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

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

今、あなたのような問題に遭遇しました。ここでこれらのコメントを読んだ後、 私は、新しい技術について深く明確になりたいレベルに属していると思います。 最初に、新しい技術を未加工のまま（短期間で）短期間で調査します。その後、すでに分解作業が行われているので、今度は優先順位を付けて、より詳細に調査します。

これが役立つことを願っています。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top