生産的なチームの構築

エンジニアは、集中して集中できる環境で成長します。 チームは多くの場合、気を散らしたり競合する優先事項に直面したりするため、エンジニアは状況を変えて注意を分散せざるを得ません。 彼らはヘッズダウンの時間とヘッズアップの時間のバランスを取るのに苦労しています。 新しい機能を追加するには、チーム メンバーが頭を下げて集中する必要があります。 顧客の問題に対応し、実際のサイトの問題に対処するには、チームが先頭に立ち、何が起こっているかを認識する必要があります。

気を散らすことを軽減するために、チームは 2 つのクルーに分けることができます。1 つは機能担当、もう 1 つはライブサイトの健全性担当です。

2 人の乗組員によるアプローチにより、生産性と予測可能性が向上します。 実装を成功させるには、次の重要な要素が必要です。

• 明確に定義された乗組員の役割
• 明確に定義された乗組員ローテーションプロセス
• 乗組員の人数を頻繁に調整する

特集スタッフ

特集クルー、または F クルー は、未来に焦点を当てています。 彼らは、高品質の機能を構築して出荷するという明確な使命と目標を持った効果的なユニットとして働いています。

F クルーは、ライブ サービスの日々の混乱から保護され、作業の設計、構築、テストに十分な時間を確保できます。 気を散らすものは最小限に抑えられ、ランダムに発生する問題を解決する必要がなくなります。 メールはめったにチェックせず、重大な問題でない限り、他の問題に巻き込まれないようにすることが推奨されます。

F クルーのメンバーが会話に参加したり、時折電子メール スレッドに巻き込まれたりした場合、他のチーム メンバーは次のように叱責する必要があります。「あなたは F クルーのメンバーなのに、何をしているのですか?」 F クルーの場合 - クルー メンバーは重大な問題に対処する必要があるため、顧客クルーにそれを委任し、機能の作業に戻ることが推奨されます。

F クルーは、小規模な機能セットに群がる緊密なチームとして運営されています。 適切な進行中の作業 (WIP) 制限は、4 ～ 6 人で実行中の 2 つの機能です。 緊密に連携することで、深い共有コンテキストを構築し、大ざっぱなコードレビューでは見逃してしまうような重大なバグや設計上の問題を発見します。 専任のスタッフにより、より予測可能なスループット率とリードタイムが可能になります。 チームメンバーは、F クルーのことを穏やかで集中力があるとよく言います。 彼らは、ある機能に深く焦点を当て、そこに全神経を捧げることに安らぎと元気を与えてくれると感じています。 人々は、F クルーでの時間をリフレッシュし、達成感を感じながら仕事を終えます。

カスタマークルー

カスタマー クルー、またはC クルー は、現在 に焦点を当て、顧客およびライブサイトの問題、バグ、テレメトリ、監視に対する最前線のサポートを提供します。 C クルーはコンピューターの周りに群がり、重大なライブサイトの問題をデバッグすることがよくあります。 彼らの最優先事項は、ライブサイトの健康です。 この環境に重点を置き、専門的なデバッグおよび分析スキルを構築します。 カスタマー クルーは、チームの残りのメンバーを気を散らすものから守るため、シールド チームとよく呼ばれます。 C クルーは、今後の機能に取り組むのではなく、顧客と現在の製品との橋渡しをします。 乗組員は電子メール、Twitter、その他のフィードバック チャネルで積極的に活動しています。 顧客は自分の意見が聞かれていることを知りたいと思っており、C クルーの仕事は顧客の意見を聞くことです。 C クルーは、顧客から報告された問題を即座に優先順位付けし、ブロックされている顧客に迅速に対応して支援します。

大量のタスクが舞い込む中、ペースの速い C クルーと一緒に仕事をするのは、時には爽快な気分になることもあります。 忙しい週に、彼らは複数のメール、ライブサイト調査、バグに対処します。 業務が落ち着いてくると、テレメトリとレポートの改善に取り組み、サービスの維持を容易にするために時間を投資します。

C クルーは、チーム メンバーを他の優先事項から外すことなく問題に対処できるようにし、顧客やパートナーの意見を確実に聞くことができるようにします。 質問や問題への対応は、C クルーの誇りになります。 ただし、このペースでは体力を消耗する可能性があり、頻繁にクルーを交代する必要があります。

クルーのローテーション

明確に定義されたローテーションプロセスにより、2 人体制のシステムが機能します。 単に乗組員を交換することもできますが (F 乗組員が C 乗組員になり、その逆も同様)、乗組員間および乗組員内での知識の共有が制限されます。 代わりに、毎週のローテーションを選択してください。

毎週の終わりに、チームがクルー間で誰を交換するかを決定する短い交換会を実施します。 ホワイトボード チャートを使用して、各クルーに現在誰がいるのか、いつ入れ替わったのかを追跡できます。 通常、各乗組員の勤続年数が最も長い人が互いに交換する必要があります。 ただし、どの週でも、ライブサイトの調査や特集の作業を完了するために残りたいと思う人がいるかもしれません。 柔軟性はありますが、誰かが乗組員に長くいるほど、交代する必要がある可能性が高くなります。

毎週のローテーションは、チーム内での知識のサイロ化を防ぎ、スタッフ間の情報と視点の一定の流れを確保するのに役立ちます。 エンジニアが頻繁に移動することで、チームの作業に関する共有知識が生まれ、C クルーが他の人の助けを借りずに問題を解決するのに役立ちます。 多くの場合、新しい F クルー メンバーは、これまで見落とされていた設計やコードの欠陥をすぐに発見します。

クルーの規模

チームの健康を維持するために、乗組員の人数は異なります。 チームがライブサイトで発生する問題の発生率が高い場合、または技術的負債が多い場合は、C クルーの規模が大きくなり、その逆も同様です。 サイズを毎週調整すると、チームの成果物と依存関係の予測可能性が高まります。 数週間以内に、チームは大規模なリリースからのフィードバックに対処するために全員を C クルーに移動させる可能性があります。

この戦略により、経営陣とのコミュニケーションが簡素化されます。 2 人体制でなければ、エンジニアは複数の作業を同時に行うことがよくあります。 1 週間にいくつかの注意散漫が発生すると、進行中の機能が遅れることがよくあります。 その結果、チームは将来の機能作業のスケジュールを自信を持って提示できない可能性があります。

専任の F クルーにより、予測可能なスループットとリードタイムが実現します。 リソースをクルー間で分割すると、チームが毎週および各スプリントで何を達成できるかについて、チーム内および管理者に対する説明責任が高まります。

次のステップ

2 人体制は、チームがエンジニアがどこに時間を費やすべきかを理解し、多くの競合する優先事項を進めるのに役立ちます。

生産性と予測可能性の向上に加えて、2 乗組員システムはチームの士気を高めることができます。 各チームのエンジニアは自分たちの役割と責任を明確に理解し、より独立して、より大きな説明責任を持って機能します。 このアプローチは、開発と運用の両方を担当する DevOps チームにとって理想的です。 ただし、このアプローチは、競合する優先事項を扱うほぼすべてのアジャイル チームに適用できます。

Microsoft は世界最大のアジャイル企業の 1 つです。 Microsoft が DevOps 計画においてチームを組織する方法を学びましょう。