何かをするのに実際どれくらい時間がかかりますか?[閉まっている]

Question

つまり、あなたが行ったプログラミング プロジェクトの名前と、それにどれくらいの時間がかかったのかを教えてください。上司は一度も文句を言ったことはありませんが、時間がかかりすぎると感じることがあります。でもこれは私がせっかちだからかもしれません。比較のためにあなたの経験を教えてください。

また、物事には常に時間がかかり、当初の計画よりもはるかに長い時間がかかることにも気づきました。なぜ計画を立て始めないのかわかりませんが、おそらくそれはモチベーションを高めるためだと思います。

ライアン

Answer 1

単純に時間を計り、見積もりを記録し、平均の割引率を決定するのが最善です。そのため、一貫性があれば、完了すると信じた時期に基づいて実際の時間を適切に見積もることができます。それは単に自分の見積もりがどのくらい下手かを判断するためではなく、むしろ避けられない注意散漫の規則性を考慮することです（個人的なものと上司/顧客ベースの両方）。

これは Joel Spolsky の記事に基づいています。 証拠に基づいたスケジューリング, 、主要な他の重要な側面は、タスクを一口サイズ (最大 16 時間) のタスクに分割し、それらを見積もり、合計して最終的なプロジェクトの合計に到達することであると彼は説明しているので、必読です。

Answer 2

直感に基づいた見積もりには経験が伴いますが、妥当な見積もりを得るには、関連するタスクを詳しく説明する必要があります。

仕様または少なくともいくつかの制約がある場合は、タスク (ユーザー ページの設計、タグ ページの設計、ユーザー ページの実装、タグ ページの実装、タグ クエリの作成など) の作成を開始できます。

これを行ったら、合計して2倍にします。他の人とコーディネートする必要がある場合は、3倍にしてください。

作業中に実際の時間を詳細に記録して、プロジェクトが完了したときにどの程度正確だったかを評価し、見積もりスキルを磨くことができます。

Answer 3

前のポスターに完全に同意します...チームの仕事量も忘れないでください。プロジェクトに 3 か月かかると見積もったからといって、それがそれに近い時間で完了するとは限りません。

私は小規模なチーム (開発者 5 名、リーダー 1 名) で働いており、多くは一度に複数のプロジェクト (大規模なものから小規模なものまで) に取り組んでいます。プロジェクトの優先順位、管理者の気まぐれ、および他のチームの空き状況 (必要な場合) に応じて、プロジェクトの作業が他のチームの中に散在します。

つまり、確かに 3 か月分の作業は無駄になるかもしれませんが、6 か月の期間では 3 か月分の作業になる可能性があります。

Answer 4

私はこれまで 1 ～ 6 か月かけてプロジェクトを自分で実行してきましたが、常に当初の見積もりを 2 倍か 4 倍にする傾向があります。

Answer 5

2 つのプログラミング プロジェクトを比較することは事実上不可能です。要因が多すぎて、その指標だけが別のプロジェクトには適用できないからです (例: 使用されている特定のテクノロジ、開発者のこれまでの経験、要件の変化など)。以前に構築したシステムとほぼ同じシステムを新たに構築する場合を除き、見積もりが正確である可能性は低くなります。

注意すべき点は、同じチームで既存のシステムの次のリビジョンを構築する場合です。得られる特定の経験により、次の作業バッチを見積もる能力が向上します。

私はこれまで数多くの推定手法の試みを見てきましたが、どれもうまくいきませんでした。疑似科学的な魅力はあるかもしれないが、実際には機能しない。

唯一の意味のある答えは、アジャイル支持者が主張するように、比較的短い反復です。短期間で実行できる作業範囲を選択し、それを納品してから、次のラウンドに進みます。その後、予算は短期ベースで割り当てられ、関係者は資金が効果的に使われているかどうかを評価できます。どこへ行くにも時間がかかりすぎる場合は、プロジェクトを放棄することもできます。

Answer 6

ホフスタッターの法則:

「ホフスタッターの法則を考慮した場合でも、常に予想より時間がかかります。」

その理由は次のとおりだと思います。

• 仕事は、それに使える時間を埋めるために拡大します。いくら無慈悲に不必要な機能を削減したとしても、納期がさらに厳しければ、さらに残酷になっただろう。
• プロジェクト中に予期せぬ問題が発生します。

いずれにせよ、人は選択的な記憶を持っているため、逸話を比較することは非常に誤解を招きます。かつて私が完全に最適化されたクイックソートを書くのに 2 時間かかったと言ったら、おそらく私はそのタスクを 1 週間前にやることが分かっていてアイデアを考えていたという事実を忘れているのかもしれません。おそらく、バグがあったことを忘れているのかもしれませんが、1週間後にさらに2時間かけて修正しました。

進行中のプログラミング以外の作業はほぼ確実に省略されます。会議、アーキテクチャ設計、私がたまたま知っていることで行き詰まっている他の人に相談することです、管理者。したがって、「座ってコーディングする」という観点から妥当と思われる作業率を考え、それが常に維持されると期待するのは不公平です。これが、後に「もっと早くすべきだった」という多くの感情の原因になります。

Answer 7

2週間から1年程度のプロジェクトを行っています。一般的に私の見積もりはかなり良いものですが、 事後的に. 。しかし、プロジェクトの開始時には、見積もりが大きすぎるとみなされて、たいていバッシングを受けます。

それは、私が人々が忘れている多くのことを考慮しているからです。

• バグ修正の時間
• 導入の時間
• 管理/会議/交流の時間
• 要件の所有者が考えを変えられるようにする時期が来た
• 等

秘訣は、証拠に基づいたスケジューリングを使用することです (Joel on Software を参照)。

つまり、少し余分な時間を計画しておくと、問題が発生しなければ、その時間をコード ベースの改善に使用できるということです。問題が発生した場合でも、見積もりの​​範囲内に収まります。

Answer 8

ジョエルがこれについて記事を書いたと思います:できることは、チームの各開発者に自分のタスク (実行する必要があるすべての手順は何か) を詳細に説明してもらい、各手順に必要な時間を見積もってもらうことです。後でプロジェクトが完了したら、実際の時間を推定時間と比較すると、各開発者のバイアスがわかります。新しいプロジェクトが開始されたら、時間を再度評価してもらい、それに各開発者のバイアスを掛けて、実際に期待される値に近い値を取得します。

いくつかのプロジェクトを実行すると、非常に適切な見積もりが得られるはずです。