バグ修正をスクラムプロセスに組み込む最善の方法は？[閉まっている]

私は過去数日間スクラムについて勉強して読んでおり、スプリント計画とタスクについて読んでいました。私の頭に浮かんだ1つの問題は、スクラムのバグに対処する方法です。Henrik Knibergは、この問題に対処するいくつかの方法を、Trenchesの非常に素晴らしい本であるScrum and XPにリストしています。

1. 製品所有者は、最も優先度の高いJiraアイテムを印刷して、スプリント計画会議に持ち込み、他のストーリーと一緒に壁に置きます（これにより、他のストーリーと比較したこれらのアイテムの優先度が暗黙的に指定されます）。
2. 製品所有者は、Jiraアイテムを参照するストーリーを作成します。たとえば、「最も重要なバックオフィスレポートバグ、Jira-124、Jira-126、およびJira-180を修正する」などです。
3. バグ修正はスプリントの外にあると見なされます。つまり、チームはバグを修正する時間があることを保証するために十分低いフォーカスファクター（たとえば50％）を維持します。その後、チームは各スプリントがJiraで報告されたバグを修正するために一定の時間を費やすと単純に仮定されます
4. 製品のバックログをJira（つまり、Excelを破棄）に配置します。他のストーリーと同じようにバグを扱います。

これは本当にプロジェクトごとに決定する必要があるものですか、それとももっと良い解決策がありますか？それぞれのアプローチに問題があると思います。それらのアプローチから生まれたハイブリッドが最も効果的ですか？プロジェクトでこれをどのように処理しますか？

これは非常に良い質問であり、この問題へのさまざまなアプローチに関していくつかの観察があります。

1. すべてのバグをバックログアイテムで同等に扱うことは、理論的には良いアイデアのように聞こえるかもしれません（作業を1か所で追跡）が、実際にはうまく機能しません。バグは通常低レベルで数が多いため、バグごとに個別のユーザーストーリーを作成すると、「実際の」ストーリーはすぐに不明瞭になります。
2. 修正のために予約された各スプリントでの明示的な時間は、製品の所有者に見える方法で実行されれば問題ありません。バグは毎日のスクラム中に言及されるべきであり、修正されたバグについての議論はスプリントのレビュー中に行われるべきです。そうしないと、製品の所有者はプロジェクトで何が行われているのかを認識できません。
3. バックログ全体をバグ追跡ツールに入れると、1と同じ一連の問題が発生します。さらに、ほとんどのバグ追跡システムはスクラムを考慮して設計されていないため、この目的で使用するのは面倒です。

私たちが最も満足できると思った解決策は、すべてのスプリントに「チケット」または「バグ」と呼ばれる単一のユーザーストーリーを置くことでした。次に、そのようなストーリーは、特定のバグを説明する低レベルのタスク（計画中にわかっている場合）または一般的なバグ修正のために指定された時間数を予約するメタタスクに分割できます。このようにして、製品の所有者はプロセスを可視化し、バーンダウンチャートは進行状況を反映します。

実際に新しい機能であるすべての「バグ」を無慈悲に閉じ、それらの新しいバックログ項目を作成することを忘れないでください。また、スプリントが完了したと見なすために、スプリントが終了する前に、現在のスプリントに対して報告されたすべてのバグを修正してください。

実際、私はこの質問からのjpeacockによる回答が最善だと思います。スクラムに向けたバグ修正に費やした時間をカウントしますか？

引用させてください：

• バグの修正が簡単/迅速である場合（1つのライナーなど）、それを修正するだけです。
• バグが自明ではなく、ブロッカーでもない場合は、バックログに追加します。
• バグがブロッカーである場合は、タスクを（現在のスプリントに）追加して、バグを修正するために必要な作業をキャプチャし、作業を開始します。これには、利用可能な合計時間が変更されていないため、新しい時間を考慮に入れるために（現在のスプリントから）他の何かをバックログに移動する必要があります。

最初のステップは、バグとは何かを定義することです。バグは、意図された/設計されたとおりに本番環境で機能しない機能である場合にのみバグであることを教えます。これらは、新しい開発に対して優先されるバグタイプのPBIになります。プロダクションで失われた機能はフィーチャーであり、通常の製品バックログ項目になります。スプリント中に発見された欠陥のあるコードは、不完全な作業と見なされます。これは、現在のコードが完了するまで次のストーリーに進まないためです。チームは常に問題のコードに取り組んでいるため、スプリントでこれらの欠陥を追跡する必要はありません。ポストイットは、チームメイト間の迅速なリマインダーとして非常に便利です。壊れたコードの修正は、常に新しいコードの作成よりも優先されます。

