私たちの会社は最近、ほぼ一人（Joe）によってコード化された製品でスクラムに移行しました。私たちは、私たちのプロセスに統合しようとする既存の顧客との関係をサポートしています。
とりあえず、次の方法を試しました。
しかし、私たちはそれを機能させることができませんでした：
あなたはすでに同じような状況に直面しましたか？どのようにしてそれから抜け出したのですか？
注：現在のところ、サポート担当者を1人にすることはできません。今後ともよろしくお願いいたします。
回答:
私たちは、チームのより若い（または最新の）開発者を中心にローテーションする「サポートプログラマー」を指定することで、非常に類似したアプローチを採用しました。彼らは、コードを最もよく知っている開発者にそれを引き継ぐほうがより速くても、他の開発者に尋ねる前に問題を理解するために本当に一生懸命努力することを勧められました。このようにして彼らはコードベースを学ぶことを余儀なくされ、あなたは人々を「ゾーン」から叩き出して生産性を破壊することを避けました。また、この機能を実現するために、サポートされていないプログラマにエンドアラウンドを行わせないようにするためのメカニズムを組み込む必要があります。
重要な点は、サポートの問題を解決する最も速い方法が常にチームの時間を最も効率的に使用できるとは限らないことをチームが理解する必要があることです。この構造の目標は、すべてのコストでその生産モードにいる人々への割り込みを最小限に抑えることであることをチーム全体が知っていることを確認してください。
とは言っても、サポートプログラマーは100％サポート呼び出しに専念していませんでした。彼らはスプリントのケースで作業しましたが、最も優先度の低いアイテムで作業することになっていたため、多くのサポート問題に巻き込まれた場合、ケースを完了しなかったという事実はそれほど大きな懸念事項ではありませんでした。 。
スプリントでトイレに行くことをどのように含めますか？開発者が自宅で子供たちと遊ぶ時間をどのように含めますか？睡眠時間を含めてどうですか？
もちろん私は皮肉なことですが、答えは、スプリントの計画にサポート時間を含めるべきではないということです。スプリント計画に含める必要があるのは、スプリントの成果物に直接関連付けられているタスクのみです。
リソースがサポートに多くの時間を費やすことになっている場合、その開発者が利用できるリソース時間は少なく、そのスプリントになります。そのスプリントに含まれる機能セットは、この事実を反映する必要があります。
私の考えでは、「サポート」作業には2種類あります。最初の種類は、今すぐ修正する必要がある緊急事態です。スプリントの一部として実際に計画して見積もることができない、より多くの運用タイプの仕事であり、消火活動です。2番目の種類はバグレポートであり、スプリントに見積もられ、優先順位が付けられ、計画されます。他の話と同じように扱われます。多くの場合、第1種は第2種になります。火を消し、バグレポートを作成して実際の修正を行い、二度と起こらないようにします。この記事の残りの部分では、私は前者について話している：今計画されていなくてはならない緊急作業。
チームから離れてサポート作業を行うと、チームの速度が低下します。次のスプリントの容量を決定するには、履歴速度を使用する必要があります。リリース作業からサポート作業に移行するために必要なコンテキスト切り替えは、オーバーヘッドがいくらかあることを意味しますが、スプリントにかみついた作業は、スプリントでこれまでに行われた作業の量を考慮する必要があるため、通常の時間あなたはサポートに入れ、そしてコンテキスト切り替えのオーバーヘッドは自動的に考慮されるべきです。
これはスプリント作業だとは思わない。それは別個のものであり、スプリント作業よりも優先されるべきです。したがって、それはチームの速度に影響を与え、次のスプリント中にどれだけの作業を実行できるかを決定するときにその速度を使用して「計画」されます。