Webアプリを構築するアジャイルチームをスケーリングおよび分割する最良の方法は何ですか？

私は最近、会社に入社して、Webアプリを構築するアジャイル開発プロジェクトのスクラムマスターとして働いています。

このチームは、アジャイルチームの最大規模になりそうです（来週は9を予定）。チームを2つのチームに分割する可能性について話しましたが、スタンドアップを短くすること（現時点では過度ではありません）ではなく、スプリントプランニングセッションで人々が完全に退屈しないようにすること（これもあまり長くありません）。

このプロジェクトには、高度に技術的なバックエンド開発者（非常に複雑なものなど）とUIの設計/構築/統合という2つの非常に明確な層があります。バックエンドの人たちが技術的なことを話しているとき、UIの人たちはゾーンアウトしているようです。時間を効率化するためだけにチームを分割する論理的な方法のように思えますが、コラボレーションと知識の共有を減らすことしかできないという点で、私は1つの大きな予約を持っています。2つのチームは、チームの他のメンバーが何を構築しているのかについて本当に良い考えを持っていません。

誰かがこのようなものに対処した経験がありますか？

残念なことに、UI担当者は複雑なバックエンド作業の詳細を気にかけません。これは、回顧展のディスカッショントピックのように聞こえます。規律に沿ってチームを分割することは、要件の人々がゾーニングを開始し、UIの担当者が自分のチームを求めていることを気にかけなくなるまでにどれくらいの時間がかかるかという危険な先例を設定します。

私は常にチームのために垂直スライスを好んでいました。UIは、仕事を簡単にするのを助けることができる非常に人々であるため、技術者が言わなければならないことに耳を傾ける必要があります（ああ、そのウィジェットはあなたにこれをさせるでしょう、代わりにこのウィジェットを使用するとどうなるでしょう）。

個人的には、UIの人たちが最初にゾーニングする問題に焦点を合わせ、その機能障害が解決したら、チームを最適に分割する方法について話し合います。私はUIの人たちを中傷しようとはしていません。おそらく、技術関係者は、UIの人たちにとって議論をより関連性のあるものにするためにもっとできるかもしれません。

他の人が言ったように、チームは新しい組織を決定するために自己組織化することを許可されるべきです。過去の経験から、自己組織化は、誰もが自分の規律や興味ではなく、チームに関心を持っている場合にのみ実際に機能することがわかりました。

乾杯！

チームの独立した部分を新しいチームに分割することは確かに良い考えです。大規模なプロジェクトでは、開発者がプロ​​ジェクト全体に精通することはほとんど不可能であるため、分割は依然として正式または非公式に存在します。

新しいチームにはそれぞれ、チームリーダー/テクニカルマネージャーが必要です。チームマネージャーは、チームの範囲について十分な知識を持ち、他のチームの作業にも精通しています。

その後、各チームは別々のスクラム会議を開催でき、他のチームのリーダーが参加できます。この方法で、「退屈な」人の数を減らすことができますが、それでもチームは他の人が取り組んでいるものを知っており、正常に共同作業を行うことができます。

チームの範囲が交差している場合、または一方のチームが他方のチームに依存している場合、コラボレーションはより重要になります。ただし、チーム全体が存在する必要はありません。チームリーダーがコラボレーションを調整できます。

スクラムの重要な側面は自己組織化です。

質問をチームと話し合い、解決してもらうことをお勧めします。

あなたの懸念はすべて十分に根拠がありますが、スクラムマスターとして、あなたの仕事はコーチし、促進することであることを忘れないでください。したがって、これらの問題をどのように解決するかを彼らに尋ねてください。彼らは、ソリューションを所有し、かつます作ることの仕事。

私は付け加えます：一般に、クロスファンクショナルチームは行く方法です。

チームを分割するときは、チームが顧客に価値を提供できる必要があるという事実を常に念頭に置いています。あなたの場合、チーム内にバックエンドとフロントエンドの両方の開発者がいるでしょう。

