Affiancare lo stack di sviluppo - in diagonale?

Question

Affiancare lo stack di sviluppo - in diagonale?

#1 da (12 voti)

11

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

Ognipartedelprogettorichiedelosviluppodell'interostack,quindinormalmentemiaspettounapprocciocompletoperlostackstack,ovveroilmodoincuiabbiamosuddivisoilnostrolavoroall'internodelteamB,progettandoerisolvendoleinterazionitralediverseparti.

Di recente ho appreso, tuttavia, che il team A vuole essere responsabile di alcune parti dello stack e propone una divisione tra i due team, in cui il livello di astrazione dei dati (e il posizionamento del contenuto nel livello dati) è gestito da solo senza sviluppo dalla squadra B. La divisione sembrerebbe qualcosa di simile a questa:

Permequestomisembramoltonaturale.Ognisquadrahadiversiobiettivietempidiversiperraggiungerli,malasquadraBavràunadipendenzadallasquadraAperimplementarelefunzionalità.Lasoluzionepropostaècheleinterfaccecomunisonodefiniteinanticipo(probabilmentec'èunintervallotemporaledi2annisulprogettoinmodochepossanoesserenumerose).LasquadraAsvilupperàprestoibitnecessariperquesteinterfaccepuravendoilpropriosetdiobiettivi,mentrelasquadraBcancelleràtuttelechiamateperl'immediatobrevetermineinmodochepossanoprogredire.

Hodubbisuquestoapproccioriguardoa:

LeinterfaccepotrebberocambiareelasquadraApotrebbenonaverelalarghezzadibandaoiltempoperadattarsiaimutevolirequisiti.
IbugnelcodicedellasquadraApotrebberoimpedirealteamBdiprogredire,eancoraunavoltapotrebberononesserelaprioritàperrisolverequestiproblemiacausadelfattochelasquadraAhaunacodadiprioritàdiversa.
Mancanzadiconoscenzadiffusatraiteam-LasquadraBpotrebbenoncomprendereappienociòcheaccadesottoicofaniepotrebbeprenderedecisionidiprogettazionesbagliateacausadiciò.

Èstatosuggeritochemolteaziendedelsettoredispongonodisottogruppiedevonoessereingradodigestirlo.Daquantohocapito,ingeneralelesquadresonosuddivisecomeinizialmentemiaspettavo(FullStack)orompendolostacktecnologicocomediseguito:

Quindi sono interessato a sapere cosa sta facendo il resto dell'industria. La maggior parte delle fessure è verticale / orizzontale? Una divisione diagonale ha senso? 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 della squadra B.

development-process programming-practices architecture team

posta Ian 11.04.2015 - 14:31

fonte

1 risposta

Leggi altre domande sui tag development-process programming-practices architecture team

Quanto l'uso di macro "probabili" e "improbabili" è eccessivo? Come distribuire una funzione solo a pochi utenti selezionati

score 12 · Accepted Answer

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 hanno impatto sul Team B. Ho visto questo accadere nel mio lavoro diverse volte.

Questa potrebbe essere una buona idea se:

È noto che la squadra A lavorerà sui progetti che richiedono nuove funzionalità nel database, mentre l'obiettivo del team B è essenzialmente quello di fare funzioni "solo frontend". Ad esempio, se la squadra B sta scrivendo la nuova app per iPhone della tua azienda, è probabile che non aggiungeranno nuovi campi di database per un po ', poiché devono portare / reimplementare tutte le funzionalità della versione desktop.
Lo "stack completo" è diventato sufficientemente complesso che nessun singolo dev (o team di sviluppo) può effettivamente "possedere" l'intera cosa. Con "proprio" intendo non solo aggiungere funzionalità e correggere bug, ma capire e curare l'intero sistema al punto che possono evitare di aggiungere più debito tecnico ad esso nel tempo. In questo caso, la divisione "diagonale" è la mossa ragionevole se la squadra A possiede un'interfaccia utente / Web API che è estremamente semplice o inevitabilmente strettamente accoppiato all'implementazione DAL / database (forse alcuni strumenti diagnostici interni?), Mentre la squadra B fa tutte le complicate cose frontend per gli utenti.
La direzione 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 trasforma in un vero problema.

Non posso parlare di ciò che è più o meno comune nel settore, ma almeno dove lavoro, c'è una chiara necessità per tutti gli sviluppatori di applicazioni di essere "stack completo". Quello che facciamo sono i team "infrastrutturali" che sviluppano / mantengono il nostro database interno, il nostro framework dei servizi web e il nostro framework UI (ho menzionato la mia azienda è enorme?), In modo che tutte le nostre centinaia di applicazioni possano avere lo stack completo sviluppatori mentre l'azienda nel suo complesso può ancora fornire prestazioni e interfaccia utente coerenti a tutti i nostri servizi.

Recentemente la nostra azienda ha creato un nuovissimo framework dell'interfaccia utente, quindi c'è stato un periodo in cui alcune delle nostre nuove app sono state bloccate in modo grave su bug e funzionalità mancanti nel nuovo framework. Questo non è più il caso, soprattutto perché a qualcuno di noi è stato dato il permesso di inviare richieste di pull al team che possiede il framework (non proprio "de-diagonalization", ma l'idea è stata presa).