タスクを見積もるときに開発者の数を考慮する必要がありますか？
アジャイルプロジェクトでの作業にはかなりの経験がありませんが、何度か試してみましたが、タスクを見積もるときは常にこの問題に遭遇します。
タスクに取り組む開発者の数を見積もりに取り入れますか？
説明させてください：タスクAは1時間単位と推定され、開発者1が作業します。タスクBも1時間単位と見積もられ、開発者2と3が一緒に作業します。
つまり開発者1がタスクAで同時に作業を開始した場合、開発者2と3がタスクBで作業を開始すると、推定に従ってすべてが同時に完了します。
タスクBの見積もりは、タスクAの見積もりの2倍か、それとも同じですか？
私が見るところの問題は、タスクを受け取って見積もったときに、何人がそれに取り組むかを常に知ることができるとは限らないということです。また、2人の開発者が1つの時間単位でタスクに取り組むことを想定していても、実際には1人の開発者だけがそれを行うことが判明しても、その開発者が2つの時間単位でタスクに取り組むことを自動的に意味するわけではありません。
これに対する標準的な方法はありますか？
見積り時には、開発者の数を考慮しないでください。ただし、開発者のスキルは必要です。
最初は、タスクの複雑さを考慮する必要があります。これはすべて相対的であるため、タスクAはタスクBの2倍難しいが、タスクCよりも30％簡単であることがわかります（たとえば）。
次に、これらの複雑さの値を取得したら、工数（または工数）を割り当てる必要があります。これwill開発者のスキルによって異なります。タスクAは、経験豊富な開発者の場合は2時間かかる場合がありますが、ジュニア8の場合もあります。繰り返しになりますが、many開発者がタスクに割り当てられる方法を無視しています。
開発者を割り当てる場合、工数を人数で割るだけではありません。オーバーヘッドがあります。タスクに追加する各人は、実際に人を追加するとタスクが長くなるところまで、チームの全体的な効率を低下させます。
複数の人が実行できるタスクがある場合は、見積もりが高すぎることをお勧めします。タスクを細かい作業に分割するようにしてください。このようにして、質問は「なくなり」、他の優先順位に応じて作業を順次または並行して実行できるため、スケジュール（および通信）が容易になります。
短い答え;いいえ、開発者の数が見積もり活動へのインプットであるとは思いません。ただし、@ ChrisFからの回答とは対照的に、開発者のスキルや「複雑さ」の他の側面が推定アクティビティへの入力になるとは思いません。
この質問に対する私の（かなり長い）回答を参照してください。 ユーザーストーリーを再推定する必要がありますか？ ここで、複雑さと推定に関する私の見解について説明します。
開発者の数、開発者のスキル、およびその他の複雑さの側面（言語の選択、利用可能な既存のコードライブラリなど）はすべて、タスクにかかる時間に寄与する要因ですがタスクのサイズを変更しないでください。これは、見積もりで測定することを目的とすべきものです。
別の例（その別のスレッドの例の上に）;次のようなユーザーストーリーがあります。 「ボタンをクリックすると、許可されていないユーザーにエラーメッセージが表示されるボタンが必要です」。さて、あなたのチームはこのタスクを「小さい」と推定し（少なくとも私の場合はそうです！）、それはあなたのバックログに入ります。 3人の開発者からなるチームは、このタスクを達成するために1つのスプリントを取ります。 10人の開発者の別のチームは、これが彼らの最初の仕事であり、7人が共通の言語を共有していないため、タスクを達成するために2つのスプリントを取るかもしれません。一方、リード開発者は、以前にそれを実行し、いくつかのトリックを知っているため、このタスクを達成するために自分で1/2スプリントを取ります。
これらの3つの異なる期間（1、2、1/2スプリント）の終わりに、あなたは何を持っていますか？ [考えて、考えて...]正解です！ボタンを押すと、権限のないユーザーにエラーメッセージが表示されます。このタスクのサイズ-これらの3つのチーム間で変更はありません。まったく同じ出力を生成しました。ただし、開発プロセスの他の要因が、時間に関連する結果に影響を与えています（そして、おそらく品質、コードの再利用、およびその他の素晴らしいこと）。
この方法で推定すると、速度測定にはるかに効果的に反映されます（チーム1の速度は良好、チーム2の速度は不良、チーム3の速度は素晴らしい）。これで、開発プロセスの他の側面を調整して、より良い結果を得ることができます。チーム1に2〜3人の開発者を割り当て、チーム2を小さなチームに分割して経験を追加し、チーム3にメンタリングジョブを提供して、他のチームが改善できるようにします。
一方、複雑さやチームの能力を見積もる場合は、速度を歪め、問題がどこにあるかを隠します。代わりに、チーム1がタスクを「中」、チーム2が「大」、チーム3が「小」と推定したと想像してください。これらの推定値にそれぞれ10、20、5の速度スコアを割り当てます（たとえば）。
1回のスプリントの後、チーム1は10ポイントを獲得し、チーム2は0ポイントを獲得し（タスクが完了していないため、2回のスプリント後に20ポイントを獲得します）、チーム3は5ポイントを獲得します（おそらく、彼が収まるようにさらに5ポイントを獲得します）。彼のスプリントへの別の小さなタスク）。これらの不自然な例からわかるように、すべてのチームの速度はほぼ同じになります。その後、速度を改善する方法はありません。このように見積もると、時間の抽象化された見積もりだけが得られます。
このアプローチをさらに複雑にする-複雑に思われるものは、後で遅くなることはありません（フレームワークコードを追加した後、開発者のスキルアップなど）、または複雑になる可能性があります（フレームワークコードは扱いにくいため、経験豊富な開発者はチームを去ります。等）。したがって、一貫性を維持するために、スプリントごとにタスクを再見積もりする必要があります。つまり、バックログ内のすべて（または多く）のタスクを再見積もりして、効果的に優先順位を付けることができます。これは、すべて無駄な時間です。アクティビティでは、すべてのチームが同じ警告で同じボタンを作成しています。
したがって、要約すると、複雑さ、開発者のスキル、チームサイズなどはすべて、サイジングアクティビティではなく、計画アクティビティの一部を形成する必要があります。そうすれば、チームがより多くのことを達成したい場合は、チームのメトリックを調整できることは明らかです。時間を調整することはできません。
[〜＃〜]更新[〜＃〜]
以下のコメントに対する私の回答は少し長いので、ここでは更新形式にしています。
「ボタン」ストーリーに関して;私はちょうど私のポイントを説明するために単一の作品を表すことができるいくつかの任意の物語を思いついた。別のチームはこれをより大きなタスクと見なすかもしれません。
ストーリーのサイズの見積もりは、製品の所有者と開発中のシステムのコンテキスト（バックエンド、組み込み、GUI、Webなど）に依存します。どのように、いつではなく、whatが配信されているかという観点でサイズを見積もることを目指します。私の例の場合、成果物はボタンとダイアログです-「小さい」サイズは私に見積もります。同様に、成果物をセキュリティフレームワークと見なすことができます。ifそれ自体が、POが何らかの認識された価値を獲得する成果物です（例：「シングルサインオンのサポートが必要です。私たちのウェブサイトなので、たくさんのパスワードを覚えておく必要はありません」）。
問題を解決するためにどれだけの作業が必要かを判断するために、いくつかの抽象的な値（スクラムのストーリーポイントに似たもの）を使用することをお勧めします。チームのすべての開発者は、毎月最低限貢献する必要があります（たとえば、ジュニア開発者は最低20の「ポイント」に相当するソリューションを提供し、上級開発者は約50を提供する必要があります）。プロジェクトの価値のある合計ポイント数とチームが提供できる月間ポイント数がわかれば、すべてのタスクを完了するのにかかる時間を見積もることができます。
あなたはそれを早い段階で一連のステップに分解したいと思っています。最初のステップは見積もりです。これは、優先アジャイルユニットでのタスクのコストを見積もります。
開発者は、スプリントごとに特定の数のユニットを処理できます。これは、開発者によってスキルレベルに応じて異なります。スキルレベルは、技術的な能力だけでなく、コードやビジネスドメインに精通していることなどです。
私がこれまで言及していないことの1つは、少しの作業のコストを見積もっていて、複数の開発者がそれに取り組んでいると思う場合、おそらくストーリーを十分に小さなストーリーに分割していないということです。