開発スタックをスライスする-斜めに？
新しいプロジェクトが進行中で、現時点では開発者はチームAとチームBの2つのチームに分かれています。このプロジェクトには2つの部分があり、開発スタック全体での開発が必要です。以下に示すスタックの非常に簡略化されたサンプル：
プロジェクトの各部分にはスタック全体の開発が必要であるため、通常、フルスタック開発者のアプローチが期待されます。これは、チームB内での作業を分解し、異なる部分間の相互作用を設計および解決する方法です。
しかし最近私は、チームAがスタックの特定の部分を担当することを望んでいることを知りました。彼らは2つのチーム間の分割を提案しています。チームBからの開発はありませんでした。この格差は次のようなものです。
私にはこれは非常に不自然に感じられます。各チームには、これらを達成するための異なる目的とタイムスケールがありますが、チームBはチームAに依存して機能を実装します。提案されている解決策は、共通のインターフェースを事前に定義することです（プロジェクトには2年のタイムスケールがあり、多数になる可能性があります）。チームAは、独自の目標セットがあるにもかかわらず、早い段階でこれらのインターフェイスに必要なビットを開発します。一方、チームBは、短期間にすべての呼び出しをスタブ化して、進行できるようにします。
私はこのアプローチについて次のことを懸念しています：
- インターフェイスが変更される可能性があり、チームAには、変化する要件に対応するための帯域幅または時間がない可能性があります。
- チームAのコードにバグがあると、チームBの進行が妨げられる可能性があります。また、チームAの優先順位付けキューが異なるため、これらのバグを修正する優先順位ではない可能性があります。
- チーム全体に広がる知識の欠如-チームBは、内部で何が行われているのかを完全に理解していない可能性があり、そのために設計上の決定が不十分になる可能性があります。
業界の多くの企業にはサブチームがあり、これを処理できなければならないことが示唆されています。私の理解から、通常、チームは最初に期待した方法で分割するか（フルスタック）、または以下のようにテクノロジスタックを分割することによって分割されます。
だから私は他の業界が何をしているかを知ることに興味があります。ほとんどの分割は垂直/水平ですか？斜め分割は意味がありますか？斜めの分割が発生した場合、私の懸念は妥当であると思われ、チームBが懸念すべき他に何かありますか？おそらく、私はチームBの成功または失敗の責任を負うことになります。
あなたの懸念は非常に有効です。特に、チームAに関する最初の2つのポイントには、チームBに影響を与える機能を追加したり、バグを修正したりする時間がありません。これは、自分の仕事で何度も発生するのを見てきました。
これは、次の場合に適しています。
チームAはデータベースの新機能を必要とするプロジェクトに取り組んでおり、チームBの目標は基本的に「フロントエンドのみ」の機能を実行することです。たとえば、チームBが会社の新しいiPhoneアプリを作成している場合、デスクトップバージョンのすべての機能を移植/再実装する必要があるため、しばらくの間は新しいデータベースフィールドを追加しない可能性があります。
「完全なスタック」は十分に複雑になっており、単一の開発者（または開発チーム）が全体を効果的に「所有」することはできません。 「独自」とは、機能を追加してバグを修正するだけでなく、システム全体を理解し、時間の経過とともに技術的な負債が増えるのを回避できるように配慮することを意味します。この場合、「対角線」の分割は、チームAが非常に単純な、または不可避的にDAL /データベース実装（おそらく一部の内部診断ツール）に密結合しているUI/Web APIを所有している場合に賢明な動きですが、チームBは複雑なユーザー向けのフロントエンドのすべて。
経営陣は、チームAがボトルネックになるリスクを理解しており、このリスクが実際の問題になったら、対角化をやめてもかまいません。
業界で多かれ少なかれ一般的なことについて話すことはできませんが、少なくとも私が働いている場所では、すべてのアプリケーション開発者が「フルスタック」であることが明らかに必要です。私たちが持っているのは、社内データベース、Webサービスフレームワーク、およびUIフレームワーク（私の会社は巨大だと言ったでしょうか？）を開発/保守する「インフラストラクチャー」チームです。会社全体として、開発者は一貫してパフォーマンスとUIをすべてのサービスに提供できます。
最近、当社はまったく新しいUIフレームワークを作成しているため、新しいフレームワークのバグや機能が不足しているため、新しいアプリの一部がかなりひどくブロックされていた時期がありました。フレームワークを所有するチームにプルリクエストを送信する許可が与えられたため、これは当てはまりません（かなりの「対角化解除」ではありませんが、アイデアがわかります）。