Webアプリを構築するアジャイルチームをスケーリングおよび分割するための最良の方法は何ですか？
私は最近、Webアプリを構築するアジャイル開発プロジェクトのスクラムマスターとして働いている会社に参加しました。
チームはアジャイルチームの最大サイズになりそうです（来週9人になる予定です）。チームを2つのチームに分割する可能性があることについて話しました。スタンドアップを短くする（現時点では過度ではありません）のではなく、スプリントプランニングセッションで人々が完全に退屈しないようにします（これも過度に長くはありません）。
プロジェクトには2つの非常に異なるレイヤーがあります。高度な技術的バックエンド開発（非常に複雑なものなど）とUIデザイン/ビルド/統合です。バックエンドの人たちが技術的な話をしているときは、UIの人たちがゾーンアウトし、その逆もそうです。時間効率を上げるためだけにチームを分割するのは論理的な方法のようですが、コラボレーションと知識の共有を減らすことだけが目的であるという大きな疑問があります。 2つのチームは、チームの他のメンバーが何を構築しているかについて、本当に良い考えを持っていません。
このようなことに対処した経験はありますか？
残念なことに、UIの担当者は複雑なバックエンド作業の詳細を気にしません。これは振り返ってみるとディスカッショントピックのように聞こえます。規律に沿ってチームを分割することは、危険な先例となります。要件担当者がゾーニングを開始し、UIの担当者が何をしているのかを気にせず、自分のチームを求める前に、どれくらいの時間がかかるでしょうか。
私はいつもチームの垂直スライスを支持してきました。 UIは、技術担当者が仕事を簡単にするのに役立つ可能性があるため、技術担当者の意見に耳を傾ける必要があります（ああ、このウィジェットは、このウィジェットを代わりに使用するとどうなるでしょうか）。
個人的には、まずUIのゾーン分割の問題に焦点を当て、次にその機能障害が解決されたら、チームをどのように分割するかについて話し合います。私はUIの連中を侮辱するつもりはありません。おそらく、技術担当者は、UIの連中にとってより親しみやすい議論にするために、もっと多くのことをすることができるでしょう。
他の人が言ったように、チームは新しい組織を決定するために自己組織化することを許可されるべきです。過去の経験から、自己組織化が実際に機能するのは、自分の規律や興味ではなく、全員がチームに関心を持つ場合に限られます。
乾杯！
チームの独立した部分を新しいチームに分割することは確かに良い考えです。大規模なプロジェクトでは、開発者がプロジェクト全体に精通することはほとんど不可能であるため、分割はまだ正式または非公式に行われています。
新しい各チームには、チームリーダー/テクニカルマネージャーが必要です。このマネージャーは、チームの範囲について確かな知識があり、他のチームの作業にも精通しています。
その後、各チームは別々のスクラムミーティングを行うことができ、他のチームのリーダーが出席することができます。このようにして、「退屈な」人の数を減らしますが、それでもチームは他の人が何をしているのかを知っており、うまく共同作業することができます。
チームのスコープが交差しているか、一方のチームが他方に依存している場合、コラボレーションはより重要になります。ただし、チーム全体が出席する必要はありません。チームリーダーがコラボレーションを調整できます。
スクラムの重要な側面は自己組織化です。
質問をチームと話し合って解決してもらうことをお勧めします。
あなたの懸念はすべて根拠のあるものですが、スクラムマスターとしてのあなたの仕事はコーチングと促進であることを忘れないでください。ですから、彼らにこれらの問題をどのように解決するかを尋ねてください。彼らはソリューションを所有し、makeが機能します。
私は付け加えます：一般的に、部門横断的なチームが進むべき道です。
チームを分割するとき、私は常にチームが顧客に価値を提供できる必要があるという事実を心に留めようとしています。あなたの場合、チームにバックエンドとフロントエンドの両方の開発者がいることになります。
フロントエンドとバックエンドの距離はどれくらいですか？予想通り、距離が離れすぎている場合にのみ分割は良いアドバイスです。
バックエンドがデータベーススキーマについて話す場合、これは遠すぎないです。フロントエンドとバックエンドの両方がデータベーススキーマについての議論に耳を傾ける必要があります。
バックエンドがシャーディング、メモリキャッシュ、ディスクレイテンシなどについて話している場合、これは少し遠すぎます（バックエンドは機械的な同情と最適化に重点を置き、フロントエンドは人間の美学に重点を置きます）。
フロントエンドとバックエンドの間に安定した明確なプログラミングインターフェイスはありますか？
安定していて明確であることにより、そのプログラミングインターフェースのユーザー（フロントエンド開発者）は変更に悩まされることはなく、テキストの壁を読んで正しく使用する方法を学ぶ必要がなくなります。
バックエンドチームは、早い段階で適切なAPIとモック実装を提供する必要があります。その後、実際の開発を開始します。
これは、APIが適切に設定されている必要があるという意味ではありません。これは、チームを2つに分割することによる影響の軽減にすぎません。
なぜそれほど多くのアジャイル記事が垂直スライスを推奨しているのですか？ここにいくつかの背景情報があります：
ほとんどのアジャイル記事は、コストの観点から、実際にはバックエンドの作業を避けることを推奨しています。
また、アジャイル記事のほんの一部が新興企業に暗黙のバイアスをかけていたことを忘れないでください。
そして、マーケティングの厳しい現実を忘れないでください-ほとんどの顧客はフロントエンドに対してのみ支払います。
バックエンド作業は費用がかかる傾向があり、遅い見返りがありました。企業がすでに長期的に確立されており、まともな利益を生み出しているのでない限り、既製のテクノロジーとオープンソースライブラリを使用することにより、バックエンドを「アウトソーシング」する方がベターです。
ほとんどのアジャイル記事では、フロントエンドを実装して、バックエンドの切り替えに耐えられるようにすることも推奨しています。このアドバイスは、以前のアドバイスと密接に関連しています。既製のテクノロジーがすべての要件を満たしていない場合は、別のテクノロジーを試してください。
チームの分割による悪影響を軽減できるプラクティス
- 安定したバックエンド
- 安定したAPI
- 不良率の低いバックエンド
- 理由：欲求不満を避けるため
- 方法：単体テスト
- 意味しない：パフォーマンスまたは最適化。機能的に正しい必要があります。
- 継続的インテグレーション
- コミュニケーション、進捗状況、意思決定における透明性
- 2つのチームでの非公式な議論を促進する
- チームメンバー（ゾーン外に出ない人）に、他のチームの会議に出席するように勧めます。
- 不定期の合同会議と合同回顧を設定する
- その他のチームビルディング活動
他の人のように、私は間違いなく垂直スライスで行くことをお勧めします。これらは「機能チーム」と呼ばれることもあります。 Scaled Agile Frameworkサイトで賛否両論を読むことをお勧めします： http://scaledagileframework.com/scaled-agile-framework/team/features-components/
最初に、分割すると、プロダクトオーナーとSDFマスターは、両方のチームのリリースバックログと、各機能チームの個別のバックログを処理できる場合があります。ただし、成長するにつれて、製品機能のバックログを実装し、それを複数のアジャイルチームのリリースバックログにフィードする必要がある可能性があります。そのレベルにスケーリングすると、機能のバックログを管理し、実装のために機能を個々のチームに引き渡す別のチームが必要になる可能性があります。その構造では、次のようなものがあります。
- アジャイルチーム1：SM、PO、部門横断的なチーム。自分のストーリーのチームバックログがあります。
- アジャイルチーム2：SM、PO、部門横断的なチーム。自分のストーリーのチームバックログがあります。
- プログラム管理チーム：プロダクトマネージャー、リリースマネージャー、エンタープライズアーキテクト。より高いレベルのエピックと機能の独自のプログラムバックログがあり、組織化、分析され、チームにフィードバックされます。
SAFeのWebサイト には、大規模なチームを編成するための素晴らしい機能がたくさんあります。チームの大規模なチームに移行するときに役立つものもあります。