スプリント中に欠陥が発生したり、ストーリーで指摘されて開発者に割り当てられるべきですか？
現在のスプリントで開発されたストーリーをテストする場合、問題は発生せず、完了しません（つまり、完了の定義が満たされていません）。別の無関係な問題を見つけた場合にのみ問題を発生させる必要があると聞きました。開発者がスプリントの終わりまでまだ取り組むことができる何かについて問題を提起しないことを意味します、私はいくつかの「ベストプラクティス」を見つけることができません。それは正しいアプローチですか？
それはあなたのプロセスに依存します。私の世界では、欠陥はあなたの品質慣行から逃れるものです。しかし、それらが何であるかを正確に定義するのはあなた次第です。
一部のプロセスでは、開発チームとテスト/品質チームが明確に分離されています。これが私が今住んでいる世界です。開発チームは単体テストと統合テストを担当し、品質チームは成果物レベル（アプリケーションとシステムレベル）の回帰テストと受け入れテストを担当します。この環境では、開発チームがテストで発見できなかった問題は、開発チームの品質活動（コードレビューとテスト）から逃れたため、欠陥として記録されます。
アジャイル手法は、高度に統合された部門間チームを促進します。この環境では、品質活動も統合されました。さまざまな人々がさまざまな活動を主導しているかもしれませんが、全員が道のあらゆる段階に関与しています。そのため、開発チームから品質チームへの明確な引き継ぎが常にあるとは限りません。このように、私は欠陥をイテレーションの終わりとリリースに至るまでのものと考えます。
ただし、考慮すべきことはコミュニケーションです。最初の例では、テストで見つけたマイナーな問題に気づくかもしれませんが、開発サイクルで修正するために必要なパスがありません。欠陥を記録して、問題を発見したことを通知し、それを処分することができます。プロジェクトリーダーまたは品質チームは、それが実際に（顧客にとって、または製品品質の観点から）大事なことであり、開発サイクルで修正されることを要求するか、または今後のリリースで計画される場合があります。
最終的には、製品の品質を理解し、適切な関係者に開発作業の現在の状態を伝達できるようにするために、正しいことを行う必要があります。
アジャイル開発の重要な価値の1つは、機能するソフトウェアを提供することです。つまり、提供する機能が正しく機能していることが確認されています（チームによる機能の理解に基づいて）。
テスト中に問題が見つかった場合、いくつかの可能性があります。
- この問題は、現在開発中の機能またはストーリーの1つに関連しており、問題が解決されないと品質基準に従ってストーリーを提供できないほど深刻です。
- 問題は、現在開発中の機能またはストーリーの1つに関連しており、問題が修正されない場合でも品質基準に従ってストーリーを提供できるほど深刻ではありません。
- この問題は、現在開発中のストーリーとは無関係であり、影響はありません。
＃1の場合、チームとして、スプリントが終了する前に問題を修正するようにしてください。そうでなければ、あなたは仕事を終えたと言うことができません。バグ追跡システムのチケットが必要かどうかは、地域の慣習とトレーサビリティの要件によって異なります。
＃2または＃3の場合、問題は製品所有者に報告して、製品バックログに入れて優先順位を付けることができるようにする必要があります。バグ追跡システムのチケットが再度必要かどうかは、地域の慣習と製品のバックログの管理方法によって異なります。
（特に＃2の下のアイテムは、「地獄が凍ったときに実行する」という優先順位を取得する可能性があることを覚えておいてください。
スクラムガイド はこれに関するいくつかのガイダンスを提供します
増分は、スプリント中に完了したすべての製品バックログ項目の合計と、以前のすべてのスプリントの増分の値です。スプリントの最後に、新しい増分は「完了」でなければなりません。つまり、使用可能な状態であり、スクラムチームの「完了」の定義を満たしている必要があります。
したがって、スクラムを実践するチームは、製品が機能の予期しない回帰に苦しむことを故意に許可してはなりません。また、インクリメントが「使用可能な状態」であり、スクラムチームの「完了」の定義を満たしている場合を除き、新機能の既知の欠陥を禁止する必要があります。
また
スクラムチームが成熟するにつれて、「完了」の定義が拡張され、より高い品質のためのより厳しい基準が含まれるようになると予想されます。 1つの製品またはシステムには、実行される作業の標準である「完了」の定義が必要です。
スクラムを使用すると、進行中の作業と本番コードのバグを管理するための独自のプロセスをスクラムチームが作成できます。これは、mostソフトウェア開発のような複雑なドメインには「ベストプラクティス」がないためです。実験を行い、成功する傾向のあるものを選択した結果として、成功したプラクティスが現れます。複雑さの詳細 こちら 。
茂みの周りで十分な打撃...彼女のあなたの答え
プロセスを選択します。いつどこで見つかったかに関係なく、すべてのバグをログに記録して修正し、その新しいプロセスの影響の測定と遡及を開始します。チームは長所と短所を確認し、最終的にはスクラムフレームワーク内で機能する実証済みの方法で解決します。
最も重要なのは、スクラムチームが経験的に、自己組織的な方法で決定を下したことです。