スクラムスプリント中の制作上の問題の管理

本番環境でのバグ管理の問題は、最近私の心の大きな特徴でした。Sprintはアイテムを追加することを意図していませんが、重大なバグの場合、これは単に避けられません。

このスプリントの中断をどうやって管理するのですか？スプリントに時間の「許容量」のパーセンテージを与えるだけで、スケジュールの80％を「念のため」にスプリントアイテムで満たすだけですか？

これが重要な場合は、対処する必要があります。

スプリントへの影響を測定するには、ログに記録する必要があります。

この情報ラジエーターを見てください：

「予定外商品」という部分があります。あなたの重大なバグをそこに置いてください。ご覧のように、スプリントをより速く完了するために、計画よりも多くのユーザーストーリーを配置する「Next」部分の逆があります。

スプリントレビューや回顧展でそれについて話します。目的は、それらを制限する方法を見つけ、それに応じて速度を調整することです。

昨日の天気に基づく「許容量」インジケータとして速度を使用する場合、スプリントに割り込む余計な作業の平均量を自動的に調整します。

本番の問題が以前のスプリントで作成されたバグが原因である場合、修正作業を現在のスプリントの速度に割り込ませても問題ありません。このようにして、チームの速度は、以前に獲得すべきではなかったポイントに対して「補正」されます。

場合によっては、スプリントの目標をすべて達成しないで、それを乗り越えることもできます;-)速度が頻繁に発生する場合、速度は平均して低い数値になります。

その他の重要ではないものは、バックログに含めるだけで、通常はスプリントに含めることができます。私はバグを最優先し、速度にカウントしないようにしています。

生産の問題の修正とトラブルシューティングに必要なすべての時間は、チームの速度に自動的に考慮されます。平均化するのに時間がかかるだけで、実際には別の許容値は必要ありません。

私は主に開発作業を行うチームで働いていますが、既存の複雑なシステムも担当しています。私たちにもこの問題がありました。

基本的に、最後のスプリントに基づいてポイントを見積もり、予想されるメンテナンス作業のためにいくつかのポイントを予約します。大規模な停止など、これを大幅に超えるメンテナンスタスクが発生した場合は、ユーザーストーリーとして追加し、まだ開始されていない既存のタスクを削除して、同じサイズのスプリントを維持します。緊急ではない大きな問題が発生した場合は、次のスプリントに移動します。

はい、これは技術的にスクラムに従っていません。しかし、柔軟性は私たちにとってうまくいきました。

すべての計画会議でチームに標準の予約から逸脱する理由があるかどうかを確認することで、この予約時間を調整しました。これは、予想よりもはるかに長い時間を要したオフィス移転の後に導入され、多くのストーリーが終了していませんでした。

ただし、私のチームや他のチームのやり方だけに固執しないでください。何かを選んで、それを実行してください。それがあなたのチームにとってうまくいくことを保証する方法はありません。振り返ってみて、評価してください。チームが不満を感じている場合は、別の方法を試して、もう一度評価してください。すべてのチームは異なり、そのニーズと制限も異なります。

それが生産上の重大な問題である場合は、直接処理できるはずですが、選択した開発方法論は関係ありません。修正プログラムは、通常のリリースサイクル（スプリントなど）とは関係ありません。

現在運用中のコードに基づいて、「修正」ブランチで修正することをお勧めします。