在庫は無駄です。バグ追跡はインベントリです。バグ追跡は無駄です。

すべてのバグをバックログアイテムで同等に扱うことは、理論的には良いアイデアのように聞こえるかもしれません（作業を1か所で追跡）が、実際にはうまく機能しません。バグは通常低レベルで数が多いため、バグごとに個別のユーザーストーリーを作成すると、「実際の」ストーリーはすぐに不明瞭になります。

機能よりもはるかに多くのバグがある場合は、エンジニアリング手法に取り組む必要があります。これは何か他のことが間違っている匂いであり、追跡は答えではありません。深く掘る。実際、バグは常に臭いです。それらはクールではなく、それらがたくさんある場合は、根本的な原因を見つけ、それらを排除し、バグの追跡に集中するのをやめる必要があります。

リストの欠陥を追跡せず、見つけて修正する-Mary Poppendieck

確かに、在庫が無駄である場合、欠陥の在庫についてはどうでしょう...

だからこそ、私は常にテスト駆動開発と継続的インテグレーションを備えたStop-the-Lineメンタリティを実装して、ほとんどの欠陥をリワークリストに載せるのではなく、見つけて修正しようと努めています。

そして、欠陥が通り抜けたら、新しいコードを書く前にそれらを修正します（バグのあるストーリーはとにかく行われません）。次に、プロセスを修正して、間違いを防ぎ、欠陥が発生した瞬間に検出できるようにします。

すべてのソリューションに適合する1つのサイズはなく、プロジェクトごとに異なります。バグは、ミッションクリティカルから修正する価値がほとんどないものに分類される場合もあります。

システムの実行にとって重要でない限り、私はバグをストーリーカードにすることを好みます。これにより、機能開発とバグ修正の優先順位が明確になります。バグ修正が「スプリントの外」にあると見なされるシナリオでは、本当に重要なビジネス機能が開発されていないときに、バグ修正がほんのささいなバグの修正に移る可能性があります。

ストーリーアプローチとしてバグを設定する前に、いくつかの順列を試しました。いくつかの異なることを試して、チームのレトロな会議でそれらを再生してください。

私たちのケース（グリーンフィールド開発、2〜3人の開発者）で発見されたバグは書き留められ、バグとして明確にマークされ、その重大度に基づいて次の反復に割り当てられるか、バックログに残されます。重大で緊急のバグの場合、それらは進行中の反復に追加されます。

バグの修正という単純なことがルールで複雑になる理由がわかりません。スクラムにルールがほとんどないことを覚えていますか？すべての機能、サポート、推奨、または欠陥はスクラムのバックログ問題であり、区別はありません。だから、スクラムガイドが言うように：スプリントのタスクは、デイリースクラムが計画会議中に決定したものに制限されることは決してありません。

どうして？

したがって、欠陥、つまりバックログの問題をPBIに入れるか、このスプリントに残して配信するかをチームとして合理的に話し合い、考えます...

より良い質問は、開発段階でバグの作成をどのように停止するかです。参照-> http://bit.ly/UoTa4n

バグを特定して文書化している場合は、後でトリアージして修正する必要があります。これは、「安定化スプリント」、つまりバグを修正するための1つのスプリント全体につながります。または、バックログに追加して、将来のスプリントの一部として優先順位を付けることもできます。また、既知のバグが含まれているソフトウェア（P3およびP4、別名はコスメティックおよびマイナー）を提供し、リリース予定のソフトウェアを提供することを意味します。

これは実際にはアジャイルではありませんか？

私のプロジェクトでは、3回のスプリントごとに短いバグ修正スプリントを導入するというアイデアをまとめました。現在のスプリントは3週間です。

アイデアは、すべての開発者が一緒にバグ修正に集中できるようにし、定期的なスプリントの新しいストーリーだけに集中できるようにし、技術的負債の削減に常に集中できるようにするというものです。

バグ修正は関連するストーリーにグループ化され、優先されます。開発者は障害の性質を理解するために立ち往生することなくバグ修正のサイズを決めるのに苦労しているため、スプリント前のサイジングには重点が置かれていません。

誰かがこれを試したか、これがうまくいくと思う方法についてフィードバックがありますか？

乾杯、ケビン。