Quando una squadra taglia più di 10, puoi ancora programmare insieme il rilascio?

La definizione delle priorità dovrebbe essere effettuata da un singolo proprietario del prodotto con l'input dei vari stakeholder, tra cui uno sviluppatore senior che è uno stakeholder per il codice e come responsabile per i requisiti non funzionali in quanto uno stakeholder aziendale è per i requisiti funzionali.

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

Se questo non è assolutamente possibile, per qualche ragione - e hai bisogno di applicare 5 perché per quella ragione prima di accettare che è impossibile - allora una squadra di 4-5 persone dovrebbe essere selezionata dal team per fare stime per loro conto.

A mio parere, NON dovresti pianificare il rilascio come una squadra di 10 persone. Molto probabilmente finirai con un incontro gigantesco in cui, in ogni discussione, 6-8 persone si sentiranno completamente disconnesse e annoiate. Aggiunga a quello l'esaurimento di 3-4 ore che sono bloccate in una stanza insieme. E considera che se parlano 10 persone, hai troppa conversazione. 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 del rilascio richiedeva 2 settimane solide. Ed è stato assolutamente brutale. Poche ore ogni giorno, penso che tutti noi iniziamo a cercare di parlare il meno possibile, in modo che la riunione finisca prima.

Questa versione della nostra squadra è più che raddoppiata. Quindi ci siamo suddivisi 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 un piano di rilascio di alto livello con solo i lead, che sono andati in modo più veloce ed efficiente perché ora avevamo solo 4 sviluppatori in una stanza. Durante questo periodo, abbiamo identificato quale team avrebbe fatto quali storie e come il prodotto verrà diviso. Anche questo ha portato a una visione più ampia dell'intero prodotto.

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

Infine, tutto è stato messo insieme e abbiamo fatto un ultimo walkthrough (più di una presentazione che di una discussione) in modo che tutti nel team sappiano cosa sta succedendo con tutto il team.

Sebbene non avessimo una versione completa di successo con questo metodo, penso che la pianificazione delle release sia andata avanti in modo più semplice di prima e ne abbiamo ricavato molto di più. La chiave è che non abbiamo mai avuto più di 3-4 sviluppatori in una data riunione e la voce di tutti è stata ancora ascoltata.

Se possibile ti consiglierei di dividere i tuoi 10 sviluppatori in 3 gruppi. Se non puoi dividere la tua versione complessiva in 3 aree per lo più non sovrapposte, allora 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 hanno più di 10 anni. In quasi tutti i progetti su cui lavoro, la pianificazione delle release viene eseguita dai lead e dagli analisti aziendali. Tuttavia, nella nostra situazione i BA non sono i manager, quindi i gestori non partecipano realmente alla pianificazione del rilascio.

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

La stima è quanto tempo richiede un'attività per essere eseguito, mentre la pianificazione della versione è quando le attività su cui è programmata la lavorazione.

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

Questa attività è svolta in modo più efficiente da un manager. Nelle piccole squadre, i ruoli tendono a confondersi. Tutti sono coinvolti in tutto. Ma man mano che il tuo team cresce, diventa ingestibile e i ruoli devono essere chiaramente definiti.

Per quanto io abbia il desiderio di essere coinvolto in tutto, non è produttivo.