バグ修正をスクラムプロセスに組み込む最善の方法は?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 この質問を改善する 私は過去数日間スクラムについて勉強して読んでおり、スプリント計画とタスクについて読んでいました。私の頭に浮かんだ1つの問題は、スクラムのバグに対処する方法です。Henrik Knibergは、この問題に対処するいくつかの方法を、Trenchesの非常に素晴らしい本であるScrum and XPにリストしています。 製品所有者は、最も優先度の高いJiraアイテムを印刷して、スプリント計画会議に持ち込み、他のストーリーと一緒に壁に置きます(これにより、他のストーリーと比較したこれらのアイテムの優先度が暗黙的に指定されます)。 製品所有者は、Jiraアイテムを参照するストーリーを作成します。たとえば、「最も重要なバックオフィスレポートバグ、Jira-124、Jira-126、およびJira-180を修正する」などです。 バグ修正はスプリントの外にあると見なされます。つまり、チームはバグを修正する時間があることを保証するために十分低いフォーカスファクター(たとえば50%)を維持します。その後、チームは各スプリントがJiraで報告されたバグを修正するために一定の時間を費やすと単純に仮定されます 製品のバックログをJira(つまり、Excelを破棄)に配置します。他のストーリーと同じようにバグを扱います。 これは本当にプロジェクトごとに決定する必要があるものですか、それとももっと良い解決策がありますか?それぞれのアプローチに問題があると思います。それらのアプローチから生まれたハイブリッドが最も効果的ですか?プロジェクトでこれをどのように処理しますか?