Quando la dimensione di una squadra supera i 10, è ancora possibile pianificare insieme la versione?

Quando decidete su cosa lavorare per la prossima versione e stimate i tempi per ogni storia utente (e attività secondarie per una determinata storia), voi ragazzi fate questo in un gruppo o solo manager?

Per una squadra di 10, è pratico?

Quanto tempo ci vuole?

La definizione delle priorità dovrebbe essere effettuata da un singolo product owner con il contributo dei vari stakeholder, incluso uno sviluppatore senior che è un stakeholder per il codice e responsabile dei requisiti non funzionali come un stakeholder aziendale per i requisiti funzionali.

La stima dovrebbe assolutamente essere fatta dalle persone che faranno il lavoro, mai da un manager che è sotto pressione per consegnare, tuttavia il tuo istinto è corretto che più di una mezza dozzina di persone passeranno ore a discutere su questo. In un mondo ideale, dovresti davvero scomporre la squadra in modo tale che non ci siano meno di 4 e non più di 7 in una singola squadra - 5 è l'ideale, IMHO.

Se questo non è assolutamente possibile, per qualche motivo - e devi applicare 5 perché a quel motivo prima di accettare l'impossibilità - allora un team di 4-5 persone dovrebbe essere selezionato dal team per fare stime per loro conto.

A mio avviso, NON dovresti fare la pianificazione del rilascio come un team di 10 persone. Molto probabilmente finirai con un incontro gigantesco in cui in ogni discussione 6-8 persone si sentiranno completamente disconnesse e annoiate. Aggiungete a ciò l'esaurimento di 3-4 ore rinchiuso in una stanza insieme. E considera che se 10 persone parlano, hai troppe conversazioni. Se non parlano, potresti non ricevere input preziosi.

Abbiamo fatto qualcosa di molto simile alla compagnia di Joseph. La versione precedente aveva 8 ingegneri e la pianificazione della versione richiedeva 2 settimane solide. Ed è stato assolutamente brutale. Poche ore al giorno, penso che tutti noi iniziamo a cercare di parlare il meno possibile in modo che l'incontro finisca prima.

In questa versione le dimensioni del nostro team sono più che raddoppiate. Quindi ci siamo divisi in team più piccoli che avrebbero assunto la proprietà permanente di un'area di un prodotto. Ognuna delle squadre più piccole aveva un vantaggio. Quindi abbiamo pianificato la versione di alto livello con solo i lead, che sono andati molto più velocemente ed efficientemente perché ora avevamo solo 4 sviluppatori in una stanza. Durante questo periodo, abbiamo identificato quale squadra farebbe quali storie e come il prodotto verrà diviso. Anche questo ha dato una visione d'insieme dell'intero prodotto.

Quindi ogni lead è tornato alla propria squadra e ha esaminato la parte del rilascio di cui solo quella squadra era responsabile. Durante questo periodo, abbiamo inserito alcuni dettagli e assegnato i valori dei punti della storia.

Infine, tutto è stato messo insieme e abbiamo fatto un'ultima procedura dettagliata (più di una presentazione che di una discussione) in modo che tutti i membri del team sappiano cosa sta succedendo con l'intero team.

Anche se non abbiamo avuto una versione di successo con questo metodo, penso che la pianificazione della versione sia andata complessivamente più agevolmente di prima e ne abbiamo ricavato molto di più. La chiave era che non abbiamo mai avuto più di 3-4 sviluppatori in una determinata riunione e la voce di tutti era ancora ascoltata.

Se possibile, ti consiglio di dividere i tuoi 10 sviluppatori in 3 gruppi. Se non riesci a dividere la tua versione complessiva in 3 aree per lo più non sovrapposte, anche 2 gruppi sarebbero meglio di una grande squadra.

In realtà faccio parte di più progetti (e più team) come lead, e ce ne sono alcuni che sono 10+. Su quasi tutti i progetti a cui lavoro, la pianificazione del rilascio viene effettuata dai lead e dagli analisti aziendali. Tuttavia, nella nostra situazione i BA non sono i manager, quindi i manager non partecipano realmente alla pianificazione del rilascio.

La stima viene effettuata dal team di implementazione, e sebbene entrambe le parti siano separate, sono molto correlate.

La stima è quanto tempo impiega un'attività per essere eseguita, mentre la pianificazione del rilascio è quando tali attività sono programmate per essere lavorate.

La pianificazione dovrebbe essere effettuata in base a preoccupazioni aziendali, mentre la stima dovrebbe essere effettuata in base a preoccupazioni tecniche. Da qui la rottura della stima e della pianificazione.

Questa attività viene eseguita in modo più efficiente da un manager. Nelle piccole squadre, i ruoli tendono a confondersi. Tutti sono coinvolti in tutto. Ma man mano che la tua squadra cresce, questo diventa ingestibile e i ruoli devono essere chiaramente definiti.

Per quanto provo il desiderio di essere coinvolto in tutto, non è solo produttivo.