テストにおけるスクラムスプリントストーリー
私はスクラムマスターであり、私の組織でスクラムを実践しています。現在、開発のためにServiceNowに移行しており、現在問題に直面しています。
問題：私たちはスプリント->ストーリー->タスクに取り組んでいますが、ストーリーを閉じる前に、クライアント（顧客/利害関係者）がストーリーをテストする必要があるという要件があります。私はプロダクトオーナーとしても活動しています。クライアントはストーリーの承認には使用できますが、テストには使用できません。
お客様の期待に多くの問題があったため、これは新しい要件です。私たちは解決しようとしていますが、スプリントストーリーを開いたままにしておくことは良い選択肢ではありません。提案してください。
あなたがスクラムマスターであり製品の所有者である場合、あなたはスクラムを行うふりをしているプロジェクトマネージャーです。
製品の所有者は、ストーリーを承認し、ストーリーに優先順位を付け、ストーリーを完全なものとして受け入れる権限を与えられたクライアントの誰かである必要があります。これが必要なのは、クライアントがプロセスに関与することを余儀なくされ、何がいつ起こるかを承認および受け入れているため、期待がより厳密に一致する必要があるためです。クライアントがこのレベルに関与することをいとわない場合、スクラムを行うのは非常に困難です。
クライアントの期待を管理するのに役立つ最善の方法は、少なくとも1人の人をもっと関与させ、すべてのストーリーに、あなたとクライアントの両方が理解できる完了の明確な定義があることを確認することです。
クライアントがテストに利用できないという問題が、クライアントがまったく時間を費やすことをいとわないというよりもタイミングの問題である場合は、開発スプリントと並行して「QAスプリント」を実行できます。それは間違いなくより重くて醜いプロセスですが、それを機能させることができます。基本的に、スプリント1を閉じて、QA /ステージング環境に移動し、スプリント2の作業を開始します。その間に、クライアントはスプリント1をテストし、新しいストーリーを作成して、見つけた問題を修正できます。また、これらのことを決定することもできます。スプリント3で行われるのを待つか、スプリント2から何かを取り出してスペースを空ける必要があるかどうかを待つことができます。リリースの準備ができたら、開発を停止し、リリースの構築と以前の開発スプリントの問題の修正に焦点を当てた「リリーススプリント」を用意する必要があります。
お客様の期待に多くの問題がありました
これの根本原因を見つけることは、改善するための最良の方法です。症状は治療できますが、改善は最小限であるか、存在しません。 欲求がよく理解されていませんでしたか？受け入れ基準が不足していましたか？増分は完了していませんか？スクラムフレームワークは関係するすべての関係者に理解されていますか？
各インクリメントは、以前のすべてのインクリメントに追加され、徹底的にテストされ、すべてのインクリメントが連携して機能することを確認します。
スプリントの終了時に、新しい増分は「完了」である必要があります。つまり、使用可能な状態であり、スクラムチームの「完了」の定義を満たしている必要があります。
顧客は完了の定義を定義しません。
開発チームはクロスファンクショナルであり、製品を作成するために必要なチームとしてのすべてのスキルを備えています。インクリメント スクラムガイド
顧客のテストでは、アイテムが完了するのを止めることはできません。
スプリントレビューは、増分を検査するためにスプリントの最後に開催されます スクラムガイド
インクリメントが完了したら、お客様と一緒に確認する必要があります。このイベントからのフィードバックにより、製品バックログに新しいアイテムが作成される可能性があります。
簡単に言うと、バックログ、特にスプリントバックログには、開発チームが完了できるアイテムのみを含める必要があります。これは、スクラムの意味での開発チームです。つまり、スクラムチームのメンバーであるすべての人です。それは実際の開発者、QA、インフラストラクチャ管理者、DBAなどである可能性があります。重要なのは、実際に作業を行うのはこれらの人々であり、さらに重要なのは、スプリント計画と日常業務を行うのはこれらの人々であるということです。
さらに、完了の定義には、開発チームが提供できる項目のみを含める必要があります。 PBIは、開発チームがすべての作業を完了し、合意された完了の定義を満たしたときに実行されます。開発チームだけがスプリントを推進し、すべてのPBIを「完了」させる責任があるため、完了の定義に外部からの影響はありません。
これらの2つのことを考えると、利害関係者のテストと承認は、完了の定義の一部またはスプリントの一部であってはなりません。むしろ、それはリリース計画の一部になります。人々が完全に見逃しているように見えるスクラムの最も素晴らしい側面の1つは、スプリントの後にリリースを続ける必要がないことです。チームは、潜在的にリリース可能な、完成した動作中のソフトウェアの増分を提供しますが、実際にリリースする必要がある場合、またはリリースする必要がある場合でも、条件はありません。人々がスクラムで混乱し始めたところは、一般的にここに来ます。彼らは、ソフトウェアをリリースする際の任意の条件に基づいて、スプリントの目的で何かが「完了」したかどうかに関するあらゆる種類の条件を追加しようとし始めます。
PBIが実行されるかどうかの決定に関係する外力がある場合、毎回スプリントターゲットを見逃すことになります。単純に、あなたは利害関係者を管理しておらず、あなたのスプリントが終わる前に彼らが増分をレビューすることを保証することは不可能です。その結果、スプリントが終了すると、すべてのPBIが「進行中」の列に表示されることになります。