Gestire più flussi di requisiti aziendali senza compromettere le dimensioni del team

Question

Gestire più flussi di requisiti aziendali senza compromettere le dimensioni del team

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

4

Un'azienda ha cinque flussi discreti di requisiti aziendali da implementare nel software. C'è un team di dieci sviluppatori.

Una soluzione organizzativa "naiiva" è quella di dividere il team in cinque "team" di due (uno per flusso di requisiti). Ma sento che questo compromette l'integrità della squadra (rendendo il lavoro di squadra più difficile, causando effetti sul silo, rendendo la comunicazione più difficile ecc.)

Qualcuno ha qualche idea su come organizzare al meglio un team di sviluppatori come questo per fornire rispetto a più flussi di requisiti? È possibile avere meno team di sviluppo rispetto ai flussi di requisiti?

teamwork requirements organization

posta Ben 21.08.2011 - 12:45

fonte

2 risposte

Leggi altre domande sui tag teamwork requirements organization

Modo preferito per gestire i dati definiti dal cliente nell'applicazione aziendale Espressioni regolari e generatori di linguaggio

score 3 · Answer 1

Suggerirei due squadre. 10 sono davvero troppi per una singola squadra (una diffusione troppo ampia della conoscenza rallenterà e un singolo caposquadra non dovrebbe concentrarsi su 5 flussi contemporaneamente), ma 5 su ciascuno dovrebbero lavorare comodamente e puoi flettere a 4: 6 se le pressioni sono pesanti su una squadra.

Hai assolutamente ragione che 5 team sono una visione ingenua. Se perdi anche solo una persona da un flusso, sei nei guai; perderli entrambi e avrai difficoltà a sopravvivere.

È abbastanza facile avere più flussi che attraversano una squadra. Vorrei raccomandare una combinazione di Scrum e Kanban, ma nel caso più semplice è sufficiente un backlog di lavoro prioritario e farlo in modo che chiunque nel team, finendo un lavoro, passi al successivo lavoro con priorità più alta, qualunque sia lo stream.

È ok (anzi, inevitabile) avere esperti di dominio tali che, se prendo un lavoro dal flusso 1 e non ne ho conoscenza, posso rivolgermi a loro per chiedere aiuto. Ma è importante che alla fine io faccia il lavoro e quindi impari almeno un po 'su tutti i flussi.

Le revisioni del codice aiutano anche a diffondere tale conoscenza, oltre a mantenere la base di codice ad un alto livello di qualità.

score 0 · Answer 2

IMHO, un modo per formare un team potrebbe essere:

Dividi gli sviluppatori in modo tale che ogni team di sviluppatori non ottenga più di due progetti simultanei (perché più di questo riduce drasticamente l'efficienza). Ad esempio, se hai 8 sviluppatori e 5 progetti a disposizione, crea 3 team, 2 team con 3 sviluppatori ciascuno con 2 progetti e un team con 2 sviluppatori con un progetto. Lo sviluppo non richiederà molto coordinamento tra i team se si hanno flussi diversi. Tuttavia, se gli stream sono molto simili tra loro, allora come dice @pdf, basta creare due team e dividere i progetti tra loro.
I progettisti e i tester non devono essere dedicati a un team specifico. È possibile creare una pipeline funzionante. Ad esempio, tester e progettisti potrebbero funzionare in modo trasversale, cioè, possono essere ordinati per progettare o testare, senza appartenere a nessun team specifico.