「スプリント中」の受け入れはアジャイル/SCRUM における有効な概念ですか?[閉まっている]

Question

閉まっている. 。この質問は 意見に基づく. 。現在回答を受け付けておりません。

---

この質問を改善したいですか? 事実と引用で回答できるように質問を更新します。 この投稿を編集する.

閉まっている 2年前.

私はアジャイル スクラム チームの一員としてソフトウェア製品のリリースに取り組んでいます。スプリントの期間は 2 週間 (~10 日) です。

ここでは「」と呼ばれる独特の指標が使用されています。スプリント途中の受け入れ'。基本的に、スプリント内のスクラム チームによってコミットおよび計画されたユーザー ストーリー ポイントの半分が、そのスプリントの途中までに完了する必要があることが期待されます。これにより、ポイントが直線的にバーンダウンし、スプリントが順調に進んでいることを示す強力な指標となる、と彼らは言います。

チームとしては、スプリント中の承認は通常悪いですが、スプリントの終わりまでにコミットされたすべてのユーザー ストーリー ポイントを完了することが知られています。

次のような質問があります。

1) スプリント途中での受け入れは有効なアジャイル/SCRUM プラクティスですか?他の場所でも使われているのでしょうか？

2) 仕事の半分が半分の時間で完了すると期待することは、目の前にある仕事の性質と複雑さが完全に決定的である「工場現場」の仕事としてそれを扱うことに似ています。ソフトウェア開発は「創造的な」プロセスであるため、アジャイルのような柔軟性の高い方法論におけるそのような厳格な指標は無関係です。どう思いますか？

3) 私のスクラム チームはスプリントに間に合うようにすべてのコミットメントを完了しましたが、スプリント中の受け入れ指標が不十分であることが疑問視されています。他の場所のスクラム チームでは、スプリントの終わり近くになってのみコミットメントを達成するのはまったく普通のことなのでしょうか?

よろしくお願いします。

Answer 1

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

スプリント途中での受け入れについてはこれまで聞いたことがありません。それが有効なアジャイル/スクラム実践であるとは思えません。 このサイト 「チームが作業にコミットすると、プロダクトオーナーは作業を追加したり、スプリントの途中でコースを変更したりすることはできません。 細かく管理する."

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

あなたが述べた理由により、厳格な指標は一般に開発者に使用するのは良い考えではありません。また、開発者は、高品質の製品を作ることよりも、測定対象が何であれ合格点を獲得することに興味を持つ可能性が高くなります。これはジョエル・スポルスキーのバグベアの 1 つです - ここ, ここ そして ここ

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

成功したスクラム チームは、スプリントの終わりまでに約束したことをすべて完了している必要があります。バーンダウン チャートは、この目標に向けた進捗をガイドするために表示される必要があり、スプリントの後半では、スプリントが成功する可能性が高いかどうかが確実に示されます。私が関わった成功したスプリントでは、ユーザー ストーリーの完了に向けて着実に進歩するのが通常ですが、これを半分の時間で半分のユーザー ストーリーを完了することには反映できません。そのため、この種の指標は使用しないことをお勧めします。

Answer 2

進行中の作業の量を制限しようとしましたか。チーム全員がいくつかのストーリーに集中し、それらのストーリーが終了するまで先に進まないようにすると、バーンダウンがより直線的になるのがわかるはずです。

ストーリーのサイズにも注目する価値があるかもしれません。私は個人的に、最初から最後まで完了するまでに数日以上かかるストーリーを見るのは好きではありません。

Answer 3

それはスクラムの実践ではありません。これは指標として解釈できますが、悪い指標です。あなたの疑問に関しては、あなたの言う通りです。

スクラムには、バーンダウン チャートという進行状況を追跡するための完璧なツールがあります。任意のマイルストーンを追加する必要はありません。

あなたの経営陣はスプリントの基本概念を理解していないようです。カウンセリングを受けるか、基本的なトレーニングを受ける必要があります。それでも 1 週間以内に何を完了するかが管理にとって重要である場合は、代わりにスプリントの長さを半分に減らすことを提案してみてください。

Answer 4

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

はい、そうです。

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

タスクを非常に小さなタスクに分割すると、仕事の進化の適切な指標を達成できます。したがって、タスクを 1 勤務日で完了するように設計すると、バーンダウン メトリックを適切に使用できるようになります。あなたが言ったように、予測不可能な長さのタスクがある場合、バーンダウン指標は無関係です。

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

問題はチームではなく、タスクの設計にあります。問題はタスクの粒度に関するものです。チームはスプリント時間指標でジョブを完了できますが、スプリント時間半ばの指標でタスクの 50% が完了するようにタスクを調整する必要があります。タスクを小さなタスクに分割すると、目的の (線形) バーンダウン チャートを実現できます。

Answer 5

標準的ではない用語ですが、マネージャーの言っていることには一理あります。

終わりが多いバーンダウン チャート (つまり、チャートの大部分で高い状態が続き、最後に突然減少する) は、タスクの粒度が粗いプラクティスを示しています。完了するまでにスプリント全体がかかり、個々の開発者によって達成されます。このパターンでは、スプリントの終了直前まですべてのタスクが未完了のままになります。

それは本来あるべき動作ではありません。バックログが優先順位に従っているのであれば、なぜ最も優先度が高くない問題に取り組んでいるのでしょうか?さらに、これにより各タスクの「バス番号」が非常に低く設定されるため、スプリントの終了までにタスクが未完了のままになるリスクが大幅に増加する可能性があります。

これを修正するには、タスクをさらに小さなチャンクに分割する必要があります。プランニング ポーカーを行っていて、タスクが 8 ポイント以上と推定される場合、そのタスクは指定されていない可能性があります。それは壊れなければなりません。可能であれば、2 秒と 3 秒 (またはそれより短い時間) に留めるようにしてください。このようにして、複数の開発者が同じ全体的な目標に向けて独立して作業することができ、同じ作業を行っている場合でも、バーンダウン チャートがより滑らかになり、リスクが少なくなるはずです。

Answer 6

ミッドスプリントの受け入れはアジャイル実践ではないか、実際には機能しません。各ユーザー ストーリーとタスク (ラリーなど) を正確に見積もっていれば、バーンダウン チャートはスプリント作業が計画に沿っているかどうか、時間内に完了できるかどうかを明確に示します。承認は、タスクではなく、ユーザー ストーリーの開発とテストの終了時にのみ行われます。