あなたのアジャイル/スクラムチームのバグワークフローは何ですか？

あなたのアジャイル/スクラムチームのバグワークフローは何ですか？

これが私たちのものです：-バグが現在のスプリントのストーリーに関連している場合、それを修正します。-バグが現在のスプリントのストーリーに関連しておらず、重大でない場合は、優先順位付けのために製品オーナーに送信されます。-バグがスプリントのストーリーに関連しておらず、重大な場合は、修正します。

現在のスプリントでの作業に関連するものはすべて修正されています。バグとは見なされず、そのように記述しません。バグは、すでに完了と見なされたものの一部である場合にのみ、バグと見なされます。

新しいバグが発生すると、バックログに追加され、利害関係者によって優先順位が付けられます。スプリントの残り時間が残っている場合、優先度の低い簡単なバグに取り組む傾向がありますが、残りの時間で完了することができます。

バグは、すでに失敗したテストがある単なるストーリーであると常に思っていました。そのため、機能の典型的なストーリーの最初のドラフトよりも明確に定義されています。

したがって、バグがストーリーであると確信している場合は、推定と優先順位に関して、他のストーリーと同様にそれらを扱います。

これに取り組む最善の方法は、まずバグを実際に検討したいものを決定することだと思います。

正直なところバグではないため、多くの開発者は、現在はバグとして取り組んでいるのではなく、意図したとおりに機能しないものを考慮しません。あなたが現在何かに取り組んでいて、それでもまだ欠陥があるなら、特定のバグは実際には完全ではないので、実際の欠陥はありません。何かが完全であり、テスト/リリース/本番の準備ができていると判断し、後でコードの欠陥または使用を見つけた場合は、バグが確実にある場合に、その逆が完了した作業に適用されます。

私の会社では、次の方法を使用して、いつバグを修正するかを決定しています。

バグが重大な場合、その製品に関連する現在のスプリントに適切な優先度で追加されます。通常、これをスプリントに含めるために約10％の追加時間を計画し、実際に完了する予定がない余分なものを用意しますが、バグがないか、予想よりも早く完了した場合は、コンプリート。

バグが重大でない場合は、バックログに追加し、通常は次のスプリントで完了します。

なぜこれが理想的なフローなのか、明らかなリークがいくつかあり、プログラミングの観点から「クリティカル」ではないことは、経営陣が予定よりも早く完了する必要があると判断した場合、すぐに完了する必要がある場合があります。完了しました。

余談ですが、最善の方法は、構造を選択してそれを使い続けることです。生産性の最大の損失のいくつかは、構造なしで物事を始めたときに発生し始めます。構造の劣化を開始すると、すべてが下り坂になるのは非常に簡単です。

それはあなたの質問に過度に答えたかもしれませんが、それらはこれらのものがどのように扱われるべきかについての私の考えです。

継続的な欠陥作業を行っています。セットアップと同様に、現在の作業に関連する重大な問題がある場合は、作業の一部として修正します。結局のところ、それに関連する欠陥がある場合、ストーリーを「完了」と呼ぶことはできません。

その他のバグについては、時間の許す限り、通常は修正します。差し迫った問題がある場合は、いくつかのストーリーを引き戻し、バグ修正に時間をかけてから通常の機能作業に戻ります。

スプリント中に発見されたバグは開発のほんの一部です。

スプリントの終了後に見つかったバグは、プロダクトバックログに記録されます。何かがバグ、拡張、または変更であるかどうかについてユーザーと議論することはありません。ユーザーがバグと呼びたい場合は問題ありませんが、それでもPBには他の新しい作業が含まれます。