誰が時間の見積もりに参加する必要がありますか？
ITプロジェクトの場合：
- 誰が参加時間の見積もりに参加する必要がありますか？開発者、チームリーダー、スクラムマスターなど？
- 誰が投票最も数えられるべきですか？
存在する必要のあるスキルほど、関係する人々についてではありません。
問題のドメインをよく理解する-これは、要件があいまいまたは高レベルの場合に特に重要です。飛行機のチケットクラスに関する仕事を見積もるために旅行で働いたことがないプログラマーとして、彼らは3つまたは4つ（経済、ビジネス、最初など）があると想定しますが、旅行で働いたことがある場合は知っているでしょう数十あること。これは、ビジネスアナリストまたはエキスパートユーザーが関与していることを意味する場合がありますが、時間の経過とともに開発者自身がこの種の知識を蓄積していきます。
テクノロジーと関連する作業の理解-通常は開発者ですが、チームに自信を持っている最近の経験を持つマネージャーが仕事をすることがよくあります。理想的には、実際に仕事をする人をそのように見積もることができます。
見積もりプロセスの理解-これが重要です。適切な見積もりを行う方法、それが正しいことを確認する方法、適切なレベルの不測の事態をチェックする方法、二重カウントまたはパディングが多すぎることをチェックする方法を理解する必要があります。通常、PM、開発マネージャー、または上級開発者がこれを持ち込みますが、一部のプロセスでは、堅実な見積もりテンプレートが必要なガイダンスを提供できます。
これらのスキルは1人で行うこともできますが、3人以上が必要になる場合もありますが、重要なのは、特定の人が存在するのではなく、それらのスキルが存在することを確認することです。
とは言うものの、一般的には、2人以上の人がお互いに仕事をチェックしているという追加の保証が必要なため、2人以上を探します。
誰の投票が最も多いかという点では、そのようには機能しません。それは議論と交渉です。マネージャーが開発者の見積もりが高すぎると思う場合、彼は理由を説明し、開発者にそれを正当化するように（圧力ではなく）挑戦する必要があり、彼らはコンセンサスに達する必要があります。あなたがその合意に達することができない場合、私は経験から2つのことを言うでしょう：
（a）あなたが「望む」数と一緒に行かないでください、それは単にトラブルを求めているだけであり、あなたが望むものは仕事がどれだけ速くできるかに重要な影響を与えません。
（b）開発者が見積もりで過大評価されているのを見たほとんどすべての場合、最終的な数値は、主にポイント（a）を無視したため、開発者が過大評価した人よりも開発者の考えに近づいています。上記。
（アジャイルでは、そして確かにXPでは、開発者が見積もりを管理するというルールがあり、それが最終的なものです。ユーザーが見積もりを下げたい場合は、より単純なものの要件を変更する必要があります。）
この質問に対する万能の答えがあるかどうかはわかりません。私が働いている場所では、通常、見積もりを提供する機能/修正を実装するチームから2人のエンジニアがいます。したがって、2人のエンジニアがそれぞれ「最小」、「最大」、「期待」の見積もりを提供します。通常、両方の推定値はかなり一貫していると予想されるため、大きく異なる場合は、さらに議論が必要になる場合があります（おそらく、一方のエンジニアが他方のエンジニアがそうではないと仮定したなど）。
私たちの状況では、誰の「投票」もそのように数えられません。通常、2つの見積もりを平均するだけです（同じ球場にまだいない場合は、両方を拒否して、もう一度話し合いをやり直すので、平均を取ることは大きな飛躍ではありません）。結局のところ、見積もりは単なる見積もりであるため、正確である必要はありません。
私の経験では、見積もりは、タスク自体を実行する可能性が最も高い人によって行われる傾向があります。 SCRUMチームは部門の枠を超えて努力する必要がありますが、しばらくすると、特定の種類のタスクは通常同じ人によって実行されます。
非常に重要なのは、すべての見積もりについてチームから承認を得ることです。開発者が見積もりを所有していると感じた場合、彼らはそれを満たすために働きます。開発者が自分たちでやったことはなく、意見や影響力もなかったという見積もりを受け取った場合、開発者はそれに対して同じレベルの責任を感じず、当座貸越は「もっと時間がかかると言った」と説明されます。
プロジェクトには、ビジネス要件と期限が上から下に向かっています。これらは、最初の反復の「与えられた見積もり」です。
これらの要件は、100％の既知のコストを持つ最大のタスクに分割する必要があります（「ログを有効にする」= 2時間=「ダウンロード log4j / SLF4J そしてプラグイン」など）。
見積もりは、それを行うのに十分な技術的専門知識をすでに持っている可能な限り高いレベルで行う必要があります。
修正された見積もりは、適切なレベルでビジネスオーナーに到達し、要件を削除/変更したり、期限を緩和したりできるようになるまで、「ビジネスに見える機能」=「この時間」の形式で戻る必要があります。その後、元に戻ります。最終的な収束まで。実際には、人々はこのフェーズを無視したり単純化したりする傾向があり、その結果、期限や機会を逃したことに関連するリスクが生じる可能性があります。