Completare anticipatamente un'iterazione

Questo di solito è causato dal "fallimento", che non sta offrendo tutto quanto pianificato per lo sprint, visto come una cosa negativa dal management. Ricorda che è necessario un errore occasionale per sapere esattamente quanto il team può fornire. Potrebbe anche essere necessario ricordare al team che le loro prestazioni sono parzialmente giudicate sulla quantità di codice che possono fornire, non solo se forniscono le funzionalità promesse in ogni sprint.

Se non è così, perché la squadra sta finendo di lavorare presto? Ad esempio:

• Stanno sopravvalutando, un problema comune con Scrum? Se è così, usa gli sprint "finiti in anticipo" come prova per spingere un po 'di più la squadra.
• ricevono assistenza dall'esterno del team? In tal caso, aggiungili come lavoratori.
• Era il tempo assegnato a possibili interruzioni, come il supporto di un prodotto esistente? In tal caso, riduci la stima per il prossimo sprint.

Assicurati inoltre che le attività di supporto vengano eseguite in aggiunta al lavoro di sviluppo, inclusi i test automatici, assicurando che l'installazione / distribuzione del prodotto sia aggiornata, che la documentazione sia completa e così via. Prendi in considerazione di aumentare i criteri di completamento per questi. In alternativa, fare in modo che l'aiuto aiuti il controllo qualità creando i dati di test, automatizzando i casi di test e così via.

Ricorda che il team sprint è giudicato dall'efficacia del team di sprint, non dal fatto che gli sviluppatori finiscano i loro compiti in anticipo o meno.

Sei sicuro di voler impedire che raggiungano il futuro? Se impedisci agli sviluppatori di guardare (iterazione + 1), nella successiva iterazione impiegheranno molto più tempo per realizzare i loro compiti di sviluppo. Ciò significa che il tuo QA avrà molto meno tempo per testare le cose.

Nel nostro team, un tema ricorrente è in realtà l'opposto, gli sviluppatori tendono a commettere un eccesso di commit in modo che non svolgano le proprie attività o che vengano eseguiti correttamente verso la fine. Ciò ha l'effetto del QA di non avere abbastanza lavoro nei primi 2/3 dell'iterazione e troppo lavoro alla fine.

Una delle idee che abbiamo gettato è di provare effettivamente a fare ciò che il tuo team sta già facendo. Fai in modo che gli sviluppatori prendano meno lavoro e finiscano presto in modo che possano iniziare a guardare (iterazione + 1). In questo modo alcune storie verranno fatte prima, così che a) il QA non sarà annoiato all'inizio e sopraffatto alla fine. Inoltre, nella pianificazione avremmo stime delle attività migliori dal momento che le persone hanno già avuto la possibilità di rivedere il lavoro da svolgere.

Essere uno sviluppatore ed essere un tester richiede personalità molto diverse e set di abilità molto diversi. Riesco a vedere come la maggior parte dei tuoi sviluppatori sarebbe esitante nel saltare regolarmente al QA. Non solo non apprezzerebbero semplicemente il loro lavoro, ma non otterranno la stessa qualità di uno sviluppatore "costretto" a testare, piuttosto che assumere un altro addetto al controllo qualità che si diverte a fare quello che fanno.

Solo la mia opinione (e io sono uno sviluppatore)

Perché lo sforzo di test e l'accettazione commerciale richiedono così tanto tempo?

Mi sembra che tu stia pianificando progetti mini-cascata all'interno delle tue iterazioni (sviluppo, test e accettazione). Il test e l'accettazione devono essere eseguiti direttamente dopo che ogni articolo è stato completato, e preferibilmente dalle persone che lo hanno sviluppato più il proprietario del prodotto. Non dovrebbe richiedere più di uno, forse due ore (se si semplifica questo potrebbe essere fatto in pochi minuti).

