Dev and Tester squadra separata AND singolo sprint

4

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?

    
posta user2892355 13.04.2016 - 19:28
fonte

2 risposte

1

Consente di ridurre il problema al caso più semplice.

Hai una storia, uno sviluppo, un tester e uno sprint per realizzare la storia testata.

Se la storia è completamente specchiata, lo sviluppatore dovrebbe essere in grado di completare il lavoro in mezzo sprint. Il tester non ha lavoro da fare in quanto lo sviluppatore testerà il codice contro le specifiche prima della consegna.

Se la storia è vagamente specchiata, il tester deve scrivere casi di test che, in sostanza, aggiungeranno compiti alla storia. Questo richiederà loro un mezzo sprint.

Ma dal momento che queste attività aggiunte sono sconosciute all'inizio dello sprint, lo sviluppatore non è in grado di impegnarsi a completare il lavoro di sviluppo per la storia e quindi non ha nulla a che fare con lo sprint.

Pertanto: è impossibile per i tester e gli sviluppatori lavorare sulla stessa storia nello stesso sprint se si impegnano a completare la storia. QED.

Se devi farlo, dovrai infrangere una regola. Fai in modo che i tester lavorino sulla v2 della storia, chiedi agli sviluppatori di impegnarsi in attività tecniche piuttosto che intere storie o far lavorare il tester sulle storie in anticipo rispetto agli sviluppatori.

    
risposta data 17.04.2016 - 08:49
fonte
0

Dovrebbe essere interpellato ciò che entra ed esce da ogni sprint e entrambe le parti concordano su tutti i problemi / attività / elementi (cliente e team di sviluppo). Quindi vengono definiti i limiti e lo scopo dello sviluppo ed è anche lo scopo dei test.

Con il team di sviluppatori pact di attività può iniziare a progettare e quindi a implementare. Nel frattempo i tester (che hanno certificato il rilascio dello sprint) dovrebbero essere pianificare e progettare tutti i casi utente coinvolti nello sprint. Utilizzare il caso di successo, il caso di successo di un utente alternativo e il caso di errore più importante. Tutti loro!!!. Quindi applicare questi scenari durante la fase di test. Infine avvia il processo di rilevamento dei problemi per ulteriori sprint.

Ci vuole tempo per fare un piano di test unitari, test di integrazione, test funzionali, test di regressione, ecc. Per scenari di successo, ma ci vuole anche più tempo per scoprire ogni possibile scenario di errore.

I tester dovrebbero essere come gli utenti finali. Per essere aggiornati sui requisiti e il business. In questa faccia, il QA troverà molti scenari imprevisti che nessuno ha visto durante l'analisi funzionale e quelli che accadono provocano cambiamenti imprevisti (e sappiamo tutti che succede ogni giorno). Alcuni cambiamenti hanno un impatto profondo e gli sviluppatori o gli analisti potrebbero perdere un po '.

Tuttavia gli sviluppatori dovrebbero rendere più semplice il lavoro di squadra del tester. Devs dovrebbe fare tutti i test unitari relativi alle loro implementazioni. Anche test di integrazione, se necessario.

È un lavoro cooperativo. Entrambe le squadre dovrebbero lavorare insieme. Osservando gli stessi obiettivi.

    
risposta data 13.04.2016 - 20:03
fonte

Leggi altre domande sui tag