1. フロントエンドはバックエンドからどれくらい離れていますか？予想どおり、距離が遠すぎる場合にのみ、分割は良いアドバイスです。

   • バックエンドがデータベーススキーマについて話す場合、これはそれほど遠くありません。フロントエンドとバックエンドの両方が、データベーススキーマに関する議論を聞く必要があります。

   • バックエンドがシャーディング、メモリキャッシュ、ディスク遅延などについて話す場合、これは少し遠すぎます（バックエンドは機械的な共感と最適化に焦点を合わせ、フロントエンドは人間の美学に焦点を合わせます）。

2. フロントエンドとバックエンドの間に安定した明確なプログラミングインターフェイスがありますか？

   • 安定的で明確であることにより、そのプログラミングインターフェイスのユーザー（フロントエンド開発者）が変更に縛られず、正しく使用する方法を学ぶためにテキストの壁を読む必要がなくなります。

   • バックエンドチームは、優れたAPIとモックの実装を早期に提供する必要があり、その後にのみ実際の開発が開始されます。

   • これは、APIを明確に設定する必要があるということではありません。これは、チームを2つに分割した場合の結果を緩和しただけです。

3. なぜこれほど多くのアジャイル記事が垂直スライスを持つことを推奨しているのですか？背景情報を次に示します。

   • 実際、ほとんどのアジャイル記事は、コストの観点から、バックエンドの作業を避けることを推奨しています。

   • また、アジャイル記事の一部がスタートアップ企業に対して暗黙のバイアスを持っていることを忘れないでください。

   • そして、マーケティングの厳しい現実を忘れないでください-ほとんどの顧客はフロントエンドの代金を支払うだけです。

   • バックエンドの作業は費用がかかる傾向があり、ペイオフが遅くなります。長い目で見れば会社が既に設立されており、まともな利益を生み出しているのでなければ、既製のテクノロジーとオープンソースのライブラリに固執することで、バックエンドを「アウトソース」する方が良いでしょう。

   • ほとんどのアジャイル記事では、バックエンドの切り替えに耐えられるようにフロントエンドを実装することも推奨しています。このアドバイスは、前のアドバイスと密接に関係しています。市販のテクノロジーがすべての要件を満たしていない場合は、別の要件を試してください。

4. チームを分割することによる悪い結果を軽減できるプラクティス

   • 安定したバックエンド
   • 安定したAPI
   • 低欠陥率のバックエンド
     • 理由：フラストレーションを避けるため
     • 方法：単体テスト
     • 意味ではありません：パフォーマンスまたは最適化。機能的に正しい必要があるだけです。
   • 継続的インテグレーション
   • コミュニケーション、進捗、意思決定の透明性
   • 2つのチーム間で非公式の議論を奨励する
   • チームメンバ（ゾーンアウトしない人）に、他のチームの会議に出席するように勧めます。
   • 臨時の合同会議および合同回顧をセットアップする
   • その他のチームビルディング活動

他の人のように、私は間違いなく垂直スライスで行くことをお勧めします。これらは「機能チーム」と呼ばれることもあります。Scaled Agile Frameworkサイトの長所/短所を読むことをお勧めします：http : //scaledagileframework.com/scaled-agile-framework/team/features-components/

最初に、分割すると、プロダクトオーナーとSDFマスターが、両チームのリリースバックログと、各機能チームの個々のバックログを処理できるようになります。ただし、成長するにつれて、製品機能のバックログを実装する必要が生じる可能性があり、その後、それを複数のアジャイルチームがバックログをリリースします。そのレベルに拡張したら、機能バックログを管理し、実装のために機能を個々のチームに引き渡す別のチームが必要になる可能性があります。その構造には、次のようなものがあります。

1. アジャイルチーム1： SM、PO、クロスファンクショナルチーム。ストーリーのチームバックログがあります。
2. アジャイルチーム2： SM、PO、クロスファンクショナルチーム。ストーリーのチームバックログがあります。
3. プログラム管理チーム：プロダクトマネージャー、リリースマネージャー、エンタープライズアーキテクト。上位レベルの叙事詩と機能の独自のプログラムバックログがあり、それらは編成され、分析され、チームに送られます。

安全なウェブサイトは、より大きなチームを編成するためのクールなものをたくさん持っている、とあなたはチーム・オブ・チームの大規模に移動すると、いくつかはあなたのための役に立つかもしれません。