SREチームにとってスクラムまたはかんばんは本当に便利ですか？

スクラムやかんばんなどのアジャイルプラクティスは、主にソフトウェア開発用に設計されました。

中断および予定外の作業は、ほとんどのSRE（サイト信頼性エンジニアリング）またはDevOpsチームが行うことの重要なコンポーネントです。Jiraのような追跡システムを使用して作業を管理することは常に役立ちますが、スプリントまたはかんばんはSREチームにとって本当に機能しますか？

私が見る制約は：

• 仕事は本質的に非常に動的であり、優先順位は日々変化します。このため、2週間のスプリント期間は非常に積極的で、不要なオーバーヘッドが追加されます。
• 待機中の人々は問題に別の側面を追加します。時々、複数のチームメンバーがオンコール/事後のタスクに関与する場合があります。
• チームには単一の「製品」がないため、一般的な計画プロセスに身を任せません。
• タスク間の重複がないため、毎日のスタンドアップ会議はあまり意味がないかもしれません
• チームは複数のパートナーチームに関連するタスクに取り組んでいるため、複数のJiraプロジェクトにまたがっている可能性があります。スプリントまたはカンバンボードでは1つのJiraプロジェクトしか許可されないため、すべての作業に対応できない場合があります。

私が話し合った多くのSREから聞いたところによると、スプリント計画はそれらに対してまったく機能していません。コミュニティから、スプリントとかんばんの経験について聞いてみたいと思います。

私もこの質問をscrum.orgで行いました：

SREチームはスクラムを効果的に使用できますか？

DevOpsグループにはアジャイルを使用しませんが、通常のスクラムチームと統合します。ビルドサーバーの最適化など、DevOpsのチームが何かを必要とする場合、関連するチームは 'DevOps'ラベルを付けてPBIをバックログに入れます。私たちのリードは、「DevOps」というラベルの付いたすべての問題を含むJiraのカスタムダッシュボードを持っています。彼らはスクラムマスターと協力して優先順位を取得し、DevOpsエンジニアの1人が、その問題の存続期間中、そのスクラムチームの臨時メンバーであることを任されています。これにより、「お客様」の優先順位に基づいて作業の優先順位を付け、スプリントに努力を結び付け、実行している作業の「クレジット」を取得できるようになります。

これに先立ち、私たちはToDoリストのためにJiraでかんばんを使用しました。残念ながら、チームの1つが何かを必要としていたので、私たちは時々、私たちが取り組む予定であった何かの作業をやめなければならないことがありました。現在、緊急の場合を除いて、彼らは基本的に、バックログとその必要性をリードに伝えるスクラムマスターを介してDevOpsリソース（人/時間）をリクエストします。

アジャイルは、この種の無秩序な環境に非常に適しています。ただし、強調した理由により、純粋な教科書スクラムはあまり適していません。かなりのDevOpsを行うスクラムマスターとして、Jiraでカンバンボードを使用して作業を追跡しました。

かんばんの利点

• チームが行っている作業の視覚化。
• チームのボトルネックを識別します。
• チームが作業を進めることに集中できるようにします。
• いつでも作業を追加できます。
• SREに依存している他のチームのために行われている作業を可視化します。
• 複数のタイプのジョブをカバーする汎用的なものにすることができます。

従来のスタンドアップは有益ではないかもしれませんが、それを変更することを検討してください。優れたスタンドアップミーティングでは、チームメンバーが直面している可能性のある、他のチームメンバーが解決方法を知っているというブロッカーが浮き彫りになります。

IMO：はい、SREチームはスクラムを効果的に使用できます。チームメンバーはスプリントのワークアイテムでしか作業できないと聞いたことも読んだこともないので、スプリントの範囲ですべての時間と労力を考慮する必要があるというのは誤解です。また、あなたの仕事はすべてスプリントに適用できるという誤解もあると思います。したがって、収束的に、スクラムでの作業とその外部での作業を管理する必要があります。

中核となるスクラムは、チームが受け入れる（またはそのような作業に適用できる）作業の性質を継続的に改善するために柔軟に使用されるフレームワーク（アーティファクトとイベントを含む）です。

あなたがする必要があるのは、あなたとあなたのチームが提供できる計画された受け入れられたスプリント作業に提供できる時間と労力と、スプリントの外で計画外の作業に取り組むための時間と労力のバランスをとることです。

すべての作業項目に重大度と優先度の尺度があります。スクラムを検討している場合は、特定の重大度までの作業を受け入れる必要があります。また、（可能であれば）今後の作業の重大度を軽減できる作業を検討する必要があります。また、スプリントを約半分の容量で開始することをお勧めします（最初は容量の方法で時間と労力を関連付けるため、これを判断するのは困難です）。チームの目標は常に、チームが受け入れる作業を提供することであるため、うるさくせず、過度に拡張しないでください。

あなたの仕事の性質は、実際には開発チームの本番バグ修正作業に匹敵すると思います。したがって、スクラムの採用と成功について生産保守チームに相談することをお勧めします。必ずしも、プログラムおよびプロジェクト管理におけるDevOpsエンジニアの経験に限定されるわけではありません。