バグ修正の反復を説明する方法は？

過去5か月間、私たちはスクラムをかなりうまく実装してきました。しかし、我々はせずに3週間離れPRODからですこれまでの任意のエンドツーエンドの統合テストを行います。痛い！私は助けが必要です。これの原因に取り組むことなく（この時点で）、現在のイテレーションを計画する必要があります。これは、マイナーな改良と多くの未知のバグ修正で構成されています。このシナリオをどのように説明しますか？まだ発見されていないバグを修正するための反復をどのように計画しますか？

スクラムかどうかにかかわらず、バグ修正は基本的に予測することが不可能です。あなたができると私が信じる最高のことは：

• すぐにテストを開始します。初期の見積もりは行われません。
• 各バグを発見したら、推定できる程度まで初期分析を行います。
• バグを推定し、修正する必要があるかどうか、および初期リリースで修正する必要があるかどうかを決定します。
• 修正する必要がある場合は、反復に追加します。
• バーンダウンチャートをプロットします。ある時点で減少し始めます。つまり、バグを修正するよりも早くバグを見つけることができなくなります。その時点で、リリースを行うことができる時期を大まかに見積もることができます（次第に正確になります）。

次回は、早期にテストを開始し、バグを修正するときに確認する必要があります。アジャイルであろうとなかろうと、すべての賢明な方法論では、新機能を進める前に既知のバグを修正する必要があります。また、各機能のバグ修正に費やされた時間を考慮する必要があります。これにより、将来デバッグされる状態に機能を実装するための見積もりを改善できます。

推定とバグ修正は、エビデンスベースのスケジューリングとハードアッシングバグ修正のJoel Spolskyによって適切にカバーされています。それはスクラムに関連するものではありませんが、その多くが当てはまるので十分に一般的だと思います。

バグ修正の反復を説明する方法は？まだ発見されていないバグを修正するための反復をどのように計画しますか？

「バグ修正の反復」について。見つかったバグはストーリーと同じように扱われるべきです。チームと協力して、各バグを修正するための努力（ストーリーポイント）を見積もり、製品の所有者/顧客と協力して、バグが次の反復に進むかどうかを決定します。

「まだ見つかっていないバグ」について。好ましくは、チームは各反復で問題を見つけて修正しています。そうでない場合は、次の回顧展でこれについて話し合ってください。製品の品質が低すぎてリリースできない場合は、すぐに最善の「バグファインダー」をバグの発見（修正ではなく）に移してください。品質が高く、ユーザーを選択するためのベータリリースを提供できる場合は、それを実行してください。それができない場合は、最低でも、改善が必要であると推奨する弱点について議論するライブユーザーデモを提供します。

「バグ修正の反復」は計画していませんが、各リリースの前にシステムテストの反復を計画しています。システムテストは、製品のすべての部分に対する統合、回帰、および実際のテストです。テスト担当者は製品（かなり大規模なレガシーシステム）をテストし、開発者は見つかったバグを修正します。バグが見つからない場合は、次のプロジェクトの機能スケジュールの調査を開始するか、内部の改善に取り組みます。

現在、コードがフリーズしてから6週間のシステムテスト（5か月のプロジェクトの場合、システムテストを含む）を計画しており、すべてが正常に機能することを確認しています。これは、実装の反復中に行われるすべてのテストの上にあります。

「リリース」基準のセットを定義する必要があります。これらには以下が含まれます。

• 失敗までの平均時間
• 1日に検出された欠陥の数
• 1日あたりの欠陥の重大度
• 未処理の欠陥の数

等

次に、各イテレーションの終わりに、テストを行う人（手動または自動テストを作成する）と、基準を満たしているかどうかを確認するためにチェックを修正する人がいます。その後、リリースしている場合はリリースし、リリースしていない場合は別のイテレーションに進みます。

これを上書きする可能性があるはずです。また、未加工の数値がアプリケーションの現実的な図を提示しないこともよくあります。あなたはいくつかの本当に深刻な欠陥を持っているかもしれませんが、それらはあなたが短期的に生きることができるまれな状況でのみ現れます。

これを行う1つの方法は、統合テストのストーリーを記述し、その間に発見したバグの新しいストーリーを記述し、次の反復でバグストーリーを修正することです。

もう1つの方法は、「統合テストで見つかったバグを修正する」というストーリーを作成することです。以前のリリースから、通常はいくつの問題が見つかるのか、そしてそれらを修正するのがどれほど難しいのかがわかるはずです。そのため、その知識に基づいてストーリーポイントを割り当てることができます。管理しやすくなる場合は、コンポーネントに分割することもできます。これには常に避けられない不確実性があります。それを説明するためにいくつかのストーリーポイントを追加します。

おそらく、最善の方法は、可能であればすべての反復に小さな統合テストを組み込むことであることに後で気づいたでしょう。それを認識し、次のリリースのためにプロセスを少し改善することでおめでとうございます。