バグ修正をスクラムプロセスに適合させる最良の方法は？
私はここ数日間スクラムについて勉強して読んでおり、スプリント計画とタスクについて読んでいます。私の頭に浮かんだ問題の1つは、スクラムのバグに対処する方法です。 Henrik Knibergは、この問題に対処するいくつかの方法を彼の非常に素晴らしい本にリストしています Scrum and XP from the Trenches ：
- 製品所有者は、最も優先度の高いJiraアイテムを印刷し、スプリントプランニングミーティングに持ち込み、他のストーリーと一緒に壁に置きます（これにより、他のストーリーと比較してこれらのアイテムの優先順位を暗黙的に指定します）。
- 製品所有者は、Jiraアイテムを参照するストーリーを作成します。たとえば、「バグを報告する最も重要なバックオフィス、Jira-124、Jira-126、およびJira-180を修正する」などです。
- バグ修正はスプリントの外にあると見なされます。つまり、チームはバグを修正する時間があることを保証するために十分に低いフォーカスファクター（たとえば50％）を維持します。その後、チームは、各スプリントがJiraで報告されたバグを修正するために一定の時間を費やすと単純に想定されます。
- 製品のバックログをJiraに配置します（つまり、Excelを捨てます）。他のストーリーと同じようにバグを扱います。
これは本当にプロジェクトごとに決定する必要があるものですか、それともより良い解決策がありますか？これらのアプローチのそれぞれに問題があると思います。これらのアプローチから生まれる、最も効果的なハイブリッドはありますか？プロジェクトでこれをどのように処理しますか？
これは非常に良い質問であり、この問題へのさまざまなアプローチに関してはいくつかの所見があります。
- バックログアイテムですべてのバグを平等に扱うことは、理論上は良いアイデアのように聞こえます（作業は1か所で追跡されます）が、実際にはうまく機能しません。バグは通常低レベルであり、より多くのバグがあるため、各バグに対して個別のユーザーストーリーを作成すると、「実際の」ストーリーはすぐに不明瞭になります。
- 製品所有者に見える方法で行われた場合、修正のために予約された各スプリントの明示的な時間は問題ありません。バグは毎日のスクラムで言及されるべきであり、修正されたバグに関する議論はスプリントのレビュー中に行われるべきです。そうしないと、製品の所有者はプロジェクトで何が起こっているのか気付かないでしょう。
- バックログ全体をバグ追跡ツールに入れると、1と同じ一連の問題が発生します。さらに、ほとんどのバグトラッカーはスクラムを念頭に置いて設計されておらず、この目的で使用するのは苦痛です。
最も満足できるソリューションは、すべてのスプリントに「チケット」または「バグ」と呼ばれる単一のユーザーストーリーを配置することでした。次に、そのようなストーリーは、特定のバグを説明する低レベルのタスク（計画中にわかっている場合）または一般的なバグ修正のために所定の時間を予約するメタタスクのいずれかに分割できます。これにより、製品の所有者はプロセスを把握でき、バーンダウンチャートに進捗が反映されます。
実際に新しい機能であるすべての「バグ」を容赦なく閉じ、それらの新しいバックログアイテムを作成することを忘れないでください。また、スプリントが完了したと見なすために、スプリントが終了する前に、現在のスプリントに対して報告されたすべてのバグを必ず修正してください。
実際、この質問から jpeacock で答えるのが最善だと思います スクラムに対するバグ修正に費やした時間を数えますか？
引用させてください：
- バグの修正が簡単/迅速な場合（ライナー1つなど）、修正するだけです。
- バグが些細ではなく、ブロッカーでない場合は、バックログに追加します。
- バグがブロッカーの場合、タスクを（現在のスプリントに）追加して、修正に必要な作業をキャプチャし、作業を開始します。これには、利用可能な合計時間が変更されていないため、新しい時間に対応するために他の何かを（現在のスプリントから）バックログに移動する必要があります。
最初のステップは、バグとは何かを定義することです。バグは、意図/設計されたとおりに本番環境で機能しない機能である場合にのみバグであると教えています。これらはバグタイプのPBIになり、新しい開発に対して優先順位が付けられます。実動で欠落している機能はフィーチャーであり、通常の製品バックログ項目になります。スプリント中に見つかった欠陥のあるコードは不完全な作業とみなされ、現在のストーリーが完了するまで次のストーリーに進まないため、チームは常に問題のあるコードに取り組んでいるので、スプリントでこれらの欠陥を追跡する必要はありません。ポストイットは、チームメイト間の素早いリマインダーのために非常に便利です。壊れたコードを修正することは、常に新しいコードを書くことに優先します。欠陥がストーリーの誤解によるものである場合、ストーリーを開始する前に受け入れ条件に取り組む必要があります。
在庫は無駄です。バグ追跡はインベントリです。バグ追跡は無駄です。
バックログアイテムですべてのバグを平等に扱うことは、理論上は良いアイデアのように聞こえます（作業は1か所で追跡されます）が、実際にはうまく機能しません。バグは通常低レベルであり、より多くのバグがあるため、各バグに対して個別のユーザーストーリーを作成すると、「実際の」ストーリーはすぐに不明瞭になります。
機能よりも多くのバグがある場合は、エンジニアリングの実践に取り組む必要があります。これは何か他のものが間違っているという臭いであり、追跡は答えではありません。掘り下げます。実際、バグは常に臭いです。それらはクールではなく、それらがたくさんある場合、根本原因を見つけ、それらを排除し、バグの追跡に集中するのをやめる必要があります。
リスト上の欠陥を追跡しないで、それらを見つけて修正してください-Mary Poppendieck
確かに、在庫が無駄な場合、欠陥の在庫についてはどうですか...
だからこそ、テスト駆動開発と継続的インテグレーションでStop-the-Lineメンタリティーを実装しようとするので、ほとんどの欠陥をリワークリストに載せるのではなく見つけて修正します。
そして、欠陥が通過すると、新しいコードを書く前にそれらを修正します（バグのあるストーリーはとにかく行われません）。次に、プロセスの修正を試みて、よりミスプルーフになり、発生した瞬間に欠陥を検出します。
すべてのソリューションに適合するサイズはなく、各プロジェクトは異なります。バグは、ミッションクリティカルから修正する価値がほとんどないものに分類されることもあります。
システムの実行に重要でない限り、ストーリーカードになるにはバグを好む。これにより、機能開発とバグ修正の優先順位が明確になります。バグ修正が「スプリント外」であると見なされるシナリオでは、本当に重要なビジネス機能が開発されていない間、バグ修正は本当に些細なバグの修正に移行する可能性があります。
バグをストーリーアプローチとして設定する前に、多くの順列をたどりました。いくつかの異なることを試して、チームのレトロな会議でそれらを再生します。
私たちのケース（グリーンフィールド開発、2〜3人の開発者）で見つかったバグは書き留められ、バグとして明確にマークされ、重大度に基づいて次の反復に割り当てられるか、バックログに残されます。重大かつ緊急のバグの場合、それらは進行中の反復に追加されます。
バグを修正するのと同じくらい単純なことがルールで複雑になる理由はわかりません。スクラムにはルールがほとんどありません、覚えていますか？すべての機能、サポート、推奨事項、または欠陥はスクラムのバックログの問題であり、差別化はありません。そのため、スクラムガイドが述べているように、スプリントのタスクは、計画会議中に決定したものに限定されることはありません。
どうして？
したがって、欠陥、つまりバックログの問題をPBIに移行するか、このスプリントにとどめて配信する場合は、チームとして合理的に議論し、考えます...
より良い質問は、開発段階でバグの作成を停止する方法です。 see-> http://bit.ly/UoTa4n
バグを特定して文書化する場合は、将来的にトリアージして修正する必要があります。これは、「安定化スプリント」、つまり、バグを修正するためだけの1つのスプリント全体につながります。または、それらをバックログに追加し、将来のスプリントの一部として優先順位を付けることができます。また、既知のバグ（P3およびP4別名化粧品およびマイナー）を含むサインオフおよびリリースされたソフトウェアを提供し、取得する予定であることも意味します。
これは本当にアジャイルではありませんか？
私は、3回のスプリントごとに短いバグ修正スプリントを導入するというアイデアをプロジェクトで表にしました。現在のスプリントは3週間です。
アイデアは、すべての開発者が一緒にバグ修正に集中できるようにし、通常のスプリントの新しいストーリーに集中できるようにし、技術的負債の削減に定期的に集中できるようにすることです。
バグ修正は関連するストーリーにグループ化され、優先順位が付けられます。開発者は、バグの性質を理解するために立ち往生することなくバグ修正のサイズを決めるのに苦労するため、スプリントの前にサイジングを行うことは重要ではありません。
誰かがこれを試してみましたか、またはこれがどのように機能するかについてのフィードバックがありますか？
乾杯、ケビン。