Quali sono i vantaggi e gli svantaggi della suddivisione dei team per livello di architettura piuttosto che per prodotto?

L'organizzazione a più livelli corre il rischio che le decisioni vengano prese in base a chi le implementerà piuttosto su dove dovrebbero essere implementate. Ad esempio, progettare una funzionalità in modo che la maggior parte del lavoro venga eseguita nel livello X, anche se naturalmente appartiene al tier Y, poiché il team di livello Y ha molto più carico di lavoro rispetto al team X di livello. Queste decisioni potrebbero essere corrette dal punto di vista del business, ma sono ancora soggette a debiti tecnici e l'organizzazione legata al progetto di solito può dipendere più puramente da ragioni tecniche e architettoniche quando prende queste decisioni.

D'altra parte, l'organizzazione a più livelli ha un vantaggio poiché contrariamente all'intuizione - i confini tra i progetti dovrebbero essere meno severi dei confini tra i livelli. L'interazione tra i livelli dovrebbe essere rigorosa e dipendere da un protocollo chiaramente definito, e avere team separati implementare i lati di queste interazioni obbliga i team a mantenere i protocolli rigorosi e ben definiti.

I confini tra i progetti dovrebbero essere meno rigorosi dal momento che condividono il codice e condividere il codice è meno pericoloso della condivisione dei dati. Se un codice era utile nel livello X del progetto A, è più probabile che sia utile nel livello X del progetto B rispetto al livello Y del progetto A. Voglio dire - quante funzioni JavaScript dal tuo framework di una pagina saranno utili nel database? Uno sviluppatore di livello X che lavora al progetto B potrebbe avere familiarità con quel codice da quando lo ha visto nel progetto A. Un progetto Uno sviluppatore che lavora sul tier Y del progetto potrebbe avere familiarità con quel codice poiché lo ha visto nel tier X - ma non sarebbero in grado di riutilizzarlo comunque a livello Y.

I dati, d'altra parte, devono essere condivisi tra i livelli degli stessi progetti e, poiché la condivisione dei dati è pericolosa, sono necessari confini più rigidi. Ecco dove la separazione dei team può essere utile - se l'app desktop potrebbe utilizzare l'accesso ad alcuni dati dal server per una soluzione rapida e sporca, uno sviluppatore legato al progetto potrebbe essere tentato di dargli accesso (dal momento che questi programmatori controllano entrambi i livelli ), ma uno sviluppatore legato al livello dovrà richiedere l'accesso dal team del server, che sono più propensi a dire di no (dal momento che hanno meno bisogno di quel particolare trucco sporco, quindi sono meno inclini a corrompere l'interfaccia per supportarlo) e costringere lo sviluppatore del desktop a cercare una soluzione più adeguata.

La separazione dei progetti è meno importante in questo senso - c'è molto meno bisogno di condividere i dati tra i progetti, e quando c'è tale necessità è spesso fatto attraverso un altro livello (ad esempio due app per smartphone che parlano attraverso un server), e anche quando è fatto direttamente, è necessario dare molto poco per rovinare tutto con trucchi sporchi, dal momento che il confine tra i progetti è più chiaro di quello tra i livelli.

Vorrei andare con ciò che funziona per i membri del team che hai e / o sono in grado di assumere. Una sorta di lasciare che accada organicamente. Le organizzazioni più grandi possono probabilmente assumere abbastanza specialisti per gestire tutte le attività di cui hanno bisogno. Questo può dipendere anche da quanto "agile" vuoi davvero essere. Se tutti possono fare tutto, hai la massima flessibilità.

Una organizzazione può avere il lusso di permettere alle persone di specializzarsi perché i loro progetti sono molto simili. Hai tutta l'esperienza di cui hai bisogno e il carico di lavoro può essere bilanciato. D'altra parte, se questa organizzazione è stata costretta a lasciare che le persone si concentrino su un'area, perché non hanno la capacità di essere competenti in molte aree, saranno limitate nei tipi di progetti che possono fare o sono costrette ad assumere un aiuto esterno per riempire il vuoto o aiutare con il carico di lavoro.

Devi davvero tenere aggiornati la tua documentazione e la conoscenza del dominio se vuoi consentire agli sviluppatori di lavorare su più progetti.

Tendiamo a pensare ai programmatori che possono usare molte lingue e lavorare in tutti gli aspetti di un progetto per essere più calibro, ma potrebbe anche significare che sanno come costruire sei diversi modi.

Entrambi possono funzionare ed entrambi possono essere cattivi. Se mi trovassi ad avere una squadra a cui piace lavorare in tutte le fasi dello stack, ci dovrebbero essere aumenti significativi della produzione prima che li costringessi a specializzarsi.