dev e qa nello stesso sprint

How can both be completed by the end of the sprint and neither is remaining but still not have a dev sit idle near the end of the sprint while they wait for QA effort or QA starts some QA work after the end of sprint because dev just finished their work.

Non c'è davvero alcun motivo per cui qualcuno non possa essere inattivo alla fine dello sprint, dal momento che scrum ottimizza il team piuttosto che l'individuo.

Detto questo, trovo difficile immaginare uno scenario in cui ciò sarebbe possibile a meno che non sia l'ultimo sprint di un progetto. Una volta terminato il lavoro di sviluppo, gli sviluppatori devono semplicemente continuare a lavorare con i tester per testare il prodotto. Lo sviluppo del software sotto scrum è uno sport di squadra. Se hai uno sviluppatore che non è disposto a testare il proprio software o quello dei propri compagni di squadra, questi non appartengono a un team di mischia.

Le cose che gli sviluppatori possono fare dopo che pensano che il loro lavoro di sviluppo sia fatto:

• aiuta a scrivere test automatici. Ad esempio, se si utilizza uno strumento di test basato su parole chiave, possono scrivere le parole chiave di livello inferiore,
• aiuta i tester a generare dati di test,
• risolve i problemi con la verificabilità del codice. Ad esempio, se si crea un'app Web, aggiungere gli attributi ID mancanti non appena il tester lo menziona,
• lavora con il proprietario del prodotto sul grooming del backlog,
• ottimizzazione di piccole sezioni di codice,
• aiuta altri sviluppatori a tagliare il traguardo con il loro codice
• aiuta a scrivere la documentazione necessaria

Allo stesso modo, non riesco a immaginare nessuno scenario in cui il controllo qualità non abbia nulla da fare prima che la codifica sia finita. Ecco alcune delle cose che i tester potrebbero fare durante i primi giorni dello sprint:

• collaborare con il proprietario del prodotto per comprendere appieno la valutazione dell'accettazione e collaborare con lo sviluppatore su come intendono farlo,
• generazione di scenari di test di alto livello,
• raccolta dei dati di test,
• presentare suggerimenti allo sviluppatore su come rendere il codice più facile da testare (semplice esempio basato su un'applicazione web: assicurati che aggiungano id univoci per ogni elemento web con cui devi interagire),
• collabora con il proprietario del prodotto e lo sviluppatore per aiutare a perfezionare gli scenari di test di alto livello,
• inizia a lavorare sui test automatici. Con i giusti framework di test è abbastanza facile scrivere test automatici prima che il software sia pronto, se tu e gli sviluppatori avete collaborato da sempre su quali elementi sono presenti sulla pagina web o nell'app, come vengono identificati, ecc.
• rivedere il codice che viene scritto in modo da essere pronto a testarlo una volta pronto per essere testato,
• lavorando con il proprietario del prodotto per il grooming del backlog e scrivendo i criteri di accettazione per il seguente sprint.

...But that still does not cover for at the least a little time when dev has completed developing vs QA has completed testing the deliverable...

La chiave per uno sprint è che il team sta collaborando sempre . Quindi all'inizio dello sprint, i tester lavorano insieme agli sviluppatori per capire cosa stanno facendo con i primi lavori, in modo da sapere come testare. Questi lavori dovrebbero durare ore, non giorni, in modo che i test inizino quasi subito.

Mentre testano, i tester stanno fornendo feedback e gli sviluppatori stanno quindi risolvendo i problemi rilevati. Quindi gli sviluppatori non hanno finito fino al termine del test. Non c'è " almeno un po 'di tempo in cui dev ha completato " fino al termine del test, a meno che il test non stia riscontrando problemi, nel qual caso il test non ha alcuno scopo.

Il problema dei tester che non hanno nulla da fare all'inizio di uno sprint e gli sviluppatori che non hanno nulla da fare alla fine si verifica solo se ogni attività nello sprint viene trattata come una mini-cascata. Quindi non farlo. Invece, considera ogni attività come uno sforzo collaborativo tra uno sviluppatore e un tester.

Questo è spesso un po 'un cambiamento di mentalità per molte persone. La risposta più semplice è che il team è responsabile dello sviluppo e del test di qualcosa nello stesso sprint, se è troppo lavoro, allora devono impegnarsi a meno funzionalità.

Immagina il lavoro come una griglia, ogni riga rappresenta una funzionalità che il team vuole implementare, ogni colonna rappresenta le varie fasi tradizionali. Dev, Test, Risolto, Fatto ecc ...

In un'applicazione tipicamente a cascata, il team eseguirà lo sviluppo per tutte le funzionalità, quindi passerà a Test, Risolto ... poiché sono sicuro che questo approccio spesso porta a grandi quantità di rilavorazioni e scarsa comunicazione.

Un team di mischia dovrebbe contenere tutti i set di abilità per portare un pezzo di un lavoro dal piano a Fatto (Fatto, dovrebbe - a meno che tu non possa sostenere una ragione VERAMENTE valida dovrebbe essere fatta e in Produzione con clienti dal vivo).

Quindi, anziché completare un'intera colonna, una squadra punta a completare un piccolo numero di righe alla volta. Finendo alcuni di questi ogni sprint e spingendoli in live prima di iniziare il prossimo set. Ci sono molte, molte ragioni per le quali questa è una buona idea che lascerò fuori dallo scopo di questa risposta.

Quindi, ora sappiamo che vogliamo portare il tuo piccolo numero di funzionalità da Ready to Done alla domanda: come aiutare il tuo team a sviluppare e testare nello stesso sprint (voglio anche includere l'implementazione in questo).

In primo luogo, rendi visibile il lavoro. Se le persone possono vedere tutto il lavoro necessario per ottenere queste funzionalità in Produzione, avrai maggiori possibilità di completarlo.

Successivamente, è responsabilità dell'intero team completare le attività. Il test non è responsabilità di una persona, è l'intero lavoro del team - alcune persone potrebbero avere più esperienza di test ma possono aiutare altri membri del team, non sono le uniche persone che possono testare.

Cambiare mentalità / cultura è difficile, ma ecco i miei suggerimenti principali:

• Prendi un piccolo numero di piccole attività e consegnale per vivere ogni sprint
• Se gli sviluppatori non riescono a trovare nulla da fare, non consentono loro di svolgere più attività, devono aiutare il processo di test / distribuzione
• Coinvolgi presto i tester, utilizza le sessioni di perfezionamento / pianificazione per identificare i test da eseguire. Avere pianificato test come questo rende molto più facile per i non-tester essere coinvolti nei test. Incoraggia gli sviluppatori ad automatizzare i test!

TLDR

Incoraggia la squadra a consegnare alla produzione ogni sprint, questo si compenserà naturalmente per far sì che le persone prendano meno lavoro, ma lo spingono fino in fondo.

Pensa ai membri del tuo team come ingegneri con competenze diverse. Non c'è motivo per cui gli sviluppatori non possano provare e i tester non possono fornire consigli sullo sviluppo in corso. Pianificare i test da eseguire come parte della definizione di Ready rende molto più semplice per i tester progettare test per gli altri membri del team da eseguire.

Raccomando caldamente che la tua definizione di Done includa qualcosa in live e le storie non siano chiuse fino a quando non sono in produzione. Ciò rende il lavoro accumulabile in test / in attesa di distribuzione estremamente visibile e incoraggia i rilasci frequenti.

Lasciatemi suggerire un approccio diverso da quelli già menzionati. Quando il QA rimane una squadra o un dipartimento separati, puoi prendere in considerazione di lavorare in questo modo:

We are currently completing a sprint items by saying that they are "dev complete"

Va bene, quindi ogni volta che hai completato lo sprint, hai una nuova versione che puoi consegnare al QA. Diciamo che questa versione ha il numero di versione 5.0. QA inizierà quindi a testare 5.0 con un focus sulle nuove funzionalità della primavera precedente. Nel frattempo, i tuoi sviluppatori iniziano a sviluppare il prossimo sprint, diciamo che mirano a 6.0.

Ogniqualvolta il QA rileva un difetto grave, viene risolto nel ramo "5.x" e nel ramo dev corrente. Ciò può comportare una versione intermedia 5.1, 5.2, ecc., Al QA dopo aver corretto un insieme di difetti. Dovrai pianificare i tuoi sprint per avere un po 'di tempo riservato per tali correzioni di bug (ma avresti bisogno di un po' di tempo anche se la tua gente di QA non troverà i difetti, ma i tuoi sviluppatori nello sprint attuale). La correzione dei bug in due rami invece di uno dovrebbe in genere richiedere solo un po 'più di tempo rispetto a ripararli nel ramo dev, dal momento che una volta trovata la causa principale del difetto, nella maggior parte dei casi sarà sufficiente correggere il bug una volta nel dev branch, unisci la correzione anche al ramo 5.x (usando il tuo sistema di controllo della versione) e crea automaticamente una nuova versione nella riga 5.x.

Quando QA ha terminato i test per la linea 5.x, la versione finale può essere distribuita alla produzione. Nota che non tutti i difetti rilevati dal QA devono essere corretti immediatamente, è perfettamente possibile inserire alcuni problemi nel backlog se hanno un impatto ridotto.

Come vedi, questo modello non richiede agli sviluppatori di sedersi e attendere il completamento del QA. Se il QA completa i test della linea 5.x prima che la nuova versione 6.0 sia pronta, sono certo che saranno felici di investire il tempo rimanente nell'automazione dei test, di pensare a nuovi test per migliorare il piano di test o di lavorare sulla documentazione o utensili. Ti permetterà di lavorare in sprint, in modo agile, al prezzo di avere una versione "pronta per la produzione" con un ritardo di circa uno sprint.