バグレポートはどのようにスプリントに組み込まれますか？

最近スクラムについて読んでいます。私の理解では、スプリントが始まる前に会議が開かれ、製品のバックログから次のスプリントのバックログに何を移動するかを決定します。現在のスプリントで機能が完了すると、「Ready to QA」バケットに入れられ、この時点で混乱します。バグレポートは製品のバックログに戻りますか？このサイクルで実行する作業はすでに決定しているため、スプリントバックログに戻れないと思いますか？QAがバグを検出するとどうなりますか？どこに行くの？

私の見たところ、これには2つの主な解決策があります。

1. 現在のスプリントに時間の100％を割り当てないでください。バグ修正やその他の支援活動のためにあなたの時間を10〜15％のを許可しますスプリント中に出てきます。その後、ブロッキングバグが発生した場合は、現在のスプリントで修正する時間があります。

   非ブロッキングバグが発生した場合、残りの時間があれば、現在のスプリントの最後に修正するか、次のスプリントの「ポット」に入ることができます。

2. 「バグ修正」のスプリントをときどき行ってください。おそらく次のメジャーリリースの直前。これを使用して、次のリリースで修正できる、または修正したい限り多くのバグを「モップアップ」できます。

これらのソリューションはどちらも「純粋な」スクラムには当てはまらないかもしれませんが、現実の世界では機能します。

「通常の」スプリント中に、特定のバグを修正するタスクを含めて、新しい機能の一部として扱うことができます。

理想的なスクラムの世界では、QAアクティビティが完了してバグが修正されるまで機能が完了しないため、「Ready for QA」バケットはありません（少なくともチームの外には見えません）。つまり、チームにはQA活動に参加できる人がいるはずです。

現実の世界では、スクラム（開発）チームと並行して機能する別のQA /テストチームがいる場合があります。その場合、次のアプローチが適切に機能する可能性があります。

1. 機能が「Ready for QA」バケットに入れられる直前に、その機能の（メイン）開発者と（おそらく）一緒に引き継いで機能をウォークスルーするQA担当者。その時点で見つかった問題はすべて、機能が「QA対応」バケットに入れられる前に解決されます。これはスプリントデモの初期段階ではないことに注意してください。これは、問題の解決策をできるだけ早く解決することを目的としています。

2. QAへの引き渡し後に見つかった問題は、次の計画会議で考慮されるように、ストーリーとして製品のバックログに配置する必要があります。

3. show-stopperバグの場合、各スプリントに一定の時間を予約します。スプリントの終わり近くに、このバッファーに時間が残っている場合、優先度の低い問題で満たされる可能性があります。

ストーリーからのワークフローの説明に基づいて、製品バックログ、スプリントバックログ、およびその他のバケット（「進行中/開発中」、「QA準備完了」、「終了」のようなものを想定しています） "）、それはあなたがカンバンのいくつかの要素をスクラムに追加しているように聞こえます-時々スクラムバンと呼ばれる珍しい組み合わせではありません。カンバンの概念により、各バケットのサイズに制限が追加され、開発者が進行中のストーリーが多すぎたり、テスターがテストしすぎたりしないようにします。これは、製品バックログからスプリントバックログにアイテムを移動する速度と似ていますが、スプリント内です。

私はあなたのタスクをユーザーストーリーにして問題に取り組みます。ユーザーストーリーは製品バックログからスプリントバックログ、進行中のバケット、QAバケットの準備が完了してバケットに移動します。開発者は（完了の定義に基づいて）ストーリーを完成させた後、それを「QA準備完了」バケットに移動し、次の人がそれを引き出して作業します。問題がある場合は、追跡システムに欠陥が入力され、ユーザーストーリーは実装およびテストされているため、完成したバケットに移動されます。問題がない場合は、完成したバケットに直接移動します。

欠陥がスプリント内にある場合、それをスプリントバックログ（または、ある種の「進行中」のバケット）に戻すことに問題はありません。既知の欠陥があるストーリーは通常、未完成と見なされます。ストーリーを終了するのに十分な時間がないと判断された場合、または欠陥がストーリーを理解していないことが原因であると判断された場合、必要性をよりよく理解できるようになるまで、スプリントから完全にデスコープするオプションが考えられます。この場合、私はお勧めしませんリリースされた製品の欠陥のある実装を含みます。

欠陥が原因でストーリーがスプリントで終了しない場合、これは将来のスプリントの速度計算で明らかになります。未完成のストーリー（欠陥のあるストーリー）ではストーリーポイントが得られないため、小さいスプリントを計画します。複雑なストーリーが少ないと、テストにかかる時間が長くなり、欠陥を早期に発見するためにより多くの労力を費やすようになります。欠陥の防止は、費用がかさむだけでなく、問題の存在を特定して問題を見つけるのに費やした時間よりも時間がかかりません。設計または実装で、問題を修正し、システムに他の悪影響を与えることなく問題が解決されたことを確認するために再テストします。タイムボックスが重要であるため、欠陥を防止する機能は、将来、より生産的なスプリントにつながります。

欠陥に優先順位を付ける方法を決定する際には、何をするかに関係なく、プロダクトオーナー（できれば顧客/ユーザーの代表者）を関与させる必要があります。いくつかの欠陥は、回避策がある場合、またはそれらがまれである場合、リリースに含めることが許容される可能性があります。つまり、欠陥は将来のスプリントのストーリーとして表示されます。その他の欠陥は緊急で「ショーストッパー」である可能性があります-これらはすぐに対処する必要があり、製品が存在する場合は使用できません。

不具合に費やされた時間が春ごとにかなり一貫している場合、実際にそれを管理する必要はありません-チームの速度はそれを反映します。

それ以外の場合は、欠陥の修正を計画できる（つまり、スプリントの期間中、修正を延期できる）場合は、そうします。

そうでなければ、スクラムは良い答えを持っていません-欠陥は、スプリントの途中での計画外のスプリントコンテンツの変更になるため、コミットメントを再度関連付ける必要があります。

スプリントは自己完結型でなければなりません。つまり、QA、バグ修正、ドキュメントを含むすべてのアクティビティは、スプリントが終了する前に完了する必要があります。展開前のアクティビティは、スプリントが終了する前にも行う必要があります。

終了しないことの問題は、次のスプリントで気が散ることです。

スプリントBで、バグを修正できるようにスプリントAのコードに注意を向けなければならない場合、スプリントBのタスクに集中する能力がなくなります。あなたの前進速度もそうです。

私の最後の仕事で、スプリントは「理想的な時間」の概念に基づいてスケジュールされました。8時間の開発者日のうち5時間は、これまで存在しなかった新機能のTDDingでした。他の3人は他のすべてをしていました。電子メール、会議、コードのコンパイル/コミット/更新、リファクタリング作業、そしてはい、バグ修正。

完了したが、チームの速度にまだカウントするバグがあった仕事を検討しました。ただし、バグは発生したときに完済しなければならない技術的負債であり、明らかに回避する必要があります。ずさんな作業をしている人々に本当の問題はありませんでした。誰も後戻りしたくなかった。

時々、バグ修正スプリントも用意されています。私たちには、消費できるペースで要件を提供できないクライアントがいるという不幸な幸運がありました。そのため、バックログを少し積み上げるために、オブジェクトが「できるだけ多くの欠陥を殺し、できるだけ多くの技術的負債を返済してください。」技術的には、そのようなスプリントの速度はゼロですが、これは実行する必要がある作業であり、クライアントを幸せにするので、価値があります。