スクラムスプリント中の制作上の問題の管理
プロダクションでのバグ管理の問題は、最近私の心の大きな特徴でした。スプリントはアイテムを追加することを意図したものではありませんが、クリティカルバグの場合、これは単に避けられません。
このスプリントの中断をどうやって管理するのですか？スプリントに時間の「許容量」のパーセンテージを与えるだけで、スケジュールの80％を「念のため」にスプリントアイテムで満たすだけですか？
これがcriticalである場合、あなたがそれを処理する必要があります。
スプリントへの影響を測定するには、ログに記録する必要があります。
この情報ラジエーターを見てください：
「予定外のアイテム」という部分があります。あなたの重大なバグをそこに置いてください。ご覧のとおり、 "Next"の部分が逆になっており、スプリントをより早く完了するために、計画よりも多くのユーザーストーリーを配置しています。
スプリントレビューや retrospective でそれについて話します。目的は、それらを制限する方法を見つけ、それに応じて velocity を調整することです。
昨日の天気に基づいて「許容量」インジケータとして速度を使用する場合、スプリントに割り込む余分な作業の平均量を自動的に調整します。
本番の問題が以前のスプリントで作成されたバグが原因である場合、修正作業を現在のスプリントの速度に割り込ませても問題ありません。このようにして、チームの速度は、以前に獲得すべきではなかったポイントに対して「補正」されます。
場合によっては、スプリントの目標をすべて達成していない場合もありますが、それを乗り越えてください;-)速度が頻繁に発生する場合、速度は平均して低い数値になります。
他の重要ではないものは、バックログに含めるだけで、通常のスプリントに含めることができます。私はバグを最優先し、速度にカウントしないようにします。
生産の問題の修正とトラブルシューティングに必要なすべての時間は、チームの速度に自動的に考慮されます。平均を取るのに時間がかかるだけで、実際には別の許容値は必要ありません。
私は主に開発作業を行うチームで働いていますが、既存の複雑なシステムも担当しています。私たちにもこの問題がありました。
基本的に、最後のスプリントに基づいてポイントを見積もり、予想されるメンテナンス作業のためにいくつかのポイントを予約します。大規模な停止など、これを大幅に超えるメンテナンスタスクが発生した場合は、ユーザーストーリーとして追加し、まだ開始されていない既存のタスクを削除して、同じサイズのスプリントを維持します。緊急ではない大きな問題が発生した場合は、次のスプリントに移動します。
はい、これは技術的にスクラムに従っていません。しかし、柔軟性は私たちにとってうまくいきました。
すべての計画会議でチームに標準の予約から逸脱する理由があるかどうかを尋ねることで、この予約時間を調整しました。これは、予想よりもはるかに長い時間を要したオフィス移転の後に導入され、多くのストーリーが終了していませんでした。
ただし、私のチームや他のチームのやり方だけに固執しないでください。何かを選んで、それを実行してください。それがあなたのチームにとってうまくいくことを保証する方法はありません。振り返ってみて、評価してください。チームが不満を感じている場合は、別の方法を試して、もう一度評価してください。チームはすべて異なり、ニーズと制限も異なります。
それが生産上の重大な問題である場合は、直接処理できるはずですが、選択した開発方法論は関係ありません。修正プログラムは、通常のリリースサイクル（スプリントなど）とは関係ありません。
現在運用中のコードに基づいて、「修正」ブランチで修正することをお勧めします。