ファンクションポイントで言う努力の見積もりをdjangoのような特定のWebフレームワークに変換するにはどうすればよいですか？それとも、労力の見積もりはWebフレームワークのアーキテクチャにのみ依存していますか？ヒントやガイドラインが役立ちます。
EDITは、これが私のフレームワークであり、djangoと言って、私の要件をモデルとテンプレートに変換するという観点から考えさせてください。
または、一般的に言うと、これらは私の要件です。これらは私のファンクションポイント（一般的な見積もり手法）であり、これをdjangoフレームワークの制約に変換して、労力の見積もりを行うことができます。
サイズの見積もりからスケジュールの見積もりに移行するときの速度のスクラムの概念が好きで、何年にもわたってうまく適用してきました。
問題、ユーザーストーリー、または機能は、コード行、ファンクションポイント、ストーリーポイント、理想的な作業時間、グミベアなど、いくつかのサイズ単位を使用して推定されます。サイズを「ポイント」で見積もっているとしましょう。
このサイズの見積もりからスケジュールの見積もりに移行するには、速度を適用します。つまり、チームが特定の時間に作成した完成した機能のポイント数に相当します。たとえば、n週間のスプリント（反復）で、nはたとえば1の範囲です。 4.4。したがって、2週間のスプリントあたり300ポイントの速度があり、バックログに実装する500ポイント相当のユーザーストーリーがある場合。したがって、すべてを完了するには2週間のスプリントが2回必要です。しかし、通常は逆に適用されます。固定期間のスプリントが与えられた場合、どのストーリーを実装して最大の価値をもたらし、どのストーリーを延期する必要があるかです。
どのようにして速度数を取得しますか？最初にあなたはそれを推測しなければなりません。しかし、最初のスプリントの直後に、チームの過去の速度データがあります。推測するのではなく、このデータに基づいて速度推定を開始します。数値の微調整が少なければ少ないほど、時間の経過とともに正確になります。
このように、問題のサイズ設定では、問題自体以外のことを考慮する必要はありません。経験、イェリングなどのチームの特徴は、速度に現れます。
このトピックに関する良い参考資料は、MikeCohnのアジャイルな見積りと計画です。
チームがWebフレームワークとWebテクノロジー全般にどれだけ精通しているか、アプリケーションの複雑さ、Webモデルにどれだけ適合するかなどの多くの要因に依存する可能性があります。一部のアプリケーションはWebモデルにうまく適合しますが、他のアプリケーションは適合しません。 。たとえば、ASP.NETがリリースされたばかりのときに、いくつかのグリッドを備えた内部デスクトップユーティリティをASP.NETに変換しようとしました。すべての機能が移植されましたが、元のデスクトップアプリが提供していたスプレッドシートのような使いやすさに比べて「クリックが多すぎる」ため、ユーザーに受け入れられませんでした。
従来のデスクトップアプリケーションと比較して、作業を（たとえば）データベース、DAL、BLL、WS、UI、およびレポートレイヤーに分割することにより、内部作業が増加する場合があります。もう1つの懸念は、ネットワーク、ブラウザ、および/またはサーバーへの計算の集中化によって引き起こされるパフォーマンスの問題である可能性があります。また、ブラウザの互換性についても心配する必要があるかもしれません。
おそらく、実際に知る唯一の方法は、チームに関心のあるフレームワークで重要な開発を実際に試し、同等の価値と動作のソフトウェアを実装することです。