誰が時間の見積もりに参加する必要がありますか？

ITプロジェクトでは：

1. 誰が時間の見積もりに参加する必要がありますか？開発者、チームリーダー、スクラムマスターなど？
2. 誰の投票が最もカウントされるべきですか？

参加する必要があるスキルとして、関係する人々についてはそれほどではありません。

• 問題領域の十分な理解-これは、要件があいまいまたは高レベルの場合に特に重要です。飛行機のチケットクラスに関する作業を見積もるために旅行で働いたことのないプログラマーとして、彼らは3または4（経済、ビジネス、最初など）があると想定しますが、旅行で働いたことがあれば、十数あること。これは、ビジネスアナリストまたはエキスパートユーザーが関与していることを意味しますが、時間の経過とともに開発者自身がこの種の知識を蓄積していきます。

• テクノロジーと関与する作業についての理解-通常は開発者ですが、最近の経験があり、チームに自信のあるマネージャーが仕事をすることがよくあります。理想的には、実際に仕事をしている人をそのようにして、彼らが見積もりに入れられるようにすることができます。

• 見積もりプロセスの理解-これが重要です。適切な見積もりを行う方法、適切であることを確認する方法、適切な偶発性のレベルを確認する方法、二重カウントまたは余計なパディングを確認する方法を理解する必要があります。通常、PM、開発マネージャー、または上級開発者がこれを提供しますが、一部のプロセスでは、確実な見積もりテンプレートが必要なガイダンスを提供します。

これらのスキルは1人でもかまいませんが、3人以上が必要になることもありますが、重要なのは、特定の人がいるのではなく、それらのスキルが存在することを確認することです。

とは言っても、一般的に私は2人以上の人を探しますが、2人以上の人がお互いの作業をチェックするという追加の保証が欲しいので。

誰の投票が最も多くカウントされるかという点では、そのようには機能しません。それは議論と交渉です。開発者の見積もりが高すぎるとマネージャーが考える場合、マネージャーは理由を説明し、開発者にそれを正当化するよう要求する（圧力ではない）必要があり、コンセンサスに達する必要があります。あなたがその合意に到達できない場合、私は経験から2つのことを言います：

（a）「ほしい」という数字は使わないでください。問題を求めているだけであり、必要なことは、作業を迅速に実行できるかどうかに実質的な影響を与えません。

（b）開発者が見積もりに支配されたほとんどすべてのケースで、最終的な数値は、主にポイント（a）を無視したため、それらを支配した人よりも開発者が考えたものに近づいています。上記。

（それはアジャイルだと私は信じています、そして確かにXPでは、ルールは開発者が見積もりを制御することであり、それが最終的なものです。ユーザーが見積もりを下げたい場合、より単純なものの要件を変更する必要があります。）

この質問に対する万能の答えがあるかどうかはわかりません。私が作業している場所には、通常、見積もりを提供する機能/修正を実装するチームのエンジニアが2人います。したがって、2人のエンジニアがそれぞれ「最小」、「最大」、および「予想」の見積もりを提供します。私たちは通常、両方の見積もりが合理的に一貫していると予想します。したがって、それらが大幅に異なる場合は、さらに議論が必要になる可能性があります（おそらく、1人のエンジニアがもう1人のエンジニアがそうではないと仮定したなど）。

私たちの状況では、誰の「投票」もそのようにカウントされません。通常、2つの推定値を平均するだけです（それらがまだ同じ球場にない場合は、両方を拒否し、最初からやり直すため、平均を取ることは大きな飛躍ではありません）。見積もりは結局のところ見積もりにすぎないため、正確である必要はありません。

私の経験では、推定は、タスク自体を実行する可能性が最も高い人によって行われる傾向があります。SCRUMチームは部門を超えて機能するように努力する必要がありますが、しばらくすると、特定のタイプのタスクは通常同じ人によって行われます。

非常に重要なことは、すべての見積もりについてチームから承認を得ることです。開発者が見積もりを所有していると感じた場合、開発者はそれを満たすために努力します。開発者が自分でやっていなかったとの意見や影響がなかったという見積もりを手に入れられた場合、開発者はそれに対して同じレベルの責任を感じることはなく、当座貸越は「もっと時間がかかるだろう」と説明されます。

プロジェクトには、ビジネス要件と期限がトップダウンで設定されています。これらは、最初の反復の「所定の推定」です。

これらの要件は、100％の既知のコストを持つ最大のタスクに分割する必要があります（「ログの有効化」= 2時間=「log4jのダウンロード/ SLF4Jとプラグイン」など）。

推定は、それを行うのに十分な技術的専門知識をすでに持っている可能な限り高いレベルで行う必要があります。

修正された見積もりは、「ビジネスに表示される機能」=「この時間」の形式で遡って、ビジネスオーナーに適切なレベルで到達し、要件を削除または変更したり、期限を緩和したりする必要があります。それから戻ってください。最終的な収束まで。実際には、人々はこのフェーズを無視するか、単純化する傾向があり、そのため、締め切りや機会を逃したことに関連するリスクが生じる可能性があります。

誰または誰が時間推定に参加する必要がありますか？開発者、チームリーダー、スクラムマスターなど？

私は時間の見積もりにすべての人がいることを好み、ここでも同じことをします

誰または誰の投票を最もカウントする必要がありますか？

開発者ですが、チームワークについてのすべてが再び

開発者はプロジェクトの実装を担当しました！ほかにだれも！

実際に実際に作業する開発者と開発チームのリーダーだけが、実際にかかる時間を適切に見積もることができます。実際のコードベースに精通しているプログラマーのみが、開発の過程で遭遇する可能性のある潜在的な困難と落とし穴を理解することができます。他の誰もが「見物人」です。

さらに、正確な見積もりを提供するために開発者を信頼できる唯一の方法は、ビジネスの人々がそれらを信頼し、専門家に頼って、見積もりがビジネスの期待に合わない場合に罰せられないことを開発者が知っている場合です。

経験則：プロジェクトマネージャーまたはビジネス担当者の見積もりが、開発の実践の課題と問題のコードベースに精通していない場合、少なくとも3倍かかります。

私は、20年近くフリーランスおよび大企業の従業員の両方でハンズオンデベロッパーとして働いてきた人物として、これを最大限に確実にそして多くの苦い経験の恩恵をもって言います。