スプリントプランニング中にチケットを処理する方法

Question

私はアジャイルチームの中で働いています。

私たちにはリリースされた製品がありますが、今後のリリースではまだ作業中です。

リリースされた製品のバグを修正するために、0から5のチケットをどこからでも受け取ることができます。

私たちのチームは、（新しい開発を担当する）ソフトウェアエンジニアと（チケットを扱うための）メンテナンスソフトウェアエンジニアで構成されています。

私の質問は、スプリント計画時のメンテナンス時間をどのように考慮するかです。

現在、チケットを解決するために数時間を割り当てるメンテナンスバッファというストーリーがあります。バッファとして使用するようにしています。したがって、チケットを受け取らないスプリントでは、開発作業のためにバッファ内の時間を使用します。

私は、これが良いやり方ではないと感じています。

Answer 1

あなたはまた、彼は書き込みShould Story Points Be Assigned to the Agile Defect Story?にマイク・コーンで覆われて言及したアプローチ：チームのようなこの活動のためにユーザーストーリーを書き時々

は：「 ユーザーとして、私は、少なくともたい1535のバグが修正されました」または「ユーザーとして がこのスプリント修正バグを約50時間費やして、アプリケーション が徐々に高品質になるようにしてほしい」 のチームでも、通常はその タスクボードに行が含まれており、アジャイルな欠陥とバグ修正が表示され、 それを追跡します。

あなたは現在、あなたは彼がアジャイルな欠陥を修正バグのためにポイントを割り当てることをお勧めしますマイク・コーン氏の記事に記載されているものと同様のものであるチケットを解決するために、いくつかの時間を割り当て、メンテナンスバッファと呼ばれる物語を持っています。

各スプリントでのバグ修正のためのいくつかの時間を設定する

• のように、あまりにも他のオプションがあるかもしれません。すべてのチームメンバーがバグを処理する日/週の設定時刻になる可能性があります。
• バグを部分的に実装された機能とみなして、同じスプリントバックログに含めます。これはマークサマーによってManaging Bugs in Scrumで議論されています。

緊急時/ホットフィックスの場合はどうすればよいですか？

緊急の不具合を修正するために必要な臨界と労力を評価する必要があります。チームがすべてを落として修正プログラムの作業を開始するかどうかは、製品所有者次第です。顧客が常に最初に来て、納品された製品が予想通りに提供されていないという理由で、値の場合、不完全な製品に多くの機能を追加することはありません。フレームワーク/方法論では、例外的なケースを扱うことを中止したり、重大な問題を無視するよう指示したりすることはありません。現在のスプリントをキャンセルすることができます。または、ホットフィックスがチームメンバーの1人（またはいくつかのメンバー）が処理できる場合は、現在のスプリントの機能やバグを緊急バグ修正と交換することができます。ジェフ・ワッツの言葉で

Production Support and Scrumから：問題は真の緊急事態である

場合は、プロダクトオーナーは、彼が認識している限り、「緊急カード」プレイする 権限を持っている必要があります 私たちが予定していたアイテムを完了させずに、 の可能性があり、スプリント目標を危険にさらしてしまうコスト。彼/彼女は、現在のスプリントの目標は、緊急を追加し、より高い優先度

を持っていることを決定しましたので、

• バックログに緊急の欠陥を追加：プロダクトオーナーは、3つのオプションのいずれかを行使することができ

現在のスプリントに欠陥がそれも、現在のスプリントをキャンセルスプリントゴール

を危うく修正プログラムを行い、その後、その

後に新しいスプリントを開始する可能性が十分に重要であるため、

Answer 2

簡単に言えば、バグを製品バックログアイテム（PBI）として調達し、製品バックログ内の他のPBIとの優先順位付けを行います。このようにして、最も重要なことが常に最初に行われることを常に確認することができます。

スクラムの書面による契約の一部は、開発チームを中断しないことに同意したことです。これは、パフォーマンスを向上させる方法の一部です。

スプリントの期間中待つことができない熱い/緊急のチケットを受け取った場合、ホットオーナーを紹介する最善の方法について開発チームと交渉するプロダクトオーナーを説得​​する必要があります。

ただし、これはルールではなく例外である必要があります。もしあなたが意味するように、バグ修正がたくさんある場合は、スクラムではなくKanBanを使って別のチームでメンテナンス/欠陥修正を実行したいと思うでしょう。

Answer 3

私はこれが良いことではないことに同意します。質問は、メンテナンスのための計画を立てるか、チームがユーザーのストーリーと欠陥の両方に最適に活用されていることを確実にして、不具合の修正を含めて継続的に品質コードを出力することを本当の目的としていますか？

私はデレクが提案したものからさらに一歩進んで、カンバンとスクラムを一緒に使用します - スクラムバンはますますキャッチしています！どのスプリントでも0-5の欠陥があると言われているので、あなたの「故障の要求」は明らかに変わりますし、メンテナンスエンジニアの能力も必要です。 0または1または2の欠陥があるとき、彼らは何をしますか？私は彼らも「価値の要求」 - 新しいユーザーストーリーに貢献していると推測します。

ここは、かんばんが輝く場所です。あなたのかんばんボードの実際のデザインはあなたのチームによって分析される必要がありますが、作業を行うための現在のプロセスを反映するシンプルな2枚のスイムレーンボードから始めることができます。簡単な例を以下に示します -

をここでは、いずれかのレーンでの作業のために利用可能なすべてのあなたのエンジニアが持っています。作業が進むにつれて、誰が自由に持ち上げることができるかに応じて、取り上げることができます - 彼らは作業を引き込み、作業します。ステージングではスプリントのためにバッチ処理を行い、一度にバッチを展開します。すべてのエンジニアは、両方のレーン内の項目に取り組む、ここで再び

-

代わりに、あなたは完全に別のユーザーストーリーや欠陥のためのレーンがあるかもしれません。ただし、不具合の修正は、顧客が修正して承認した時点で（該当する場合）直ちに導入することができます。あなたのバリューデマンドでは、現在と同じプロセスを続け、各スプリントが完了したら展開します。これらのアプローチのいずれかの

利点がある -

1. あなたはどちらの状況で動作するように人々の大きなプールを取得します。
2. 潜在的に、応答時間が短縮され、SLAパフォーマンスが向上します。
3. 誰もが新しいものに取り組む幸せなチームができます。ほとんどのエンジニアはメンテナンスを望んでいません:-)

もちろん、基本的な分析に基づいています。かんばんやスクランバンに慣れていない場合は、David Anderson（Kanban）とCorey Ladas（Scrumban）とYuval Yeret、Jim Benson、Masa Maedaなどの書物を読んで自分自身を良くする必要があります。また、www.swiftkanban.comに接続することもできます。

希望すると便利です。