あなたが行ったプログラミング プロジェクトの名前と、それにかかった時間を教えてください。上司は文句を言ったことはありませんが、時間がかかりすぎると感じることがあります。しかし、これは私もせっかちだからかもしれません。比較のためにあなたの経験を教えてください。
また、当初の計画よりも物事が常に長く、時にははるかに長くかかるように見えることにも気付きました. なぜ計画を立てないのかはわかりませんが、おそらく動機付けのためだと思います.
ライアン
1169 次
8 に答える
7
単純に時間を計り、見積もりを記録し、オフの平均パーセントを決定するのが最善です。そのため、一貫性がある限り、完了できると信じていた時期に基づいて実際の時間を適切に見積もることができます。見積もりがどれほど悪いかを判断するだけではなく、避けられない気晴らしの規則性を考慮に入れることです（個人的および上司/クライアントベースの両方）.
これは Joel Spolsky のEvidence Based Schedulingに基づいており、重要な読み物であり、他の重要な側面は、タスクを一口サイズ (最大 16 時間) のタスクに分割し、それらを見積もり、追加して最終的なプロジェクトに到達することであると説明しています。合計。
于 2008-09-21T21:08:00.063 に答える
2
私は以前のポスターに完全に同意します...あなたのチームの仕事量も忘れないでください。プロジェクトに3か月かかると見積もったからといって、その近くでプロジェクトが完了するとは限りません。
私は小規模なチーム（5人の開発者、1人のリード）で作業しています。私たちの多くは、一度に複数のプロジェクトに取り組んでいます。プロジェクトの優先順位、管理の気まぐれ、および他のチームの可用性（必要な場合）に応じて、プロジェクトでの作業は他のチームの間に散在します。
ですから、そうです、3か月分の仕事は死んでいるかもしれませんが、6か月の期間で3か月分の仕事になるかもしれません。
于 2008-09-21T21:14:57.317 に答える
2
直感に基づく見積もりには経験が伴いますが、合理的なものを得るには、関連するタスクを詳細に説明する必要があります。
仕様または少なくともいくつかの制約がある場合は、タスクの作成を開始できます (ユーザー ページのデザイン、タグ ページのデザイン、ユーザー ページの実装、タグ ページの実装、タグ クエリの作成など)。
これを行ったら、それを追加して2倍にします。他の人と調整する必要がある場合は、3 倍にします。
進行中に実際の時間を詳細に記録して、プロジェクトが完了したときにどれだけ正確であったかを評価し、見積もりスキルを磨くことができます。
于 2008-09-21T21:03:15.813 に答える
1
2つのプログラミングプロジェクトを比較することは事実上不可能です。これは、からのメトリックが別のプロジェクトにのみ適用できないことを意味する要因が多すぎるためです（たとえば、使用される特定のテクノロジー、開発者の以前の経験、要件の変化）。以前に構築したものとほぼ同じ別のシステムを打ち抜かない限り、見積もりが正確になる可能性は低くなります。
注意点は、同じチームで既存のシステムの次のリビジョンを構築する場合です。得られた特定の経験は、次の作業のバッチを見積もる能力を向上させます。
私は推定方法論であまりにも多くの試みを見てきました、そしてどれもうまくいきませんでした。彼らは疑似科学的な魅力を持っているかもしれませんが、実際には機能しません。
唯一の意味のある答えは、アジャイルの支持者によって提唱されているように、比較的短い反復です。短い時間枠内で実行できる作業の範囲を選択し、それを提供してから、次のラウンドに進みます。その後、予算は短期的に割り当てられ、利害関係者は自分のお金が効果的に使われているかどうかを評価できます。どこかに行くのに時間がかかりすぎる場合、彼らはプロジェクトを捨てることができます。
于 2008-09-21T21:12:26.917 に答える
1
ホフスタッターの法則：
「ホフスタッターの法則を考慮に入れても、常に予想よりも時間がかかります。」
これは次の理由によると思います。
- 作業は、それを実行するために利用可能な時間を埋めるために拡張されます。不必要な機能をどれほど冷酷にカットしていても、締め切りがさらに厳しければ、もっと残酷だったでしょう。
- プロジェクト中に予期しない問題が発生します。
いずれにせよ、人々が選択的な記憶を持っていることもあって、逸話を比較することは本当に誤解を招きます。完全に最適化されたクイックソートを作成するのに2時間かかったことがあると言えば、1週間前にそのタスクを実行することを知っていて、アイデアを考えていたという事実を忘れているのかもしれません。たぶん、1週間後にさらに2時間かけて修正したバグがあったことを忘れています。
私はほぼ確実に、進行中のプログラミング以外の作業をすべて除外しています。会議、アーキテクチャ設計、私が知っていることに固執している他の人への相談、管理者。ですから、「そこに座ってコーディングする」という点でもっともらしい仕事の割合を考え、それが常に持続することを期待するのは不公平です。これは、あなたが「もっと速くなるべきだった」という事実の後の多くの感情の源です。
于 2008-09-21T22:41:21.663 に答える
1
私は自分で 1 ～ 6 か月のプロジェクトを行ってきましたが、常に当初の見積もりの 2 倍または 4 倍になる傾向があります。
于 2008-09-21T20:58:54.187 に答える
0
Joelがこれに関する記事を書いたと思います：あなたができることは、チームの各開発者に彼のタスクを詳細にレイアウトするように依頼し（実行する必要のあるすべてのステップは何ですか）、各ステップに必要な時間を見積もるように依頼することです。後でプロジェクトが完了したら、リアルタイムと推定時間を比較すると、各開発者のバイアスがわかります。新しいプロジェクトが開始されたら、時間をもう一度評価するように依頼し、各開発者のバイアスを掛けて、実際に期待される値に近づけます。
いくつかのプロジェクトの後、非常に良い見積もりが得られるはずです。
于 2008-09-21T21:15:59.077 に答える
0
私は2週間から1年までのプロジェクトを行います。一般的に、私の推定は非常に良好であり、事後確率です。ただし、プロジェクトの開始時には、見積もりが大きすぎると見なされるため、通常、私はバッシングを受けます。
これは、人々が忘れている多くのことを考慮しているからです。
- バグ修正の時間
- 展開の時間
- 管理・会議・交流の時間
- 要件の所有者が考えを変えることを許可する時が来ました
- 等
その秘訣は、証拠ベースのスケジューリングを使用することです (Joel on Software を参照)。
問題は、少し余分な時間を計画している場合は、問題が発生しなければコードベースを改善するために使用します. 問題が発生した場合でも、見積もりの範囲内です。
于 2008-09-21T21:04:39.197 に答える