Per ora ci sono alcune soluzioni. Puoi fare in modo che il team di sviluppo cerchi nuove tecnologie un giorno alla settimana per tenerle occupate. In questo giorno potrebbe essere una buona idea per loro esaminare i loro processi di test, dal momento che sembrano avere un problema con i test (a loro non piace). Forse possono dedicare il loro tempo extra allo sviluppo di un ambiente di test automatizzato che vada al di là di alcuni semplici test di unità (il test dell'unità è solo una delle numerose tecniche di test).

Se continui a spingere per più storie durante lo sprint sarà difficile evitare questo comportamento. Invece lascia che le persone trascorrano il resto dello sprint con qualunque cosa stiano facendo, tranne le nuove storie. Immagino che ci sia una miriade di cose che possono essere fatte: dall'automazione delle build, dall'apprendimento a quel nuovo strumento interessante della scorsa settimana, ai test o al barbecue che avresti potuto avere per settimane. Un nuovo sprint può essere pianificato di conseguenza per fare più storie in una nuova iterazione (se questo è l'obiettivo).

Se puoi accelerare test e accettazione, allora fallo. Se non puoi, questo è un fattore limitante.

Cosa sta succedendo durante i test e perché ci vuole così tanto tempo?

Potrebbe essere un problema di risorse (5 sviluppatori, un tester - non funzionerà)

O forse il test è troppo accurato E non trova alcun problema in alcun modo - nel qual caso basta testare di meno e automatizzare di più?

O forse la qualità è scarsa e ci vuole un sacco di tempo per testare perché c'è bisogno di molte riparazioni / riparazioni? In tal caso, gli sviluppatori devono rallentare e sviluppare una migliore qualità (e alla fine considerare di far funzionare il QA durante lo sviluppo).

Qualcuno intelligente (sono troppo pigro per cercarlo) ha detto che il compito di uno sviluppatore è di mettere fuori gioco il QA.

Ho visto sviluppatori che finiscono presto perché non sono completi. Nel mio libro, gli sviluppatori non hanno meno responsabilità dei test rispetto ai tester, quindi se i tester stanno trovando molte cose che devono essere segnalate, aggiunge sia il tempo amministrativo che i tempi di ri-test.

Gli sviluppatori possono creare collezioni di test unitari davvero impressionanti da eseguire e tuttavia il codice può avere errori spettacolari. Forse la causa è che stanno considerando la funzionalità richiesta in modo troppo ristretto. Forse potrebbe tornare ai casi d'uso che potrebbero dover richiamare più flussi alternativi. O forse è un segno di scarsa qualità del codice abbinato a test di unità troppo pochi o troppo ingenui.

In alcuni ambienti di sviluppo, ci possono essere molte funzionalità che vengono testate con simulatori o date un passaggio perché sono troppo difficili per gli sviluppatori per testare con quello che hanno a disposizione alla loro scrivania. Nell'interesse della correttezza, lo scopo del test degli sviluppatori rispetto al test di accettazione è un fattore determinante per quanto i tester devono lavorare.

Un'altra considerazione è il rapporto tra sviluppatori e tester e la complessità della configurazione del test rispetto agli strumenti disponibili per automatizzare il test. Se lo sviluppo esegue test unitari in dieci minuti, ma le interazioni dell'utente complesse oi test con hardware e dispositivi esterni non fanno parte dei test, forse è normale che i tester siano long pole. I tester possono fare molto di più per documentare il proprio lavoro rispetto agli sviluppatori e se questo è vero potrebbe esserci qualche tipo di valutazione sul fatto che una parte stia prendendo scorciatoie o l'altra stia facendo un lavoro non necessario.

Gli sviluppatori non dovrebbero influenzare i tester in modo tale da comprometterne l'obiettività. Tuttavia, penso che sia molto ragionevole per gli sviluppatori condividere la documentazione sui test delle loro unità e il codice che è stato modificato con i tester. In alcuni gruppi, gli sviluppatori fanno un sacco di lavoro, quindi distribuiscono i build ai tester quando la pianificazione è quasi esaurita. In altri gruppi, i tester ottengono build giornalieri, quindi i test possono procedere con nuovi bit non appena diventano disponibili. In alcuni gruppi, i tester possono persino generare le proprie build che sono cronometrate al loro miglior vantaggio.

Alcuni team stanno aggiungendo persone con il titolo Software Development Engineer in Test in modo che possano avere personale altamente qualificato per eseguire test di copertura del codice / decisione. Questo può essere in contrasto con alcune linee guida Agile, ma lo stesso fanno le pratiche di test degli sviluppatori che diciamo che dovremmo fare, ma non farlo.