プログラミングタスクの見積もりにどれくらいの時間がかかりますか？

たとえば、プロジェクトをn個の個別の作業成果物（クラス、関数、コンポーネントなど）に分割した場合、n * tが推定に費やすのに適切な時間になるような時間tはありますか？

そのレベルに分解するのに十分な情報がある場合、それぞれに1分以上費やすことはできません。とにかく正解するつもりはありませんが、1時間後と同じように、1分後も正解します。

一方、ユーザーストーリーについて話している場合は、関係者を部屋に入れ、推定する前に5分間質問してください。

とにかく、見積もりを行うのに多くの時間を無駄にしないでください。それらは、努力する価値があるほど有用または正確ではありません。

私の経験では、アジャイルアプローチの中心となる「うん、それは本当にうまくいく」要素の1つは、「タスクは1日もかからないはずです」というガイドラインです。1日以上かかるものを見積もる場合は、かなり遠く離れています。

あなたがそれらを分解できるようにそれらを分解したら、あなたは十分に終わりました。それらが何であるかに関係なく

アジャイルスクラム方法論では、Planning Pokerはチーム全体を使用して、スプリントのユーザーストーリーに必要な労力をすばやく見積もる効果的な方法と見なされています（これがあなたが話していることだと想定しています）。それ以外の場合は、ユーザーストーリーの一部である単一のタスクの見積もりに数分以上費やすことはありません。

開発者のチームの見積もりを作成する場合は、このコンセンサスベースの手法を使用することを強くお勧めします。

ポーカーを計画すると、1回のセッション（1〜2時間以内）内のすべてのユーザーストーリーについて、かなり良い見積もりを得ることができます。

これを読んで試してみてください！

また、原則として、ユーザーストーリーのタスクは7.5時間（1日の作業）を超えることはできません。その場合は、タスクを小さなタスクに分割する必要があります。

それはあなたが何を必要としているのかによると思います。たとえば、プロジェクトのリソース割り当てがプロジェクトに依存している場合（ここで時々そうだったように）、慎重に行うことをお勧めします。逆に言えば、この種の必要性のないプロジェクトを行っている場合は、あまり詳しく説明しないでください。あまりにも多くの時間を費やすことは良い考えではありません。正確な推定を行うことは非常に困難です。

WikipediaにはCone of UncertaintyとCone of Uncertaintyと呼ばれる有名な概念があり、通常はどれほど正確に推定できるかを述べています。読む価値があります。

見積もりから何を得るのですか？

作業内容によっては、正確な個別の見積もりが関連する場合があります（顧客が週末に支払うか、タスク/ストーリーが他のユーザーにブロックされており、正確なETAが必要です）かそうでないか（バックログに200のストーリーがある場合）ストーリーが1週間変化しても誰も死ぬことはありません。多数のエラーを平均化するために推定誤差に頼っています）。

最小限の時間を費やして、ニーズに十分合った見積もりを取得してください。公式はありません。

個人的には、1〜2分以上は、おそらく間違ったものを推定している（分割するか、発見を計画している）ことを意味します。

実際には、他の利害関係者が相対的な優先度を割り当てるのを助けるために見積もりが必要です。したがって、少なくともtask1はtask2に比べて約3倍の労力であるという広範なベースの見積もり（時間の観点からは、最終的にはあまり正確ではない場合でも）は有用です。（特定の目標を達成するための）それらのタスクが何であるかを理解するために必要なだけの時間を費やしてから、それらのおおよその見積もりを行います。

相対的な優先度を設定したら、作業に集中し、途中で見積もりを調整します。つまり、事前の見積もりにはほとんど時間をかけないでください。ただし、時間の経過に応じて見積もりを調整して、何が行われるかをプロジェクト計画が適切に判断できるようにします。

良い見積もりは、仮定ではなく事実に基づいたものです。

したがって、すでに同様のプロジェクトがあり、以前の推定時間を取得した場合、それはを開始するための適切な推定ベースとして機能する可能性があります。ただし、プロジェクトのスコープによっては、不明なアーティファクトが存在する可能性があります。BAまたは製品の所有者にできるだけ早く明確にすることをお勧めします。

それはまた言うことは本当です：ソフトウェアプロジェクト推定は本質的に不正確です。ただし、次のような役立つ現実的な見積もり方法があります。

• 作業を行う人は、プロジェクトの見積もりに参加する必要があります
• エキスパートを取り込む：プロジェクトの成功にはエキスパートの判断が不可欠です
• 大きな部分を範囲として推定する
• Delphi手法の使用： これは、ソフトウェアプロジェクトの見積もりに矛盾がある場合に、チームの意見をまとめるのに役立つ方法です。
• コストに注意してください
• 作業を実行するために利用可能な割り当てられたリソースを覚えておいてください