エンジニアは、集中して没頭できる環境で力を発揮します。 多くの場合、チームは注意をそらされ、競合する優先事項に直面し、エンジニアはコンテキストを変えて、集中力を分散させられます。 彼らは集中して作業する時間と周囲に気を配る時間のバランスを取るために苦労しています。 新機能を追加するには、チーム メンバーが頭を下げて集中する必要があります。 顧客の問題に対応し、ライブ サイトの問題に対処するには、チームが頭を上げて何が起こっているかを認識する必要があります。
気を散らすのを軽減するために、チームは 2 人 のクルーに分けることができます。1 つは機能用、1 つはライブ サイトの正常性用です。
2 人のスタッフによるアプローチにより、生産性と予測可能性が向上します。 正常な実装は、次の重要な要素に依存します。
- 明確に定義された乗組員の役割
- 明確に定義された乗組員の交代プロセス
- クルーのサイズを頻繁に調整する
フィーチャー クルー
機能クルー ( F クルー) は、 未来に焦点を当てています。 高品質な機能を構築して出荷するという明確な使命と目標を持つ効果的なユニットとして機能します。
F クルーは、ライブ サービスの日常の混乱から保護され、作業を設計、構築、テストする時間があることを確認します。 彼らは気を散らすものが最小限に抑えられ、ランダムに発生する問題を修正する必要がない自由を享受することができます。 メールをめったに確認せず、重要な場合を除き、他の問題に取り込まれないようにすることをお勧めします。
F クルーメンバーが会話に参加したり、時々メールスレッドに吸い込まれたりした場合、他のチームメンバーは「あなたはF クルーにいるのに、何をしているんですか？」と注意する必要があります。F クルーメンバーが重大な問題に対処する必要がある場合は、それを顧客対応チームに委任し、本来の業務に戻る必要があります。
Fチームは、緊密なチームとして、小規模な機能セットに集中的に取り組んでいます。 良好な進行中の作業 (WIP) の制限は、4 人から 6 人のフライト中の 2 つの機能です。 緊密に連携することで、深い共有コンテキストを構築し、カーソルのあるコード レビューで見逃される重大なバグや設計上の問題を見つけます。 専用のクルーは、より予測可能なスループットレートとリードタイムを可能にします。 多くの場合、チーム メンバーは F クルーを穏やかで集中的と見なします。 彼らは機能に深く集中し、心が安らぎ元気を取り戻すことを見出すために、完全に注意を払います。 人々は、リフレッシュして達成された感じでFクルーに時間を残します。
顧客チーム
顧客クルー ( C クルー) は 、現在 に焦点を当て、顧客とライブ サイトの問題、バグ、テレメトリ、監視に対する現場サポートを提供します。 C クルーは、多くの場合、コンピューターの周りに寄り添い、重要なライブ サイトの問題をデバッグします。 1 番の優先度はライブ サイトの正常性です。 この環境に特化して、彼らはデバッグと分析の専門スキルを磨いています。 顧客の乗組員は、多くの場合、チームの残りの部分を邪魔から保護するため、 シールド チームと呼ばれます。 C クルーは、今後の機能に取り組むのではなく、顧客と現在の製品の間の橋渡しです。 クルー メンバーは、電子メール、Twitter、およびその他のフィードバック チャネルでアクティブです。 顧客は自分の声が届いていると感じたいと思っており、Cクルーの仕事はそれをしっかり聞くことです。 C クルーは、顧客から報告された問題を直ちにトリアージし、ブロックされた顧客に迅速に関与して支援します。
多くのタスクを受け入れるので、ペースの速いCクルーに取り組むのは、時には爽快です。 忙しい 1 週間に、複数のメール、ライブ サイト調査、バグに対処します。 運用が静かになるにつれて、テレメトリとレポートの改善に取り組み、サービスの維持を容易にするために時間を費やします。
C クルーは、チーム メンバーを他の優先順位から外すことなく問題に対処し、顧客とパートナーの意見を確実に聞くことを可能にします。 質問や問題に対する応答性は、C クルーにとって誇りのポイントになります。 しかし、このペースは疲労を生じさせるため、乗組員の頻繁な交代が必要です。
クルーのローテーション
明確に定義された回転プロセスにより、2 人の乗組員システムが機能します。 単に乗組員を入れ替えることができます(FクルーはCクルーになり、その逆も同様ですが)、これにより乗組員間と乗組員内の知識共有が制限されます。 代わりに、週単位のローテーションを選択します。
各週の終わりに、チームがグループ間で誰をスワップするかを決定する短いスワップミーティングを実施します。 ホワイトボード グラフを使用して、各クルーの現在のユーザーと、それらのスタッフがスワップされた日時を追跡できます。 各乗組員の最も経験豊富な人々は、通常、交代する必要があります。 ただし、特定の週に、誰かがライブ サイトの調査や機能に関する作業を完了したい場合があります。 柔軟性はありますが、誰かが乗組員に長くいるほど、スワップされる可能性が高くなります。
週単位のローテーションは、チーム内の知識のサイロを防ぎ、スタッフ間の情報と視点の一定の流れを確保するのに役立ちます。 エンジニアの頻繁な移動により、チームの作業に関する知識が共有され、C クルーが他のユーザーの助けを借りずに問題を解決するのに役立ちます。 多くの場合、新しい F クルーメンバーは、以前見過ごされていた設計やコードの欠陥をすばやく見つけます。
搭乗員のサイズ
クルーのサイズは、チームの正常性を維持するために異なります。 チームがライブサイトの問題の受信率が高い場合、または技術的負債が多い場合、C クルーは大きくなります。その逆も同様です。 サイズを毎週調整すると、チームの成果物と依存関係の予測可能性が向上します。 数週間後には、チームが全員を C クルーに移動して、大きなリリースからのフィードバックに対処する場合があります。
この戦略により、管理との通信が簡略化されます。 2人乗りのシステムがなければ、エンジニアは多くの場合、複数の作業を同時に行います。 1週間に複数の妨害が発生すると、進行中の機能の遅延がしばしば生じます。 その結果、チームは将来の機能作業のタイムラインを自信を持って提供できない可能性があります。
専用のFクルーは、予測可能なスループットとリードタイムにつながります。 スタッフ間でリソースを分割すると、チーム内のアカウンタビリティが向上し、毎週および各スプリントでチームが何を達成できるかを管理できます。
次のステップ
2 人乗りのシステムは、エンジニアが時間を費やす必要がある場所をチームが理解し、多くの競合する優先順位を進めるのに役立ちます。
生産性と予測可能性の向上に加えて、2 人の乗組員システムはチームの士気を高めることができます。 各チームのエンジニアは、自分の役割と責任をより明確に理解し、より独立して、はるかに大きな説明責任を持って機能します。 このアプローチは、開発と運用の両方を担当する DevOps チームに最適です。 ただし、このアプローチは、競合する優先順位を扱うほぼすべてのアジャイル チームに適用できます。
Microsoft は、世界最大のアジャイル企業の 1 つです。 Microsoft が DevOps 計画でチームを編成する方法について説明します。