あなたのアジャイル/スクラムチームのバグワークフローは何ですか？
あなたのアジャイル/スクラムチームのバグワークフローは何ですか？
これが私たちのものです：-バグが現在のスプリントのストーリーに関連している場合、それを修正します。 -バグが現在のスプリントのストーリーに関連しておらず、重大でない場合は、優先順位付けのために製品の所有者に送信されます。 -バグがスプリント内のストーリーに関連しておらず、重大な場合は、修正します。
現在のスプリントでの作業に関連するものはすべて修正されています。バグとは見なされず、そのように記述しません。バグとは、既に完了と見なしたものの一部である場合に限り、バグと見なします。
新しいバグが発生すると、バックログに追加され、利害関係者によって優先順位が付けられます。スプリントの残り時間が残っている場合、優先度の低い簡単なバグに取り組む傾向がありますが、残りの時間で完了することができます。
バグは、すでに失敗したテストがある単なるストーリーであると常に思っていたため、機能のストーリーの一般的な最初のドラフトよりも明確に定義されています。
そのため、バグがストーリーであると確信している場合は、推定と優先順位に関して他のストーリーと同様に扱います。
これに取り組む最善の方法は、まずバグを実際に検討したいものを決定することだと思います。
正直に言うとバグではないので、多くの開発者は、現在取り組んでいる予定どおりに機能していないものをバグではないと見なします。現在何かに取り組んでいて、それでもまだ欠陥がある場合、特定のバグは実際には完了していないため、実際の欠陥はありません。何かが完全であり、テスト/リリース/本番の準備ができていると判断し、後でコードの欠陥または使用を見つけた場合は、間違いなくバグが存在します。
私の会社では、次の方法を使用して、バグをいつ修正するかを決定しています。
バグが重大な場合、その製品に関連する現在のスプリントに適切な優先度で追加されます。通常、これをスプリントに組み込むために約10％の追加時間を計画し、実際に完了する予定がない余分なものを用意しますが、バグがないか、予想よりも早く完了した場合は、コンプリート。
バグが重大でない場合は、バックログに追加するだけで、通常は次のスプリントで完了します。
なぜこれが理想的なフローなのか、明らかなリークがいくつかあり、プログラミングの観点から「クリティカル」ではないことは、経営陣が予想よりも早く完了する必要があると判断した場合、すぐに完了する必要がある場合があります。完了しました。
余談ですが、最善の方法は、構造を選択してそれを使い続けることです。生産性の最大の損失のいくつかは、構造なしで物事を始めたときに発生し始めます。構造の劣化を開始すると、それがすべて下り坂になるのは非常に簡単です。
それはあなたの質問に過度に答えたかもしれませんが、それらはこれらのものがどう扱われるべきかについての私の考えです。
スプリント中に発見されたバグは開発のほんの一部です。
スプリントの終了後に見つかったバグは、プロダクトバックログに記録されます。何かがバグ、拡張、または変更であるかどうかについてユーザーと議論することはありません。ユーザーがバグと呼びたい場合は問題ありませんが、PBには他の新しい作業が含まれます。
継続的な欠陥作業を行っています。セットアップと同様に、現在の作業に関連する重大な問題がある場合は、作業の一部として修正します。結局のところ、それに関連する欠陥がある場合、ストーリーを「完了」と呼ぶことはできません。
その他のバグについては、通常、時間の許す限り修正します。差し迫った問題がある場合は、いくつかのストーリーを引き戻し、バグ修正に時間をかけてから通常の機能作業に戻ります。