1
開発スタックのスライス-対角線？
新しいプロジェクトが進行中です。現時点では、開発者はチームAとチームBの2つのチームに分かれています。このプロジェクトには、開発スタック全体での開発が必要な2つの部分があります。以下に示す非常に単純化されたスタックのサンプル： プロジェクトの各部分はスタック全体にわたる開発を必要とするため、通常はチームB内で作業を分解し、異なる部分間の相互作用を設計および実行するフルスタック開発者アプローチを期待します。 しかし最近、チームAがスタックの特定の部分を担当することを望んでいることを学びました。チームは、2つのチームの分割を提案しています。チームBからの開発はありません。分割は次のようになります。 私にはこれは非常に不自然に感じます。各チームには、これらを達成するための異なる明確な目標とタイムスケールがありますが、チームBは機能を実装するためにチームAに依存します。提案された解決策は、共通のインターフェイスが事前に定義されていることです（おそらくプロジェクトには2年のタイムスケールがあり、多数になる可能性があります）。チームAは、独自の目標を設定しているにもかかわらず、これらのインターフェイスに必要なビットを早期に開発し、チームBは、すぐに短期間のすべての呼び出しをスタブして、進行できるようにします。 私はこのアプローチについて懸念があります： インターフェイスは変更される可能性があり、チームAは変化する要件に対応するための帯域幅または時間がない場合があります。 チームAのコードのバグにより、チームBの進行が妨げられる可能性があります。また、チームAが異なる優先順位キューを持っているため、これらを修正する優先事項ではない可能性があります。 チーム全体に広がる知識の欠如-チームBは、内部で何が起こっているのかを完全に理解していない可能性があり、そのために設計上の決定が下される可能性があります。 業界の多くの企業にはサブチームがあり、これに対処できる必要があることが示唆されています。私の理解では、一般的に、チームは当初の予想方法（フルスタック）に分割されるか、以下のようにテクノロジースタックを分割します。 ですから、私は他の業界が何をしているかを知りたいと思っています。ほとんどの分割は垂直/水平ですか？対角線分割は意味がありますか？対角線の分割が発生した場合、私の懸念は有効であると思われ、チームBが懸念すべきことは他にありますか？私はおそらく、チームBの成功または失敗の責任を負うことに注意してください。