過剰なプロセスや会議で全員を煩わせることなく、別々の製品チームを調整するにはどうすればよいですか？
約1年前、私たちはレガシーEコマースプラットフォームをゆっくりと分解し、より小さな書き直されたサービスに置き換える旅を始めました。現在、いくつかのチームがあり、それぞれがWebサイトの別々の領域に焦点を当てています。チェックアウト、カート、検索など
これらの各チームは、担当する機能を提供する多数のサービスを管理しています。私たちが直面している課題は、同じ慣行に従い、高レベルのアーキテクチャ要件を尊重し、ダンプせずに適切に類似したAPIを維持する（たとえば、カート/バスケットなどの概念に同じ用語を使用する）方法でこれらのチームを調整する方法です。たくさんの会議とそれらへのプロセス？現在のセットアップの大きな利点の1つは、開発者が権限を与えられていると感じ、それを完全に削除したくないということです。
異なるチームの相互理解を促進するために、 ドメイン駆動設計 を検討することができます。次の利点があります。
- チーム間で同じ用語を使用する（「ユビキタス言語」）
- 異なるチームに値する独立したサブドメインを区切るための制限されたコンテキストの使用（例：販売および会計）
- コンテキストマップの使用。境界のあるコンテキストと、さまざまなチームで使用される関連用語との関係を明確にします。
ドメイン駆動設計は、優れたAPIを設計するための原則も定義します。ただし、設計原理は十分ではありません。また、それぞれのニーズと要件を特定し、最も適切なAPIを定義するために、チーム間の協力も必要です。これを処理する1つの方法は、統合チーム（グローバル統合チームとサブチーム間のリンクを作成するために各チームの1人の代表者）を持つことです。これは、 スクラムのスクラム の原則に従って構成するのが最適です。
統合の問題を超えて、スクラムのスクラムアプローチは 小さなチームを超えてスクラムをスケールする にも適しています。そのため、サブチーム間でリリースとスプリントの同期を維持することも良いオプションです。