私はアジャイルチームで働いています。
リリース済みの製品があり、今後のリリースに向けて取り組んでいます。
スプリントごとに、リリースされた製品のバグを修正するために 0 ～ 5 枚のチケットを受け取ります。
私たちのチームは、ソフトウェアエンジニア (新規開発を担当) と保守ソフトウェアエンジニア (チケットを担当) で構成されています。
私の質問は、スプリント計画中のメンテナンス時間をどのように説明するかです。
現在、チケットを解決するために数時間を割り当てるメンテナンス バッファーと呼ばれるストーリーがあります。そして、私たちはそれをバッファーとして使用しているので、チケットを受け取っていないスプリントでは、バッファー内の時間を開発作業に使用しています。
これは物事を行うための良いアジャイルな方法ではないと思いますが、何か提案はありますか?
あなたが言及したアプローチは、 Should Story Points Be Assigned to the Agile Defect Story? のMike Cohn によっても取り上げられています。、彼が書いているところ：
チームは、このアクティビティのユーザー ストーリーを次のように書くことがあります。より高品質に。」そのようなユーザー ストーリーを明示的に作成しないチームでさえ、通常、タスクボードに行を追加して、アジャイルな欠陥とバグ修正を可視化し、追跡します。
現在、チケットを解決するために数時間を割り当てるメンテナンス バッファーと呼ばれる話があります。これは、アジャイルの欠陥をバグ修正するためにポイントを割り当てることを推奨している Mike Cohn の記事に記載されているものと似ています。
次のような他のオプションもある可能性があります
緊急事態/ホットフィックスの場合はどうすればよいですか?
その緊急のバグを修正するために必要な重要度と労力を評価する必要があります。チームがすべてを破棄してホットフィックスの作業を開始するかどうかを決定するのは、プロダクト オーナーの責任です。その理由は、常に顧客が最優先であり、納品された製品が期待される価値を提供していない場合、不完全な製品に機能を追加しても意味がないからです。例外的なケースの処理を妨げたり、重大な問題を無視するように指示したりするフレームワークや方法論はありません。そのため、現在のスプリントをキャンセルするか、チームの 1 人 (または数人) のメンバーがホットフィックスを処理できる場合は、現在のスプリントの機能またはバグを緊急のバグ修正と交換できます。
Production Support and Scrumの Geoff Watts の言葉:
問題が真の緊急事態である場合、プロダクト オーナーは、そのコストを認識している限り、「緊急カード」をプレイする権限を持っている必要があります。ゴール。
プロダクト オーナーは、次の 3 つのオプションのいずれかを実行できます。
簡単に言うと、バグをプロダクト バックログ アイテム (PBI) として提起し、プロダクト バックログ内の他の PBI に対して優先順位を付けます。このようにして、最も重要なことが最初に行われることを常に確認できます。
スクラムの不文律契約の一部は、ビジネスが開発チームを妨害しないことに同意することです。これは、パフォーマンスを向上させる方法の一部です。
スプリントの期間を待てないホット/緊急のチケットを受け取った場合、プロダクト オーナーを説得する必要があります。プロダクト オーナーは、ホットなアイテムを導入する最善の方法について開発チームと交渉します。
ただし、これは規則ではなく例外である必要があります。あなたが暗示しているように、修正するバグがたくさんある場合は、スクラムではなくカンバンを使用して、別のチームでメンテナンス/欠陥修正を実行したくなるでしょう。