2

スクラムとユーザー ストーリーについて簡単な質問があります。

私は大学向けの小さなプロジェクトに取り組んでおり、スクラムとユーザー ストーリーを使用して機能に取り組むことにしました。スクラムは通常、一連のチーム メンバーで行われることを知っていますが、私の場合は、プロジェクト スーパーバイザーと一緒にこれを 1 人で行っています。

ユーザー ストーリーと、ポインティング システムと優先順位システム (Must、Should、Could、Wont) の内容を理解しています。

イテレーションの終わりに近づいているときに来て、ユーザー ストーリーの約半分が完了したとしましょう。

私のユーザーストーリーの例は次のとおりです。

「ユーザーは機器を記録できる必要があります」

このユーザー ストーリーの小さなサブタスクを作成しました。1 つのサブタスクを除いてすべてのサブタスクに到達し、イテレーションの最後に到達しました。このユーザー ストーリーの評価は 8 です。

  • このユーザー ストーリーをバーンダウン チャートに含めることができるかどうか、またはチャートに追加する前にサブタスクが完了するまで待つべきかどうかはわかりません。

  • また、ユーザー ストーリーで完了したタスクの数に基づいてバーン ダウン チャートを作成することはできますか、それともテストなどを含めて完全に完了したユーザー ストーリーの数に常に基づいて作成することができますか?

    前もって感謝します！

4

2 に答える 2

2

スプリント バーンダウンとリリース バーンダウンの 2 つの伝統的なバーンダウン チャートがあります (どちらもスクラム自体には必要ありません)。

このユーザー ストーリーをバーンダウン チャートに含めることができるかどうか、またはチャートに追加する前にサブタスクが完了するまで待つべきかどうかはわかりません。それはあなた次第です。リリース バーンダウンの目的は、何が残っているかを理解することです。その機能は出荷できないので、それについて信じられないほど明確にしてください。これが続く場合は、原因を突き止めてください。

速度 (完全に完了することができた経験的な量) は、次のスプリントで何を予測する必要があるかを知るのに役立ちます。このスプリントは部分的にしか完了していないため、経験主義は、その量の作業を再び予測しないことを示しています.

また、ユーザー ストーリーで完了したタスクの数に基づいてバーン ダウン チャートを作成することはできますか、それともテストなどを含めて完全に完了したユーザー ストーリーの数に常に基づいて作成することができますか? チームが伝統的に残りを合計するスプリント バーンダウンタスクまたはタスク時間は、スプリント予測 (上または下) を再交渉する必要があるかどうかを理解するのに役立ちます。

スプリント外でタスクをバーンダウンしようとすることはお勧めしません。リリース レベルでタスクをバーンダウンし、何が残っているかを理解するには、多くの細かい詳細を見積もる必要があります。問題を解決する方法は、現在の信念から変わり、それにかかる時間も変わります。また、間違いなく、現時点でやろうと思っていることをすべて実行するわけではありません。

于 2012-11-07T01:57:17.793 に答える
1

いくつかのヒント：

バーンダウン チャートは、特定の日のスプリントに残っている推定作業時間の量を表すため、スプリント以外のものは含めないでください。通常、ストーリーは、チーム メンバー (この場合はあなた) によるストーリーに付随する労力とリスクを反映したポイントで評価されます。ストーリーがタスクに分割される場合、それらのタスクは通常、時間単位で見積もられます。ベスト プラクティスは、タスクが次のデイリー スクラムまで 1 日または時間以上かからないようにすることです。

あなたの質問の根底にある質問は、「スプリントが終了したときに、私が完了したストーリーの部分を数えることができますか?」かもしれないと思います. 残念ながら答えは「いいえ」です。スクラムを使用する最善の方法は、ストーリーを完成させることについて非常に白黒であるということです。それは完全に「完了」するかどうかです。中間点はありません。チームにとって何を意味するかは、それが前もって定義されており、動く目標ではない限り、チーム次第です。私の場合は、QAメンバーを審査員として「出荷可能な品質」であれば完了というルールを採用しています。

ストーリーが出荷可能でない場合、50% 完了か 99% 完了かに関係なく、失敗したことになります。部分的なクレジットはありません。これが発生した場合、ストーリーはポイントで再見積もりされ、バックログに戻され、プロダクト オーナーは次のスプリントのためにそれを取り戻すかどうかを確認する機会を得ます。また、ストーリーの見積もりを再評価する絶好の機会でもあります。8 ポイントのストーリーは、通常の規模のチームでは大きく、1 人のチームでは大きすぎます。チームのターゲット ストーリー サイズは、理想的には約 2 ～ 5 ポイントです。最後に、8 ポイントのストーリーを完了できなかった場合は、ベロシティが高すぎて、次のスプリントでポイントを減らす必要があることを示しています。

于 2012-11-17T03:20:49.403 に答える