開発者がペアプログラミングを行っているアジャイルストーリーの見積もりをどうしますか？
1人で2ポイントのストーリーであった場合、ペアリングしている場合は2倍にしますか？
ペアリングは必ずしも開発タスクの100％で行われるとは限らないため、ストーリーポイントを2倍にするのは間違っているようです。そして、最後までペアリングが必要なタスクの量が明確でない場合があるため、ストーリーが完了するまでストーリーのポイントがわからないため、スプリントの途中で見積もりを変更するのはおかしいようです。
ただし、速度がスプリント中に達成できる作業量の正確な表現になる場合、複数の人がタスクに取り組んでいる場合、推定値を変更することは正しいようです。しかし、また、これは管理オーバーヘッドの多くを追加するようです。
考え？
私の理解では、ストーリーポイントは相対的な労力の見積もりであり、工数ではありません。ストーリーに必要なeffortは、ペアが作業しているからといって変更されることはないので、ストーリーポイントが変更されても意味がありません...
また、速度は前のスプリントで行われた履歴から導出されます。一部のストーリーでペアリングし、他のストーリーではペアリングしない場合、平均速度は、チームのペアリングの習慣を自動的に考慮して、平均スプリント容量を反映します。次のスプリントで特定のタスクをペアリングする予定であると思う量に基づいて、スプリントの見積もりを手動で調整する必要はありません。
実際、数字のすべての「ゲーム」のために、誰も「推定」を信頼しないため、スクラムの取り組みが失敗する原因となるのは、これらの手作業によるものです。
TL; DR
ストーリーポイントは、チームが全体としてストーリーを「開始」から「終了の定義」に移行するための作業の見積もりです。ストーリーに複数のスキルセットや複数の人が関与しない場合は、ストーリーではなくタスクがあるはずです。
ストーリーポイントは工数見積もりではありません
ストーリーポイントは、相対的な努力の尺度です。
If FOO is a baseline 2-point story
And BAR is roughly twice as much work
Then BAR is a 3-point or 5-point story.
スクラムでは、通常、製品バックログがストーリーポイントで推定されますが、個々のタスクをスプリントバックログで推定する必要があるかどうかについて意見が分かれることがあります。スプリントバックログタスクを見積もる場合、ストーリーポイントではなく理想的な時間を使用できますが、概して見積もりは工数ではなく実時間に基づいています。
スクラムチームは自己組織化タイムボックスを使用します
工数の見積もりは通常、チームが完全に自己組織化していない「プロジェクトの匂い」です。効果的なスクラムチームは、チームが各スプリント内で必要に応じてリソースをタスクからタスクにシフトできるため、俊敏です。
チームがペアプログラミングを採用している場合、またはストーリーで複数のチームメンバーが特定のタスクに集中する必要がある場合、チームはそれらの要素をストーリーポイントの見積もりとスプリント計画の両方に組み込む必要があります。スプリント計画の間、スクラムチームは各ストーリーをプロダクトバックログからはがし、それを見積もり、ストーリーが現在のスプリントに適合するかどうかを判断しようとします。
「完了の定義」に到達するために必要なチームの努力は、工数を測定するよりも、このタイプの評価のためのより正確なツールになる傾向があります。ただし、チームはプロジェクトの成功につながるあらゆる指標を使用する必要があります。
一般的に言えば、重要なのは、タスク実行者（開発チームなど）が見積もりを行えるようにすることです。工数の見積もりは、タイムボックスプロセスに効果的な見積もり手法を提供するのではなく、チームの見積もりプロセスに外部から課せられる予算ツールになる傾向があります。スクラムは 100％の使用率の誤り ではなく、タイムボクシングに基づいているため、最初から使用率を測定するように設計された手法を回避することをお勧めします。
チームとプロジェクトはそれぞれ異なるため、走行距離は確かに異なる場合があります。
これについてフォローアップするには...
私は先週スクラムコンサルタントと面会し、彼にこの質問をしました。 1つのストーリーでペアプログラミングを行う場合、予想されるのは、多くの/すべてのストーリーであるレベルのペアプログラミングを行っているため、工数の作業の過不足は時間の経過とともに均一化され、速度に影響を与えないはずです。
別の回答ですでに述べたように、ストーリーは通常、相対的なサイズで推定されます。したがって、違いはありません。
特定のストーリーをペアにする必要があると考えているという事実は、それらが他のストーリーと比べて複雑さのレベルが異なることを示しており、推定にもっと力を入れることを検討する必要があります。
あなたがコメントで言うように、あなたのチームはペアプログラミングの価値に納得できないようです。それをどのように変更するかについて考える必要があります。ペアプログラミングのみを使用する場合と使用しない場合の両方を試用することを検討してください。もちろん、それは決定的なものではありませんが、チームの理解を深めるのに役立ちます。
TDDはペアプログラミングの促進に本当に役立つと思います。最初にテストを考案する方法は、ペアが目標を簡単に決定するのに役立ちます。
（TDDを使用した）ペアプログラミングは誤った経済であることがわかりました。隠れたバグが蓄積して、バグを修正する必要があるために故障して何も提供されなくなるまで、速度が速くなりました。
ペアでプログラムした場合、速度は15％遅くなりましたが、各リリースの終わりに、あるクラスのバグを完全に排除しました。より予測可能でした。
TDDでペアプログラミングを行うには、規律が必要です。そして、規律を守ることは難しいことを私たちは皆知っています。あなたのチームはなりたくないかもしれませんが、あなたは彼らを説得する必要があります。