SCRUMプロセスでバグトリアージ会議を行うのはいつですか？
私は 記事 を読んでいましたが、アジャイルスプリント中の「予期しない緊急事態」の状況に対するいくつかの解決策を説明しています。この記事は、問題が本当に緊急事態であるかどうか、およびアクティブなスプリントに関与するリソースが対処する必要があるかどうかを判断するトリアージを提案しています。
したがって、ソリューション1は、すべての生産上の問題に対してトリアージを実行する強力なプロダクトオーナーです。それが実際の本番の問題である場合は、必ず修正してください。しかし、私はあなたが緊急事態ではないはずの多くの問題を見つけることを保証できます...ところで、このようにトリアージを実行しているプロダクトオーナーは、ジェームズ・コプリエンが彼の組織パターンブックでファイアウォールと呼んでいるものです。
この記事では、「ソリューション2」についても触れています。
解決策2：トリアージを実行し、少なくとも次のスプリントまで修正を延期する
この記事で詳細に触れなかったのは、トリアージ自体です。これらの会議は適切にスケジュールされていますか？または、それらの「キュービクル」会議は、関係者とバグについて話し合うために、非常に非公式にオンデマンドで開始されましたか？誰がこれらのトリアージ会議/議論に関与する必要がありますか？
私の質問はより一般的です。私はここのみんなに長い記事自体を読むように頼むつもりはありません。問題は一般に、アジャイルプロセスでのバグのトリアージに関するものです。
トリアージは通常、会議としては行われません。チームは製品に応じて異なる方法で行いますが、私たちのチームでは、製品の所有者がお客様の問題のトリアージを行い、テストで見つかった問題については、別のチームメンバーを「その日のトリアージ」としてローテーションします。
トリアージャーの仕事はデバッグではなく、次の質問にできるだけ効率的に答えることです。
- 既知のバグですか、新しいバグですか、ユーザーエラーですか？
- 新しいバグの場合、どのソフトウェアチームが修正を担当する必要がありますか？
- 影響はどの程度深刻ですか？回避策はありますか？それ以上のテストを妨げていますか？.
- 修正時間の概算。
トリアージャーが他の誰かの専門知識を必要とする場合、彼は彼に電話をかけます。トリアージャーは、何かを保留にするほど深刻だと感じた場合、製品所有者と非公式にチャットします。それ以外の場合は、バックログに入ります。ほとんどの場合、問題のトリアージにはおそらく15分かかり、他の人を巻き込む必要はありません。
場合によります。
アジャイルチームごとに、ニーズが異なるため、プロセスも異なります。毎日数十個のバグが発生している場合、非公式のキューブ会議ではおそらくそれを削減することはできません。バグの大部分がユーザー入力である場合は、だまされやすい人を探し、ユーザビリティの問題を判断できる人が必要です。少人数のグループの場合は、チームリーダーのデスクに立ち寄るのがよいでしょう。ニーズと繁殖シナリオについて話し合うことができるからです。メジャースケジュールされたリリースの数週間前であれば（そう、アジャイルで発生することもあります）、より頻繁にトリアージする必要があるかもしれません。
奇妙な要件（政治、政府による監視、超高リスクプロジェクトなど）のない平均サイズのプロジェクト（9〜18か月）で平均サイズのチーム（5〜7人の開発者）が最も効果的に機能するのは、トリアージ会議を一緒に開催することです。スプリント開始の1〜2日前にバックログをグルーミングします。人々は、チームリーダーが緊急であると考えるもの（顧客の問題への影響が大きい、バグが別のチームをブロックしている、データが破損している）から来ることができます。バグが深刻である場合、または報告者が十分に信頼できる場合は、待機しないでください。
はい、あなたはスプリントを中断しないように努めるべきですが、人々はそれをするでしょう、そうすれば彼らを最も破壊的な方法でそれをやらないようにプッシュするかもしれません。
最初に言うことは、スクラムチームが取り組むほとんどすべてのことは、通常の方法でスプリント計画会議で議論されるべきであるということです。ストーリーがバグであるかどうかにかかわらず、新機能の開発は、プロダクトオーナーが優先順位付けされたスプリントの代わりに行う必要があるのはこの時点です。
第二に、スプリントの混乱が発生します-それは単に頻度の問題です。それがたまにある場合は、プロダクトオーナーを含むチーム全体がスプリントに苦しむ準備ができている必要があります。POは、人々が予期しないタスクに取り掛かる前にそれに備えるべきです。
あなたが考慮する必要がある主なことは、スクラムがあなたに合っているかどうかです。そうではないかもしれません。初心者のPOは、システムをゲームしようとする最初の数か月のフェーズを通過して、チームからより多くの仕事を得ることがよくあります。初心者のプロダクトオーナーが、シャワーを浴びて開発者がコミットする準備ができているものをSprintに追加するために、緊急のバグとしてシャワーで考えた機能がないと説明しているのを見てきました。これが起こっている場合は、スクラムにうんざりし、新しいPOをやさしく追加してください。しかし、チームの仕事の性質上、予期しないバグ、顧客からの問い合わせなどが事実上2週間ごとに処理される必要がある場合、スクラムはあなたに向いていないことをお勧めします。 かんばん はアジャイル方法論のシステムであり、はるかに柔軟で、真に価値があります 計画に従って変更に対応 スクラムではできない方法で、十分に細かいタイムスケール。常にそれを許さないシステムに新たな優先順位を付け加えようとしていることに気づいたら、別のシステムを試してください。