スクラムでは、誰が「完了」を検証しますか？

私は組織のQA /テストマネージャーであり、今日までソフトウェアの品質を確認しました（テストの作成と実行、バグの修正）。誰がスクラムでこれを検証しますか？チームがすべての適切なテストを作成して実行したことをどのようにして知ることができますか？一方、私が検証を続けた場合、チームは十分な権限を与えられているとは感じないでしょう。しかし、「完了」が実際に「完了」であるという検証プロセスが必要です。何を指示してるんですか？

スクラムの大きなアイデアの1つは、チームが「完了の定義」に同意する必要があるということです。理想的には、これは誰もがチェックリストを調べることで検証できる客観的な基準のセットのようなものです。

しかし、何かがすり抜ける可能性を減らすために、「実行」を検証することは、アイテムを実装した人またはあなたのような指定されたQA以外の人によって実行されるというルールを持つことは完全に理にかなっていますボトルネック）。

疑問がある場合は、チームとスクラムマスターと話し合い、一緒に決定します。

この質問には暗黙的な仮定があると思います。プロダクトオーナーがバックログアイテムまたはタスクがプロダクトオーナーを満たしていると宣言した場合の「承認済み」と、バックログアイテムに関連付けられたすべての作業が完了したことを意味する「完了」には違いがあります。

ただし、タスクには通常、製品所有者に見えるものよりも多くのタスクがあります。通常、テスト、文書化、およびレビュー（自動および手動）を含め、通常はせいぜい半技術者です。プロダクトオーナーが技術的な側面を理解できる立場にあることはめったにありません。完成したかどうかは言うまでもありません。

したがって、「完了」の意味を判断するのは最終的にチームの責任です。組織には標準があり、さまざまな利害関係者に独自の要件があります。通常、スクラムマスターまたは関連するマネージャーが、リストの照合と実施を担当します。

あなたの例では、QA /テストマネージャーとして、あなたはテストが完了したかどうかを言う人です。ただし、コードがレビューされたか、セキュリティ要件が満たされているか、製品が国際化されているか、ドキュメントが完全であるか、またはその他の「完了」を構成するかどうかを言うのに最適な人ではない場合があります。

「完了」の唯一の概念は、ストーリー全体が完成したかどうかです。チームは、いつストーリーが終了したと感じるかを示すdoneの定義を作成する必要がありました。これには通常、「コードがレビューされた」、「夜間テストが実行された」、「すべての受け入れ基準が満たされた」などのことが含まれます。彼らが物語を終わらせることを期待した。

スプリント中に、doneの定義にあるこれらの項目のいずれかが達成されたかどうかを判断しようとしている場合は、質問してください。スクラムとアジャイルは、オープンなコミュニケーションに関するものです。あなたがチームの一員である場合、チームメートにテストを書いた人がいるかどうか、テストを実行したか、夜間の仕事を作成したかなどを尋ねてください。

チームの外に座ってテストを確認する必要がある場合は、doneの定義の一部として「テストはユーザーuser3251930がレビューする必要があります」をチームに追加してもらいます。それが物語を成し遂げるのに必要なものであるなら、それについて正直であり、それをプロセスの一部にしてください。「完了の定義」の要点は、チームが品質の高いソフトウェアを提供するために必要なことを行ったことを確実に知ることができるようにすることです。その一部が外部レビューである場合は、そうしてください。

最終的に、特定のストーリーを承認するのは製品所有者であるため、最終的にはストーリー全体が完了したかどうかについて最終決定を下します。

最初の質問

あなたはスクラムマスターですか？もし、そうなら。

スクラムのプロセスは、スクラムマスターによって制御および管理されます。

どうやってやるの？

要件フェーズでは、検証が必要なテストがあるそれぞれに対してユーザーストーリーを使用できます。

各スプリントでは、作業項目は製品バックログから取得され、製品所有者によって指示されます。各作業項目には検証基準もあります。

これで、スプリントの開始後にスクラム要件が変更されることはありません。スプリントの最後に、完了した各アイテムの基準に従って検証を分析できます。

その完了がプロダクト所有者の応答によってのみ見つけられる場合。

アジャイルでは、開発フェーズの後半でも「変更を受け入れる」ことを忘れないでください

チームが決定します。「完了」と見なされるものにチェックリストを使用します。ストーリーごと、スプリントごと、リリースごとの「完了」

他の人が述べたように、最終的に決定は製品の所有者にあります。

これは、開発/テストチームが独自のプラクティスに応じて定義する必要があるものであることに同意します。一部のプロジェクトは非常に機敏であるため、アルファストリームにバグをリリースするリスクがあります。一部の開発者は、開発グループ外のバグをプロセス障害と見なします。

私が取り組んでいるプロジェクトでは、コード変更のピアレビューが必要であり、コードを書いた人は誰でも回帰テストを提供/更新するか、それができない理由を説明する必要があります。（彼らとそのレビュアーはまた、既知の悪い慣行をチェックしたことを証明する必要があります。彼らが完全なテストスイートを実行し、クリーンな結果（または既知のモジュロをクリーンな少なくとも未解決の問題）その後、コードは複数のプラットフォームでの集中的な自動ユニットおよび機能テストに耐え、それらに対してリグレッションを引き起こさないことを実証する必要があり、自動コード分析システムによって一般的なアンチパターンがさらにチェックされます。次に、それをメイン開発ストリームに受け入れ、ワークアイテムを完了としてマークします。

これは明らかに、失敗する新しい方法を誰も見つけられないことを保証するものではありませんが、開発の速度を大きく妨げることなくリスクを許容可能なレベルに減らします。