スプリント中のスプリントバックログの変更について混乱
私は最近スクラムについてたくさん読んでいて、スプリント中にスプリントバックログを変更しても大丈夫かどうかについて、矛盾しているように見える情報を見つけました。 スクラムに関するウィキペディアの記事 は問題があると言っており、さまざまな 他の記事 もこれを言っています。また、ソフトウェア開発の教授がスクラムの概要について同じことを教えました。
しかし、私は Scrum and XP from the Trenches を読み、タスクボード上の予定外のアイテムのセクションについて説明します。次に Scrum Guideを調べました。 そして、スプリント中に「スプリント目標に影響を与える変更は行われません」とスプリント目標の議論で「作業が開発チームの予想と異なることが判明した場合、彼らは製品オーナーは、スプリント内でスプリントバックログの範囲を交渉する必要があります。」
スプリントバックログは、進行中の変化がデイリースクラムで理解できるように十分に詳細な計画です。開発チームはスプリント全体でスプリントバックログを変更し、スプリント中にスプリントバックログが発生します。この出現は、開発チームが計画を実行し、スプリント目標を達成するために必要な作業についてさらに学習するときに発生します。
新しい作業が必要になると、開発チームはそれをスプリントバックログに追加します。作業が実行または完了すると、推定残り作業が更新されます。計画の要素が不要と判断された場合は削除されます。スプリント中にスプリントバックログを変更できるのは開発チームだけです。スプリントバックログは、開発チームがスプリント中に達成することを計画している作業の非常に目に見えるリアルタイムの画像であり、それは開発チームにのみ属します。
したがって、この時点で私は完全に混乱しています。考えてみれば、2つ目のアプローチを取る方が理にかなっています。バックログ内の個々の特定のアイテムは、私には最も重要なことではないように見えますが、むしろスプリントの目標なので、スプリントの目標を変更するのではなく、バックログを変更できることは理にかなっています。たとえば、製品の所有者とチームの両方がストーリーについて同じページにいると思っていたが、スプリントの進行中に誤解があることがわかった場合、それに応じてそのストーリーを構成するタスクを変更することは理にかなっているようです。または、忘れられていたが、スプリントの目標を達成するために必要なストーリーまたはタスクがあった場合、スプリント中にバックログにストーリーまたはタスクを追加するのが最善だと思います。
ただし、スプリントのバックログを変更しても問題がないことを強く主張する人はたくさんいます。どういうわけかその立場を誤解していますか？スプリントバックログを定義している人々は、どういうわけか違うのですか？スプリントバックログについての私の理解は、スプリントバックログは、ストーリーとそれらが分解されるタスクの両方で構成されるということです。
とにかく、この問題についてのご意見をいただければ幸いです。私は、スプリント中にスプリントバックログを変更する理想的なスクラムアプローチとは何か、および開発にスクラムをうまく使用している人々がスプリント中にスプリントバックログを変更できるかどうかを理解しようとしています。
最初に、私はそれについて厳しいルールを持ちませんでした。スクラムの要点は、状況に適応できるようにすることです。したがって、どうしても必要な場合（重要なことを忘れた場合など）は、スプリント中にスプリントバックログを変更できるはずです。
しかし、スプリント中のスプリントバックログに対するこの変更には抵抗する必要があります。スプリントが短いのは、プロジェクト全体のタイムライン（複数のスプリント）に影響を与えずに、新しい作業を次のスプリントに追加できるということです（正しく優先順位が付けられた後）。
ただし、このスプリントのタスクの1つで作業が重要な場合は、2つのオプションがあります。
- 新しいアイテムをスプリントに追加します。
[〜＃〜] but [〜＃〜]同等のサイズのアイテムをスプリントから削除します。 - 不適切に計画されたアイテムをこのスプリントからドロップします（次のスプリントで適切に計画できるようにします）。
- （適切なサイズの）代替を、製品バックログの上部から追加します（これは、スプリント計画会議からの優先順でなければなりません）。
- または、すべてのスプリント項目が完了したら、開発者が製品のバックログからたるみをピックアップできるようにします。
だから私はあなたがおそらくスプリントバックログを変更すべきではないということをキャンプにいます。ただし、例外的な状況が発生する可能性がある状況を考慮する必要があります。ほとんどの場合、私はオプション2を使用し、バックログからタスクを使用して開発者にタスクのスラックをピックアップさせます。
次に、次の計画会議で、新しいタスクが適切に分析され、スプリントに（必要に応じて）追加されます。
スプリントは短く、開発サイクルの終わりではなく、次のドロップの印にすぎないことを覚えておいてください。製品の所有者は、次のスプリントが終了するのを待てない機能に非常に必死でなければなりません。
混乱は曖昧な言葉によるものです。
スプリントバックログには2つの詳細レベルがあります。まず、チームが提供することを約束したアイテム（ユーザーストーリー）のリストです。第2に、チームがこれらの各ストーリーを提供するために行うのは、すべてのタスクです。
したがって、人々がスプリントバックログについて話すとき、彼らは彼らが何を意味するかについて本当に明確でなければなりません。スクラムガイドを読むと、次のように書かれていることがわかります。スプリントバックログは、スプリント用に選択された一連の製品バックログアイテムであり、製品の増分を提供し、スプリント目標を実現するための計画です。
したがって、製品バックログ項目のリストとそれらを提供するための計画（タスク）の両方です。
現在、多くのチームはスプリントの最初に提案されたすべてのタスク（計画）を追加して、残り時間に基づいてバーンダウンチャートを追跡できるようにしています。他のチームは、必要に応じてタスクを出現させます。これは、「スプリントバックログ」に追加しても問題ないときです。チームは、アイテムを配信し、スプリント目標を達成するために検査および適応するためにそれを行う必要があるためです。
特定の状況下では、チームがスケジュールよりも進んでいる場合があり（チームの機能を向上させる可能性のある他のすべての有用なタスクを排除した場合）、プロダクトオーナーと協力して別のストーリー（優先順位とサイズが既に設定されているはず）を選択する場合があります。製品バックログ...ただし、そのスプリント内で完了し、スプリントの目標に沿っていると確信している場合のみ。
だから、私たちはそれを持っています。はい...チームは、必要に応じてタスクをスプリントバックログ計画に追加します。いいえ、通常、スプリントの範囲を定義するバックログアイテムのリストには追加されません。
これで状況が明らかになればいいのですが。
それはあなたの状況に依存します。計画中に一部の情報が欠落していて、後でいくつかのストーリーにいくつかのポイントを変更または追加する必要があることがわかった場合は、問題ないと思います。しかし、はい、機能のスコープが完全に変化する場合、それは極端な状況であり、別の方法で処理する必要があります。
ただし、もちろん、計画中は、作業する各機能について誰もが明確に理解し、話し合うことが前提となっています。ディスカッションと計画が適切であれば、ほとんどすべてのケースで、変更を実際に行う必要はありません。
私は答えに同意します。ストーリーが発展し始めたら、それが完了するまで止めることはできないと指摘します。
早い段階でかかとを掘ります。変更を求める人は難しい方法を学ばなければならないでしょう。さもなければ、人々があなたがとにかく好きなことをすることができることを人々が学ぶなら、あなたは計画を無駄にしてしまうでしょう。
品質は焦点から生まれ、バグは一連の思考を落とすことから生じることを引用します。コンテキスト切り替えのコストを挙げてください。借金を追跡し、中途半端な仕事に取り組むためにストーリーを書いて話し合い、プレイインする管理はコストがかかります。このルートから始めないでください。
アイデア：妥協策として各四半期に費やす3つの切り替えクレジットを経営陣に与える。