スクラムでの生産（旧バージョン）からの欠陥の処理方法
SCRUMに移行します。スプリントでは、バージョン1.0の運用中に、バージョン1.1で作業します。ただし、バージョン1.0からの不定期のバグが報告されており、修正する必要があります。これをどのように処理するべきかについての情報は見つかりませんでした-それらをスプリントの一部にすることは私には適切ではないようです（異なるバージョンのものであり、現在のスプリントのスプリントの目標とは関係がないため）。彼らは？基本的には、すでに展開されているバージョンのメンテナンス作業に拡張できます。
正式にスクラミーがそれを処理したのかどうかはわかりませんが、以前のチームで行ったことは次のとおりです。
時間を取っておく
私たちがそれを認めたかったかどうかに関わらず、生産問題は現実です。したがって、行うべき唯一の正気なことは、それらを計画に含めることです。
スプリントを計画するときは、開発の作業の一部を本番の問題に対処するために予約してください。割合がどれだけ大きいかは、製品とチームに非常に固有です。したがって、この値は、スプリントごとに微調整する必要があるものの1つです。
すべての生産上の問題が平等に作成されるわけではありません
生産上の問題が発生した場合は、対処方法を決定する前に、その影響を評価する必要があります。
- 問題がブロッカーの場合は、すぐに修正する必要があります
- 一方、問題が軽微であるか、既知の回避策がある場合は、ユーザーはそれに満足して喜んで新しい問題は製品のバックログに入ります
その最後のポイントは非常に重要です。チームは常に他のすべてよりも生産の問題を優先しているという理由だけで、チームはスプリントに繰り返し失敗しているようです。
短いスプリントを使用するポイントは、中断を最小限に抑えて作業できるようにすることです。もちろん、実用的である必要があります（たとえば、ブロッカーに対処する）が、計画したスプリントを危険にさらさないように注意する必要もあります。
それは非常にバランスの取れた行為です。