Prima un po 'di background:
Precedentemente nel processo del ciclo V, abbiamo un team di sviluppo e un team di definizione / tester del prodotto (li chiameremo tester). Siamo passati all'agile pochi mesi fa con ancora questa separazione: persone con conoscenza e persone per la definizione / test del prodotto.
Il team di sviluppo ha già da tempo un'integrazione continua con test automatici di non regressione. Il team di tester ha solo capacità di test funzionali, nessuna possibilità di sviluppo.
Inoltre, gli sviluppatori e i tester si trovano in una posizione diversa (viene utilizzata la videoconferenza).
Se aiutiamo per le soluzioni, stiamo usando Jira per Scrum.
Situazione attuale:
Gli sviluppatori e i tester sono nella stessa squadra di mischia. Tutti sono dedicati al team per la durata di uno sprint. Le storie degli utenti hanno i criteri di accettazione impostati correttamente ... Fin qui tutto bene.
Tuttavia, il testing delle user story è gestito dai tester e non è qualcosa come un test che controlla i criteri di accettazione e consente o meno di integrare la storia dell'utente (aggiungiamo test da verificare ma non vengono utilizzati per la convalida della storia dell'utente). E ovviamente, i tester non possono codificare in quanto non hanno le conoscenze per farlo.
Questo ci porta a un problema che, quando si eseguono le misure, non è possibile effettuare un dimensionamento che abbia senso sia per gli sviluppatori che per i tester all'interno dello stesso sprint. Se sommiamo il dimensionamento, quando si pianifica lo sprint c'è un'alta probabilità che una parte abbia il 75% del carico di lavoro e l'altra quasi nulla da fare. E se dimensioniamo solo per uno dei lati, ci assicuriamo che una parte abbia la giusta quantità per lo sprint, ma l'altra parte potrebbe non farlo. Potremmo dimensionare per entrambi, ma la selezione potrebbe non coincidere con la priorità: vogliamo avere un carico di lavoro adeguato.
Finora abbiamo dimensionato il lavoro di sviluppo e ci siamo ritrovati con un enorme arretrato di storie utente non testate (che possono azzannarci se il test fallisce)
Da quello che ho letto qua e là, la soluzione è quella di separare gli sprint e gli sviluppatori da convalidare in base ai criteri di accettazione (test automatici) e quindi i tester potrebbero eseguire test aggiuntivi nel loro sprint. Tuttavia, la direzione vuole che teniamo tutto in uno sprint, una scheda ...
Quindi non essendo in grado di trovare una soluzione che consenta un buon dimensionamento con entrambi i team che lavorano nello stesso sprint, spero che alcuni di voi abbiano riscontrato lo stesso problema e trovato una soluzione o idee su un possibile miglioramento.
TLDR:
Come pianificare e gestire gli sprint con storie utente che richiedono un gruppo specifico da ded e un gruppo specifico per testare l'accettazione della storia utente senza tempo vuoto per un gruppo?