時間の見積もりをどのように扱いますか？
時間をかけすぎると、品質が低下します。時間をかけすぎると、開発者は何があっても、割り当てられたすべての時間を使用する方法を見つけます。見積もりを処理するのに良い方法は何でしょうか？彼らは必要悪ですか？
もちろん、それらは必要ですが、本質的に邪悪ではなく、単にひどく行われています。
適切な見積もりの基本：
1）理想的には作業を行う開発者は、それらの生成に関与する必要があります。
2）見積もりは範囲（通常は最良のケース、最悪のケース、最も可能性の高いケース）であり、単一の値ではありません。範囲を使用して概算できます。単一の値（（最良のケース+ 4 *最も可能性の高いケース+ 2 *最悪のケース）/ 7はそうするための公正な公式です）しかし、それがすべてであることを忘れないでください-概算。
3）私の経験上悪い見積もりの最も一般的な理由は、希望的な考えであり、開発者の側（楽観的である場合、すべてうまくいく） ）またはマネージャー（すべてが迅速に進むのに必死です）。これは戦う必要があります-うまくいっているすべてに基づいた推定はかなり下にあることの証明です。最も可能性の高いケースでは、特定の量のものが意図したとおりに機能しないと想定する必要があります。
4）私の経験では悪い見積もりの2番目に多い理由は、実行する必要があるすべてのことを考えていないことです。それは単なるコーディングではなく、単体テスト、管理者、ユーザーガイド、機能に関連するバックエンドのメンテナンス画面です。タスクを個々のコンポーネントに分割すると、それぞれが1日の4分の1から5日間かかります。そのようなサイズは、妥当なレベルの精度で推定できます。
5）実際にかかった時間を測定し、後で確認し、それを使用して見積もりを改善します。同様の以前のタスクの実績をベンチマークとして参照し、状況が予想よりも高い理由を正当化します。
6）ミクロレベル（各タスク）とマクロレベルの両方で概算します（全体の所要時間を把握してください）。通常、マクロレベルの推定値は低くなります。これは、マイクロレベルの推定値を確認する必要があることを示します（必ずしも変更する必要はありません）。私の経験のスイートスポットは、彼らが同意するか、マクロレベルの推定値がまだ低い可能性がありますが、個々のタスクの推定値を変更する意思がない人です。その時点で、個々のタスクの見積もりを使用します。
7）見積もりと商業的側面を混同しないでください。 100日と見積もり、通常のチャージアウト率が1日あたり1,000ドルである場合、明らかに100,000ドルになるはずです。彼らがそれを請求することができないと言ってビジネスはうまくいきますが、（スコープが変更されない限り）見積もりが変更されない場合、請求率は変わります。
8）開発者は、見積もりに挑戦する必要があります（なぜ何かがそんなに時間がかかるのかを説明するように求められます）が、それらを下げるように圧力をかけられるべきではありません。確かに、数値がいずれの場合でも誰かが望んでいるものではないというだけでなく、正当化できない場合は、通常、より良い内訳と潜在的な2つ目の目のために、しかし対立しない方法でプッシュする必要があります-思い出させるPM（またはPMを覚えている場合）は、プロジェクトが時間どおりに配信されない場合、外観が悪くなるため、見積もりがしっかりしていることに注意してください。
9）偶発事象を追加する必要があります偶発的な偶発事象（通常は10〜20％）と特定のリスクをカバーします。不測の事態は計画する必要がありますが、プロジェクトマネージャーが「所有」します。つまり、開発者がそれに入る必要がある場合、PM）に話しかけ、見積もりを超過している理由を言う必要があります。これは通常、ただ詰める時間を停止し、本物のものの偶発性を維持するのに役立ちます。もし誰かがあなたのたわごとに偶然の予算が発生した場合、それはITプロジェクトの現実にすぎないことを説明してください。次に、それを次回の見積もりの中に隠すことを忘れないでください。
10）（編集）努力と経過時間を混同しないでください。努力は、何かをするために費やされる必要がある合計時間であり、経過は、それが開始するときと終了するときの差です。通常は異なります-管理者、サポート、メンタリング、人生は、1週間で5日間の作業が完了しない可能性があることを意味します。大まかなガイドとして4を取り上げますが、会社やチームメンバーのその他のコミットメントに従って調整してください。
11）（編集-Martin Wickmanから）これまでに行った、または計画している他の作業は、見積もり時に貴重な情報源になる可能性があります。以下のコメントでは、Martinは、相対的な見積もりに言及しています。これは、割り当てられた見積もりが、関係する作業を考慮して比例的に見えるようにするために、同様のタスクを互いに比較することを含みます。 1週間を1つのタスクに、1週間を別のタスクに喜んで割り当てる頻度は驚くべきことですが、2つの点を見ると、一方が他方よりも明らかに複雑です。これは、1つ（または両方）の数値が間違っていることを示しています。これをさらに進めると、完了したタスクとプロジェクトを将来の作業の見積もりへの主要な入力として使用する証拠に基づくスケジューリングにアクセスします。
Steve McConnellがこれについてすべて Software Estimation に書いています。それは少し乾燥していますが、主題に関しては非常に徹底しています。
あなたが言及している現象はパーキンソンの法則として知られており、「仕事はその完了に利用可能な時間を埋めるために拡大する」と述べています。
つまり、人々は締め切りに間に合うように自分のペースで物事を完了する傾向があります。怠惰のせいではないと思いますが、時間よりも常にやらなければならないことが多いので、納品のタイミングに応じて優先順位を付けます。
私の経験では、締め切りのジレンマに対する最善の解決策は、プロジェクトを小さな頻繁な成果物に分割する反復プロセスです。これにより、緊急性が高まり、大きなタスクよりも小さなタスクを推定する方がはるかに簡単になるため、推定を現実的に保つことができます。ただし、開発者に多くの入力を与え、締め切りを管理するように注意してください。 100万件の小さな締め切りを指示するマネージャー=マイクロマネージャー。
いずれにせよ、締め切りは実際のビジネス上の制約によって設定されるべきです。作業にかかる時間の見積もりに基づいて期限を作成することは、定規を使用してそれ自体を測定することにいくらか似ています。
見積もりは必要悪ではありません。それらが悪である場合、それらが必要であるかどうか質問する必要があります。
ソフトウェアエンジニアリングにおける最近の重要な傾向の1つは、Leanソフトウェア開発の哲学、特にKanbanの急増です。そして-メッセンジャーを撃たないでください-リーンとカンバンの支持者はそれを率直に言います：「推定は無駄です。」廃棄物をどうするの？ 「削除する」
（Henrik Kniberg、有名な作者 Scrum and XP from the Trenches がカンバンに入りました。彼の最新の本 Lean from the Trenches =は間もなく発表されます。本の中で、彼はストーリーポイント、相対的なサイズの見積もりは時間の無駄だと主張しています。）
推定の代わりに彼らが行うことは巨大な別のトピックですが、その要点は、variabilityを採用し、ユーザーにとって価値ある機能のflowを最適化し、 リードタイム個々のタスクの実行にかかる時間を制御する代わりに、リードタイムまたはスループットについてシステム全体を最適化します。
ユーザー要件が特定されてからユーザーに配信されるまでのユーザー要件の過程を視覚化すると、実際にコードを入力する必要がほとんどないことがわかります。開発段階であっても、進行中の作業項目が次の場合、多くの時間が失われる可能性があります。
- ブロック状態（エスカレーションプロセスはどの程度効果的ですか？）
- すぐに利用できないリソースを待つ
- 他のボトルネックの徹底
- 再加工
超効率的ではないソフトウェア開発チームは、上記の原因のいずれかで数日を無駄に（顧客に関する限り、それはすべて無駄です）、簡単に5日かかる可能性があります。いくつかの機能をコード化する2は、あらゆる価値を追加します。機能のリクエストから配信までの45日間のうち、コーディングなどにどのような順序で費やされたかは、お客様が気にしないことを覚えておいてください。
類推を使用すると、アメージングレースの出場者は、最初にフィニッシュに到達することによって価値を追加します。彼が1キログラムの地元の食べ物を食べるのにかかる時間を推定することは、付加価値のある活動ではありません。
あなたが職場でこの考え方を実行できるかどうかはわかりませんが、これは有用な視点だと思います。
Delevopersは、あなたではなく、自分の仕事の見積もりを作成するものでなければなりません。 （または言い換えると、自分の仕事だけを見積もる必要があります。）
時間と経験により、特に自分の見積もりを追跡する場合に、より正確に見積もりを行うことができます。
プログラミングの本当の問題は、特定の言語の特定のプロジェクトで、ルーチンの機能要求に対して非常に正確な見積もりを提供できる可能性があることです。しかし、多くの場合、これまでに行ったことのない（そしておそらくあなたが知らない言語で、そして/またはあなたが知らないフレームワークで）何かについて見積もりをしなければなりません。その場合、あなたの見積もりは何らかの形で推測です。とにかく推測してみて、見積もりを追跡し、反映してください。
簡単な答え：相対的な見積もりを使用し、頻繁に出荷する。これは基本的に、Extreme Programmingメソッドで使用されるアプローチです。基本的な手順：
- チームは、一般的にユーザーの観点から書かれた、前進するすべての有用なステップのリストを作成します。 （例：「お客様がカートに商品を追加しました」）。
- 製品マネージャーはリストを優先度でソートし、リリースマーカーを挿入します。 （例：「最初の内部アルファ」、「最初のパブリックベータ」）。
- 開発者は、重要な最小のアイテムを選びます。彼らはそれを1ポイントと呼んでいます。
- 開発者はそれに関して他のすべてを推定します。大きすぎるもの（8ポイントなど）は、より小さな部分に分割されます。
- 開発者は一度に1つずつ機能を構築し、少なくとも週に1回は動作するシステム（つまり、誰かが銃を頭に置いた場合にリリースできるもの）を作成します。
- チームは毎週、完了したポイントを数え上げます。来週、彼らはほぼ同じ量を引き受けようとします。彼らがそのすべてを早期に完了した場合、彼らはより多くを行うことを選ぶことができます。
- 製品マネージャーが特定のリリースの見積もりを求めている場合、彼らは毎週の速度を調べ、リリースのポイントを数え、計算を行うことができます。
これは単純すぎるように聞こえるかもしれませんが、私や他の多くのチームにとって非常にうまく機能しています。特に、プロダクトマネージャーは次の作業を調整することでスケジュールを完全に制御できるため、スケジュールのプレッシャーはもはや開発者にとって問題ではありません。ビジネスの人々は、優先順位やスケジュールについて好きなだけ議論することができ、コーディングを続けることができます。
JP Lewisの「ソフトウェアの見積もりに対する大きな制限」を読んで理解する必要があります。
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.4205
http://scribblethink.org/Work/kcsest.pdf
http://scribblethink.org/Work/Softestim/softestim.html
一般にプログラムのコードを読み取って停止するかどうかを決定できないという事実とは異なり、一般に、要件を読み取ってそれらを実装するのにかかる時間を決定することはできません。これは議論の余地があるとは思わない。
アジャイルパラダイムについての言及がないことに驚いています。プロジェクトでアジャイルを使用して、作業を小さな扱いやすいチャンクに分割しました。各チャンクはいくらか見積もるのが簡単で、通常は1週間以上の作業ではありません。毎日のスクラムにより、管理者や他の開発者は、何かがタイムフレームを超え始めていることを知ることができます。プロジェクトを毎日分析して、プロジェクト全体を完了するための全体的な「競争」のどこにいるかを常に把握できるようにします。何かがあなたを引き留めるなら、経営陣は総締め切りの何日前かを見つけられません、あなたはそれが来るのを見ます。
- 履歴分析を行って、チームがどれだけ時間を見積もったかを把握し、改善を試みます。
- .
追加する機能に応じて、開発者または技術リーダーがプロジェクトの時間を見積もります。この時間がはるかに長い場合は、機能/機能を削減するために、彼らと話し合う必要があります。見積もりも、開発者によって異なります。初心者は、エクスペリエンス開発者が完了するのと同時にジョブを完了することはできません。したがって、そのようなことを考慮に入れるべきです。そして、要件が常に変化しているためか、開発者は常に時間をかけています。
完成したプロジェクトはコードのセットではありません。完了したプロジェクトは、特定の時点での一連のコードです。顧客/ユーザーがコードを取得するタイミングを気にしない場合、それはおそらくそれほど重要ではありません。