より大きな組織でサポート/バグ修正はどのように機能する必要がありますか？
大規模なSaaSプラットフォームで作業する約40人のエンジニアのチームがあります。他の組織と同様に、ロードマップから提供したいものの膨大なバックログがあります。しかし、もちろん、バグのバックログ、すべての優先順位、対応する必要のある偶発的な本番インシデントもあります。
私たちはサポート/メンテナンス作業を行ういくつかのモデルを認識していますが、どちらが適切か（公理的に、または単に「適切」）はわかりません。
私たちが知っているモデルは次のとおりです。
完全な所有権：自己完結型の各スクラムチームは、所有するアプリケーションの領域に関連するバグやインシデントに対処します。これは理論的には、システム管理者チームが何が起こっているのか理解できない場合、夜中に起こされることになります。
専用サポートチーム：バグバックログのクリーンアップ、本番インシデントの修正プログラムの作成などを単独で担当するメンテナンス開発者のチーム。これにより、他の開発者はロードマップ作業に専念できます。
ローテーションサポートチーム：各スクラムチームは、いくつかのスプリントをシフトして、上記のようにメンテナンスを行います。しかし永久ではない。
現時点では「完全な所有権」モデルを採用していますが、PO/PMは、正当な理由により、予想よりも大きなバグに対処する必要がある場合に、スプリント速度が悪影響を受ける場合があると不満を述べています。
インシデントのないバグのないシステムを作成する以外に、他の組織はこの問題にどのように取り組みますか？
私も「トータルオーナーシップ」のサポーターです。
それが品質の向上に役立つと思います。 「機能チーム」と「バグチーム」が存在する組織で働いてきました。バグチームは懸命に燃えていて、まだバックログで地面を失っていたようです。結局、彼らはおそらくチームだけである必要があることに気づき、各チームはその領域の機能とバグの両方に責任を負っていました。
あなたが望む最後のものは、開発者が「オンコール」であるということです。 QAや大人の監督なしで、真夜中にコードを変更/ロールアウトすることが正しい答えになる方法はありません。それだけではうまくいきません。
他の人々が示唆しているように、顧客をオンラインに戻すためにプッシュできる小さなボタンのセットを持っているある種のDevOpsまたはサポートスタッフがいるはずです。正確には何がどのようにソフトウェアやサービスの性質に依存します。インシデントを書き留め、適切なスクラムチームに転送できます。
私の組織では複数の製品をサポートしており、各チームはサポートリーダー、製品の所有者、および最初の処置を行うことができる技術リーダーとのバグのトリアージ会議を毎週開催しています。
また、スプリントのキャパシティを80％に抑えるように計画しているため、予期しないカスタマーサービスのエスカレーション（およびその他の驚き）に備えてバッファを用意しています。これは、何かが発生した瞬間から計画された作業に影響を与えていないことを意味します。また、サポートに関して静かなスプリントがある場合は、いつでも1つまたは2つのストーリーを取り入れて、過剰な容量を埋めることができます。
私の経験では、バグには次の2つの種類があります。
- 昨日のように修正する必要があります...赤い点滅ライト。サイレン。ステータスを要求するボス。
- ああ。うん。修正します。ある時点で。多分。
最初のケースでは、それが何であるかです。これは「スプリント」や計画、速度やポイントには関係ありません。それはできるだけ早く行われる必要があり、それはあなたの計画を台無しにするでしょう。あなたにできることは何もありません。あなたはこれのために何らかのローテーションをしている人を望まないで、あなたはこれで最も良い仕事をすることができる人を望みます。そして、あなたは今それを望んでいます。あなたにできることは何もありません。ほとんどの場合、それを望むのはベロシティについて文句を言うのはまさにPO/PMです。そのような事件の後で彼らに彼らの計画を回復する方法を理解させてください。
2番目のケースでは、計画を安定させる必要があります。しかし、明らかに、開発者が本当にバグレポートに飛び込んだ場合、何が明らかになるかはわかりません。したがって、テスト済みのスクラムツール Timeboxing を使用します。最初のスプリントにタイムボックスを割り当てて、修正する必要があるものを明らかにします。たとえば、何が悪いのかを理解するのに1人が1営業日かかります。そのバグを修正するのもうまくいくなら、素晴らしい。早くやれよ。そうでない場合、あなたがそれを理解し、適切に見積もることができる次のスプリントのストーリーを書くことができる限り、あなたのストーリーは「完了」しています。そのタイムボックスが終了し、まだバグを理解していない場合、そのストーリーはスプリントの最後に完了しておらず、おそらく話し合う必要があります。何が起こっても、タイムボックス全体でこのスプリントの安定性があり、バグレポートだけでなくハードデータがあるので、次のスプリントの見積もりが向上します。
言うまでもなく、スクラムには製品の所有権が必要です。別のチームが背後で製品に任意の重大な変更を加えることができる場合、適切なスクラムを使用することはできません。
私が見てきた最善のアプローチは、「完全な所有権」と「専用のサポートチーム」の組み合わせです。
開発チームアプリはすべてのバグを所有しており、優先順位を付けてスプリントに修正を書き込む必要があります。
サポートチームアプリをデプロイし、ライブでの問題に対応します。ただし、リリースのロールバック、サーバーの再起動、バグの発生などによってのみ。コードは変更されません。
したがって、ライブでの「train smash」バグの場合、あらかじめ決められた応答があります。以前のバージョンにロールバックして顧客をオンラインに戻し、バグをバックログに入れて、チームが次のスプリントに優先順位を付けられるようにします。
これで、開発チームへのプレッシャーは「サイトがダウンしています!!」ではなくなりました。しかし、心配する必要はありませんでした」最後のリリースがロールバックされました！これらの機能が必要です！」プロジェクトマネージャーに問題への対処方法の柔軟性を提供します。
コード修正を壊して、真夜中にライブサーバーに配置することは、実際に誰もがやりたいことではありません。開発プロセスとは別に、計画的かつ段階的な導入は、影響を受けるユーザーを制限し、リハーサルした即時対応を提供することにより、これらの問題をスムーズにします