私はPHP開発者であり、何日も、ましてや何時間も、何かが仕事にかかる時間についてはよくわかりません。私はよく新しいものを書いていて、それを古いレガシーのがらくたとマージしています。上司に、何かが行われる可能性が高い週、そしておそらくその週の半分を伝えることはできますが、世界でどのようにして、何かが行われる日を具体的に知ることができますか？バグやその他の未知のものが頻繁に発生し、時間を浪費することを考えると、それは少し非現実的ではありませんか？私はこれらのものをそんなに最小化することしかできません...
私は次のように言うことを考えています：
「ほら、明日」と言っているのがわかります。明日！」は役に立ちません。私が取り組む多くのことであなたのためにできる最善のことは、与えられた週のどの半分がそれを終える可能性があるかをあなたに伝えることです。与えられた週の金曜日なら、次の週に移ったほうがいい」と語った。
時間の見積もりは難しいです。
しかし、私がこれをうまくやったときは、すべて共通点がいくつかあります。
1.）プロジェクトの非常に優れた完全な要件を受け取りました。これは重要であり、要件が実際に可能な限り完全であることを確認するために難しい質問をする必要があります。
2.）プロジェクトをセクションに分割し、各セクションをホワイトボードに書き込んでから、各セクションの完了までの時間を個別に見積もりました。私はこれを行うときにチームの他のメンバーに貢献してもらいましたので、何も忘れません。これはとても単純に見えますが、とてもうまく機能します。時間のかかるプロジェクトの一部を見落とす可能性を減らすことで、より現実的になると思います。このようにプロジェクトを詳細に書き留めて計画することができれば、非常に役立ちます。
この全時間の見積もりプロセス中に、プロジェクトと何をする必要があるかについての理解を深めることができます。これにより、間違いやコードの記述と書き直しなどを防ぐことができます。これはすべての人にとって良いことです。
思い切って、50％の時間を追加してください。あなたは締め切りに間に合い、ストレスを感じることはありません。あなたの上司は速いコードよりも質の高いコードを見るでしょう、そしてあなたはたまに予想よりも速くなるでしょう。誰もが勝ちます:)
より良い見積もりは経験から得られます。
また、ファンクションポイント分析法を使用して、適切な出発点を取得することもできます。次に、プロジェクトマネージャーに定期的な更新を提供します。したがって、プロジェクトが来週に入る必要がある金曜日に、プロジェクトマネージャーは驚かないでしょう。
にも違いがあります
何かをするのに必要な時間の見積もりについて：
しばらくして、「それを行うのにどれくらい時間がかかりますか？」と尋ねられたとき、あなたは考えることができるでしょう：
時間が経つにつれて、あなたはこれでますます良くなるでしょう; そして、最終的には、おそらく次のことができるようになります。
ホー、そして私は忘れました：私は通常、バグのテストと修正のために「開発時間」の約15％を追加しますが、これは私が取り組んだプロジェクトの標準レートであり、一般的に非常に正確です（もちろん、初心者の場合） 、おそらくより多くのバグを作成する人は、もう少し追加します;経験豊富な開発者の場合は少し少なくなります）。
はい、もちろん、時々、あなたは完全に間違っているでしょう; それは起こります、それはそれです：誰もがたまに間違いを犯します:-)
遅延について：まあ、私は一般的に上司に「他に何かをする必要がなければ、X日かかるはずです」と言います。それで、上司が私の仕事の途中で2日間何か他のことをするように言ったら、それは「彼のせい」です^^
一人でプロジェクトに取り組んでいるとき、または「自分の上司」であるとき、私は一般的に「他のもの」にどれだけの時間を費やす必要があるかを知っています。
少し前に取り組んだプロジェクトで、「これを行うには5日必要ですが、通常、計画されていない作業に半分の時間を費やしていることを考えると、合計で10日かかると考えてください」とクライアントに伝えていました。 -しばらくすると、このように数えることに慣れます^^
マーフィーの時間管理の法則：
何かにかかる時間を把握するには、どれくらいの時間がかかるかから始めます。
次に、これに2を掛けます。
次に、次に高い時間単位に移動します。
したがって、プロジェクトに1日かかる場合、おそらく2週間かかります。
すべての回答とフィードバックをありがとうございます。
この質問をしてからしばらく経ちましたが、それ以来、スクラムとアジャイル手法を使用して時間の見積もりスキルを大幅に向上させました。ホワイトボードとスクラムを使用し、時間どおりにチャンクで配信します。
プロジェクト全体がいつ納品されるかについては、プロジェクトの規模によっては、納期は不明です。ただし、タスクをストーリーとサブタスクに分割することで、プロジェクトの規模を把握できます。これにより、納品の期待が現実的であるかどうかを経営陣に示すことができます。
さらに、タスクのバックログがあると、スプリントごとに継続的に優先順位を変更できます。これにより、最も優先度の高い問題が確実に完了します。最終的に、バックログの残りのアイテムは重要ではなく、製品はリリースに「十分」です。
これまでのところ、うまく機能しています。
詳細：http ：//www.scrumalliance.org/pages/what_is_scrum、http ：//www.goodagile.com/scrumprimer/。
自分の回答を回答としてマークして申し訳ありませんが、これが私にとってうまくいったことです。
私の経験から（マネージャーとアソシエイトの両方の側にいた）、ほとんどのマネージャーは、従業員からの見積もりを次のレベルまで報告していないことを知っています。代わりに、彼らは彼ら自身の直感と外部の制約についての知識によって行きます。
マネージャーが見積もりを依頼するとき、アソシエイトが分析を行い、サブタスク、主要なギャップ、依存関係などを把握することよりも、見積もり値自体を気にしないことがよくあります。言い換えると、見積もりを依頼することは、多くの場合、経営陣が従業員を動かすために採用するトリック。この場合、推定値は、従業員に分析を強制するための依存性注入メカニズムにすぎません。
もちろん、トリッキーなマネージャーは、特にそれが過小評価されていた場合は、見積もり値を覚えて、プロジェクトの緊急度を制御するためにそれを使用する傾向があります。
私ができる最善のアドバイスは、タスクをより小さな部分に分割し、それらを見積もることです。楽観的および悲観的な範囲を計算するために、各サブタスクに「信頼度」のパーセントを付けることができます。そうすれば、上司が「5〜8日ですか？それはまったく役に立ちません。これらの数字はどこで思いついたのですか！？！？」あなたは彼にあなたの内訳を示すだけで、あなたには正当性があります。有能なマネージャーは、あなたがコミットするためにいじめられるためにあなたが逸脱するものではなく、あなたがコミットするもののためにあなたの尻を置くべきです。
これを改善するための1つの方法は、元の見積もりを追跡し（最初は暗闇で撮影する必要がある場合）、実際にかかった時間を追跡することです。あなたはそれがどれほど「難しい」か、そしてそれが最初に1から10のスケールで言われるだろうとあなたが思ったどれほど難しいかを推定したいかもしれません。
しばらくこれを行うと、パターンが見え始め、見積もりがどのように良い/悪い（相対的な用語）であるかを理解し始めるかもしれません。
時間が経つにつれて、これらを使用して見積もりを再考するのに役立ててください。たとえば、過去数回、中程度の難易度（たとえば、10のうち5）の5日間のタスクを推定しましたが、平均して5日間休みました。
それで私はこれで10日を見積もり、何が起こるかを見るつもりです。:)
この演習を継続的にやり直すと、これをより適切に処理できるようになります。
ああ、そうです、すでに述べたように、見積もりは難しく、そこにはたくさんのリソースがありますが、練習や本当に良いメンターのようなものはありません。:)
見積もりについてのいくつかの考え：
Steve Mcconnell（別名Mr Code Complete）によるすばらしい本へのリンクは次のとおりです： http ： //www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=ntt_at_ep_dpt_3-Software Evaluation Demystified
基本的な手順は次のとおりです。
完了する必要のある項目、質問、前提条件、および可能な納期の範囲を含む話し合うドキュメントは、プログラミングの成熟度のレベルに大きく影響します-日数/週数（または単にsnide remark）そして決して近づくことはありません。上司がそれを理解していない場合は、新しい上司を見つけてください。
可能であれば、別の仕事を見つけてください。上司は、プロジェクト管理、リソース管理、ソフトウェア開発について何も知らないようです。
一般的に、あなたが与えることができるのは見積もりだけです。あなたの見積もりは経験を積むことでより良くなるでしょう（ほとんどの場合、あなたは今日よりもはるかに多くの努力を見積もるでしょう）。そして-sw開発者なら誰でも知っているように、実際の努力の90％以上を要する（そして開発時間を大幅に増やす）愚かな問題にぶつかるオプションが常にあります。
私は一般的に、私が実際に思っているよりも3〜4倍長くかかると言います。たとえば、2日で何かを作れるとわかっていれば、1週間かそこらと言います。
そうすれば、あなたがあなたの推測された時間よりかなり下で終えるならば、あなたは英雄のように見えるでしょう！：P
多くの場合、過去の経験と履歴データが見積もりを提供するのに最適です。履歴データを使用して将来のタスクを予測する前に、同様のコード/問題を処理したことがある場合。もちろん、新しいものやまったく未知のものを扱っている場合、正確な見積もりを提供することは困難です。もちろん、それらは「見積もり」であり、物事がいつ行われるかについての知識に基づいた推測です。
私は2つのことをします：