スクラムで、タスクが数時間で見積もられる場合、スプリント計画でタスクを割り当てないようにするにはどうすればよいですか？
私はこの主題について多くを読んでいます、そして私が次のステートメントを集めることができることからスクラムで「すべき」です：
1）製品バックログレベルでストーリーポイントのユーザーストーリーを推定します。これにより、見積もりの抽象化が可能になり、チームは紛争なく一緒に見積もりを行うことができます。ある開発者は別の開発者よりもはるかに速くストーリーを完成させるかもしれませんが、両方の場合、推定は3ストーリーポイントです。
2）理想的には、スプリントの計画中にタスクを割り当てないでください。個人の説明責任には役立ちますが、チームの説明責任を軽減します
3）スプリント計画では、各ストーリーに関連するタスクを具体化し、これらを数時間で見積もります。
私の質問はこれです、どのようにしてタスクを数時間で見積もることができますが、それでもタスクを特定の開発者に割り当てないのですか（ポイント2および3）？確かに、ストーリーポイントを使用する全体のポイントは、専門の開発者が1時間かかると言うのを避け、ジュニア開発者が8時間かかると言うのを避けることです。
現在、スプリント計画内のタスクを数時間で見積もっている場合、見積もりを行った特定の開発者にタスクを割り当てずに、さまざまなレベルの専門知識を持つすべてのチームメンバーに適した見積もりにどのように到達しますか？
ありがとう
Scrum Guide によると、スクラムで真実である必要があると主張するステートメントは、必ずしもスクラムでは真実ではありません。
スクラムによると、ストーリーポイントでユーザーストーリーを推定する必要があるとは限りません。スクラムガイドでは、ユーザーストーリーやストーリーポイントについては触れられていません。スクラムでは、製品バックログ項目を含む製品バックログがあり、製品バックログ項目の属性の1つは見積もりです。ただし、見積もりには多くの方法があり、見積もりは数値である必要さえありません。すべての製品バックログ項目を同様のサイズに分解した場合は、それで十分です。見積もりの目的は、製品所有者が製品バックログを適切に注文するための作業を完了するために必要となる可能性のある作業量を理解できるようにし、開発チームがどの製品を決定することによってスプリントを効果的に計画できるようにすることです。バックログアイテムは、反復で完了する可能性があります。
スクラムは、スプリント計画中に開発チームが作業を割り当てる必要があるかどうかについては黙っています。開発チームは自己組織的であり、スクラムガイドは、スプリントの過程で達成できることとそれがどのように行われるかを決定するのは開発チーム次第であると述べています。要件は、スプリント計画の終わりまでに、開発チームが十分な作業を行って、スプリントタイムボックスの終わりまでに達成できる可能性がある製品バックログ項目を決定することです。一部のチームは、少なくとも暫定的に、すべての作業を割り当てることを好みます。他のチームはスプリントが進むにつれて仕事を引き込むことを好みます。どちらも有効で、どちらにもトレードオフがあります。
スプリント計画では、すべての製品バックログアイテムを分解する必要はありません。製品バックログのサブセットを取得し、それが実行される可能性が高いと予測できるように、作業を十分に分析する必要があります。この作業は、スプリント計画だけでなく、発生する洗練アクティビティ全体（洗練のための特定のスクラムイベントはありません）で実行できます。プロダクトバックログアイテムに見積もりを設定することは、改良の結果であり、ポイント、時間、または値なしで見積もり、プロダクトバックログアイテムのほぼ均一なサイズを単に確保することになります。
それでは、見積もりに移ります。ソフトウェア開発の仕事を見積もるためのいくつかの良い習慣があります。これらのプラクティスの1つは、作業が特定の人によって行われることを想定していません。人々が何かを達成するために費やす時間は人によって異なります。単純に彼らの知識と、仕事をするために必要な一連のスキルに基づいています。チームの専門家が作業を行うと推定するべきではありません。その人が作業を行う人物ではない可能性があるためです。一方、最も熟練していない人が作業を行うかのように見積もると、すべてが過大評価されます。だからあなたは真ん中に何かが必要です。 Wideband Delphi や Planning Poker などの手法は、これを支援するように設計されています。
これは、人々が数時間で見積もることを避ける傾向がある理由の1つでもあります。ここでは2つの考慮事項があります。第1に、誰が作業を行っているかによって複雑さが変わることはほとんどありません。作業も同様に複雑ですが、一部の人々は、複雑さの一部を切り抜けることができる既存の知識とスキルを持っています。第2に、チームレベルで推定する場合、複雑さはチームの努力も考慮しています。より複雑なものには、ペアプログラミング、より集中的なピアレビュー、より多くのテストなどが含まれる可能性が高くなります。
したがって、私の推奨は2つあります。
- コンセンサスに基づく見積もり手法とリスク管理を使用して、適切な見積もりを決定します。見積もりで受け入れようとするリスクのレベルに基づいて、中間点と最高の見積もりの間の何かを見つけます。
- 時間ベースの推定から複雑度ベースの推定に移行することを検討してください。または、代替として、すべてほぼ同じサイズの非常に小さな作業単位。
公式のスクラムの答えは、「時間ではなく複雑さを見積もり、ストーリーポイントを使用する」です。
しかし、実際のところ、見積もりはあなたがやりたくないものではありません。スクラムがどのような影響評価を達成しようとしているのか、いくつかの主要な目的があります。
完了したタスクに関して、ストーリーへの進行状況を測定できます。
これは、タスクが完了するまでに約1日かかることを意味します。あなたは毎日あなたの毎日のスクラムを持っているからです。 2番目の毎日のスクラムでタスクが実行されない場合、問題があることがわかります
完了したストーリーの観点から、プロジェクトの完了に向けた進捗状況を測定できます。
これは、ストーリーが完了するのに1スプリント未満かかる必要があることを意味します。各スプリントの最後に、完成したストーリーをデモするためです。 2回目のスプリントデモでストーリーが完成しない場合、問題があることがわかります
したがって、ストーリーが1日未満のタスクに分割され、1スプリントよりも長いストーリーがさらに分解されている限り、問題はありません。
超高速/低速の開発者がいる場合、これは通常は問題になりません。1時間程度の開発が最も速く、1日程度の開発が最も遅い、非常に小さなタスクがたくさんあるからです。
進捗状況を報告できる限り、進捗率は平均します
スプリント計画では、各ストーリーに関連するタスクを具体化し、これらを数時間で見積もります。
ストーリーをタスクに分割したり、何かを数時間で見積もったりしたことはありません。ストーリーが明確で十分に小さい場合、それなしでスクラムを実行できます。
不可能を実行しようとするのではなく（だれがそれを実行するのかを知らずに数時間で見積もる）、ユーザーストーリーを改善するだけで、タスクはまったく必要ありません。