Grandi squadre con applicazione a strati

Question

Grandi squadre con applicazione a strati

#1 da (4 voti)
#2 da (3 voti)
#3 da (2 voti)
#4 da (1 voti)

5

Lavoro in una squadra abbastanza grande (circa 15 sviluppatori) che sta attualmente discutendo la nostra metodologia di lavoro. Il software su cui lavoriamo è abbastanza ricco di funzionalità e si sta espandendo rapidamente in termini di ambito, quindi il numero di sviluppatori è aumentato ultimamente e continuerà ad aumentare. Al momento i diversi sviluppatori hanno diverse aree di interesse in cui sono bravi. Alcuni si concentrano sull'interfaccia utente, alcuni sulla logica aziendale e altri sul back-end. Ma uno sviluppatore dell'interfaccia utente potrebbe aggiungere qualcosa al back-end se ha voglia di farlo.

Man mano che il numero di sviluppatori cresce, non possiamo più lavorare nello stesso team (è piuttosto difficile cercare di seguire ciò che fanno altre 20 persone). Molte squadre che lavorano nella stessa base di codice potrebbero diventare disordinate se le persone stanno cambiando il "codice di altri popoli".

Stiamo discutendo alcuni modi alternativi per dividere i nostri compiti, e diverse persone argomentano in modi diversi:

Alcuni pensano che il modo attuale di fare le cose sia abbastanza buono. Certo, un ragazzo che si concentra sull'interfaccia utente potrebbe apportare modifiche alla logica di business del backend e potenzialmente incasinare le cose. Ma allo stesso tempo ci fidiamo di lui per non incasinare troppo. Le revisioni delle modifiche potrebbero essere sufficienti per garantire che la qualità rimanga valida.
Alcuni preferiscono che una squadra venga assegnata a un livello specifico. Ad esempio, un team (2-3 sviluppatori) potrebbe essere assegnato a lavorare solo sull'implementazione della logica aziendale nel backend, mentre un altro team potrebbe essere assegnato a lavorare su frontend e un terzo potrebbe concentrarsi sulle cose di persistenza. Ciò incoraggerebbe le persone a essere esperti nel proprio livello. Il lato negativo è che se uno sviluppatore della UI ha bisogno di qualcosa nel back-end, c'è un sovraccarico con la pianificazione se la persona che fa il back-end si trova in un'altra squadra.
Un terzo modo suggerito è quello di avere team con membri che conoscono tutti i livelli. Quindi un team si concentrerà su un tipo specifico di funzionalità e quindi includerà i membri che conoscono l'interfaccia utente, la logica aziendale, il back-end, ecc. Ciò darebbe il vantaggio che una squadra non dovrà attendere l'arrivo di un'altra squadra per implementare una nuova caratteristica che interessa tutti i livelli. Il lato negativo della gente vede qui che questo potrebbe portare a una maggiore focalizzazione tra gli sviluppatori, che potrebbe portare a una minore qualità.

Non sono sicuro di quello che sto chiedendo qui, ma se qualcuno ha esperienza, o se ne conosce qualcosa su un buon materiale di lettura su questo argomento, sarebbe apprezzato.

agile team layers

posta Nitra 08.05.2013 - 19:22

fonte

4 risposte

Leggi altre domande sui tag agile team layers

Cos'è la sicurezza dei thread? [chiuso] Perché non esiste un'opzione di distribuzione privata per il framework .NET? [chiuso]

score 4 · Answer 1

Indipendentemente dalla struttura scelta, la qualità della comunicazione all'interno del team è probabilmente il fattore più critico per il tuo successo (presupponendo naturalmente che gli sviluppatori abbiano competenze sufficienti).

Attualmente sto lavorando in un team di progetto di 20 sviluppatori, per una grande applicazione a più livelli. Gestisco 9 e il mio collega ne gestisce 9, mentre gestiamo insieme il progetto. Abbiamo sviluppatori specializzati nelle stesse aree in cui discutete. Alcuni di loro hanno anche esperienza negli altri livelli e si sentono sicuri di fare dei cambiamenti lì. Abbiamo sottogruppi fluidi che assembliamo per ogni funzionalità in base alle necessità. Sottolineiamo la comunicazione come una parte costante del processo. Questo include incontri (minimi), WIKI e solo andare alla scrivania di qualcuno. I membri del team sono disposti ad aiutarsi a vicenda ea condividere le proprie conoscenze. Quando il cambiamento avviene nel codice, può avere un impatto su tutti i livelli direttamente o indirettamente ed è importante mantenere tale comunicazione.

Hai menzionato "il codice di altre persone" , e mentre alcuni su questo sito hanno sottolineato che la società possiede il codice, non lo sviluppatore, può essere ancora inquietante essere l'unico sviluppatore che tocca una parte del codice per un po 'quando improvvisamente qualcun altro apporta una modifica senza informarti e devi correggere il risultato. Se questi due sviluppatori parlano prima che si verifichino gli aggiornamenti, lo sviluppatore esperto con il codice può almeno fornire qualche background e i problemi possono essere evitati. Una buona comunicazione può ancora salvare il giorno.

score 3 · Answer 2

La mia preferenza sarebbe che ogni piccolo team si specializzasse in un livello, con quel livello come principale area di responsabilità, ma che fosse addestrato trasversalmente negli altri livelli ed essere in grado di lavorare in quegli altri livelli qualora si presentasse la necessità .

Si spera che i livelli e le interfacce architettoniche siano ben definiti tra questi livelli, in modo che, indipendentemente dall'assegnazione degli sviluppatori, possano lavorare in un determinato livello senza influire negativamente sul resto dell'applicazione.

score 2 · Answer 3

Terza opzione per me.

La comunicazione è fondamentale e ridurre al minimo l'affidamento su un altro team di livelli per completare correttamente il bit o implementare correttamente l'interfaccia concordata può notevolmente inibirlo.

Preferisco anche che il mio team sia generalista e possa spostarsi facilmente in aree diverse quando necessario. Hai una nuova funzionalità? Una "persona" può lavorare su tutta la faccenda invece di aspettare che 3 diversi livelli di persone diventino disponibili.

Ho sempre un esperto di DB che tiene d'occhio le cose, e 1 esperto di UI che controlla quel lato delle cose, ma avere persone flessibili e di talento, lavorando su silos di funzionalità piuttosto che su livelli orizzontali, per me funziona sempre meglio.

score 1 · Answer 4

Agile generalmente preferisce il terzo approccio. Sono sicuro che la maggior parte delle risorse sull'agile raccomandano questo. Il motivo principale per non preferire l'approccio a più livelli è che sarebbe difficile per ogni squadra fornire software di lavoro ogni iterazione, perché il lavoro di una squadra dipende dal lavoro di un'altra. Potresti provare ad affrontarlo in modo che i team a livello "inferiore" funzionino prima di quelli a livello "più alto", ma sarebbe difficile comunicare i cambiamenti. Soprattutto se l'unica cosa che il cliente vede è l'interfaccia utente. Quello che vuoi cercare è denominato team di caratteristiche, contro i team di livello.

Per garantire che l'esperienza sia condivisa correttamente tra diversi team e livelli, si consiglia inoltre di ruotare spesso le persone tra i vari team. Ciò garantirà coerenza e qualità nell'intera applicazione.

Inoltre, la nota sul "codice di altre persone", consiglierei di consultare CodeOwnership di Martin Fowler.