Affettare lo stack di sviluppo - in diagonale?

Abbiamo in corso un nuovo progetto e al momento gli sviluppatori sono stati divisi in due team, il team A e il team B. Questo progetto ha 2 parti che richiedono uno sviluppo in tutto lo stack di sviluppo. Esempio molto semplificato del nostro stack mostrato di seguito:

Ogni parte del progetto richiede uno sviluppo su tutto lo stack, quindi mi aspetterei in genere un approccio di sviluppo dello stack completo che è il modo in cui abbiamo suddiviso il nostro lavoro all'interno del team B, progettando e elaborando le interazioni tra le diverse parti.

Ho recentemente appreso tuttavia che il team A vuole essere responsabile di alcune parti dello stack e stanno proponendo una divisione tra i due team, in cui il livello di astrazione dei dati (e inserendo il contenuto nel livello di dati) è gestito da se stessi senza sviluppo dal Team B. Il divario sarebbe simile a questo:

Per me questo sembra molto naturale. Ciascun team ha obiettivi e tempistiche distinti per raggiungerli, ma il Team B dipenderà dal Team A per implementare le funzionalità. La soluzione proposta è che le interfacce comuni siano definite in anticipo (probabilmente sul progetto è prevista una scala temporale di 2 anni, quindi potrebbero essere numerose). Il team A svilupperà quindi in anticipo le parti richieste per queste interfacce nonostante abbia il proprio set di obiettivi, mentre il team B respinge tutte le chiamate per il breve termine immediato in modo che possano progredire.

Ho dubbi su questo approccio per quanto riguarda:

• Le interfacce possono cambiare e il Team A potrebbe non avere la larghezza di banda o il tempo necessari per soddisfare i requisiti in evoluzione.
• Gli errori nel codice del team A potrebbero impedire il progresso del team B e, di nuovo, potrebbero non essere la priorità per risolverli a causa del fatto che il team A ha una coda di priorità diversa.
• Mancanza di conoscenza diffusa tra i team: il team B potrebbe non comprendere appieno cosa succede sotto il cofano e, pertanto, potrebbe prendere decisioni di progettazione inadeguate.

È stato suggerito che molte aziende del settore dispongono di sottogruppi e devono essere in grado di gestirlo. Secondo la mia comprensione, generalmente i team sono divisi come inizialmente mi aspettavo (Full Stack) o rompendo lo stack tecnologico come di seguito:

Quindi sono interessato a sapere cosa sta facendo il resto dell'industria. La maggior parte delle divisioni è verticale / orizzontale? Ha senso una divisione diagonale? Se dovesse verificarsi una divisione diagonale, le mie preoccupazioni sembrano valide e c'è qualcos'altro di cui la squadra B dovrebbe preoccuparsi? Da notare che probabilmente sarò ritenuto responsabile per il successo o il fallimento del Team B.

Le tue preoccupazioni sono estremamente valide. Soprattutto i primi due punti sul Team A che non hanno il tempo di aggiungere funzionalità o correggere bug che incidono sul Team B. Ho visto che ciò accadeva nel mio lavoro parecchie volte.

Questa potrebbe essere una buona idea se:

• È noto che il Team A lavorerà sui progetti che richiedono nuove funzionalità nel database, mentre l'obiettivo del Team B è essenzialmente quello di fare funzionalità "solo frontend". Ad esempio, se il Team B sta scrivendo la nuova app per iPhone della tua azienda, è probabile che non aggiungeranno nuovi campi di database per un po ', poiché devono eseguire il port / reimplementare tutte le funzionalità della versione desktop.

• Lo "stack completo" è diventato sufficientemente complesso che nessun singolo sviluppatore (o team di sviluppo) può effettivamente "possedere" l'intera cosa. Per "proprio" intendo non solo aggiungere funzionalità e correggere bug, ma comprendere e preoccupare l'intero sistema al punto da poter evitare di aggiungere più debito tecnico nel tempo. In questo caso, la divisione "diagonale" è la mossa sensata se il Team A possiede un'API UI / Web che è estremamente semplice o inevitabilmente strettamente accoppiata all'implementazione DAL / database (forse alcuni strumenti diagnostici interni?), Mentre il Team B lo fa tutte le complicate cose frontend rivolte all'utente.

• Il management comprende il rischio che la squadra A diventi un collo di bottiglia e sarebbe disposta a de-diagonalizzare le cose se o quando questo rischio si trasformasse in un problema reale.

Non posso parlare di ciò che è più o meno comune nel settore, ma almeno dove lavoro, è evidente che tutti gli sviluppatori di applicazioni devono essere "full stack". Ciò che abbiamo sono team "infrastrutturali" che sviluppano / mantengono il nostro database interno, il nostro framework di servizi Web e il nostro framework di interfaccia utente (ho già detto che la mia azienda è enorme?), In modo che tutte le nostre centinaia di applicazioni possano avere lo stack completo sviluppatori mentre la società nel suo complesso può ancora fornire prestazioni e interfaccia utente coerenti a tutti i nostri servizi.

Di recente la nostra azienda ha creato un nuovo framework per l'interfaccia utente, quindi c'è stato un periodo in cui alcune delle nostre nuove app sono state gravemente bloccate su bug e funzionalità mancanti nel nuovo framework. Questo non è più il caso, soprattutto perché ad alcuni di noi è stata concessa l'autorizzazione a inviare richieste pull al team proprietario del framework (non proprio "de-diagonalizzazione", ma si ottiene l'idea).