Dilemma del QA rispetto alle iterazioni

Nella mia azienda, lavoriamo con successo con pratiche agili, ma senza usare iterazioni. Il motivo principale è che non riusciamo a trovare un modo pulito per adattarci al QA in un ciclo di iterazione.

Comprendiamo il QA come ulteriore bit di verifica per un determinato build (release candidate) prima che questo build venga distribuito al cliente. Il punto è evitare che un singolo commit dannoso danneggi l'intera versione. Dal momento che non si sa mai quale sia, il QA deve attendere fino a quando tutte le funzionalità / commit per il rilascio sono nella build. (Non sono permesse le ultime parole famose "È stato solo un piccolo cambiamento".)

Se il QA trova dei bug in un candidato di rilascio, gli sviluppatori risolvono questi bug nel rispettivo ramo di rilascio (e lo uniscono nel trunk). Quando tutti i bug sono stati corretti, viene distribuito un nuovo build per il QA da testare nuovamente. Solo quando non viene trovato alcun bug in un determinato candidato al rilascio, viene offerto al cliente per la verifica.

Questo di solito richiede circa due o tre candidati, circa una settimana, per rilascio. Il tempo per scrivere le correzioni è in genere molto più basso rispetto agli sforzi di test. Quindi, per tenere occupati gli sviluppatori, lavorano sulla versione N + 1 mentre il QA funziona su N.

Senza usare le iterazioni, questo non è un problema perché possiamo sovrapporre il lavoro per le versioni N e N + 1. Tuttavia, da quello che ho capito, questo non è compatibile con approcci basati su iterazioni come Scrum o XP. Richiedono che un'iterazione sia rilasciabile alla fine con tutti gli sforzi di test da incorporare nell'iterazione.

Trovo che ciò porti necessariamente a uno dei seguenti risultati indesiderati:

(A) Gli sviluppatori sono inattivi al termine di un'iterazione perché il QA ha bisogno di tempo per verificare un candidato al rilascio e il lavoro di correzione dei bug non tiene completamente occupati gli sviluppatori.

(B) Il QA inizia a funzionare già prima che la prima release candidate sia pronta. Questo è ciò che è principalmente raccomandato su Stack Exchange. Ma non è ciò che la mia azienda comprende come QA perché non esiste un candidato di rilascio specifico testato. E il "piccolo cambiamento" che rompe tutto può ancora essere introdotto inosservato.

(C) I bug vengono riportati alla successiva iterazione. Questo è consigliato anche su Stack Exchange. Non penso che sia una soluzione. Significa fondamentalmente che non otteniamo mai una build verificata perché ogni volta che vengono apportate correzioni di bug, vengono aggiunti allo stesso ramo anche nuovi commit non verificati.

Esiste una via d'uscita da questo dilemma?

Comprendiamo il QA come ulteriore bit di verifica per un determinato build (release candidate) prima che questo build venga distribuito al cliente.

Non c'è nulla di intrinsecamente incompatibile tra questa forma di QA e metodologie basate sull'iterazione come Scrum.
All'interno di Scrum, il team consegna un prodotto su un ciclo X-settimanale al proprio cliente. La parte importante qui è che, se il team di sviluppo sta eseguendo Scrum, il suo cliente è il team di controllo qualità, non l'utente finale del prodotto.

Come sviluppatore, prenderei in considerazione un prodotto che può essere spedito al QA se ha una possibilità combattiva di superare tutti i test. Questo probabilmente significa che alcuni dei test di qualità sono già stati eseguiti sui build giornalieri, ma come ciò influisce sui test di rilascio ufficiali da parte del team di controllo qualità dipende dalla tua organizzazione.

Per la maggior parte delle situazioni di vita reale, l'agile si ferma alla consegna a QA / UAT o come si chiama.

Lo sforzo di passare dal controllo qualità alla produzione in un ambiente di vita reale è spesso sottovalutato. In molti casi ciò coinvolge utenti aziendali reali nei test, nella gestione della firma dalla linea reale di manager aziendali, nella pianificazione del rilascio con operazioni ecc. Questo non è banale!

In casi estremi, il software potrebbe richiedere la certificazione di agenzie esterne o essere sottoposto a rigorosi test di sicurezza.

In queste circostanze è semplicemente impossibile prevedere più di una versione al trimestre, ad eccezione delle correzioni di bug.

Peggiora un prodotto software serio. La documentazione deve essere verificata e pubblicata. Le brochure di marketing devono essere modificate. I venditori devono essere informati su ciò che stanno vendendo (non è un compito facile!) Ecc. Ecc. Non si vuole davvero far passare il business più di una volta all'anno.

La soluzione a brevissimo termine è concedere al QA un ulteriore periodo di tempo dopo l'iterazione per finalizzare i test. vale a dire. Se hai un'iterazione di due settimane, non rilasciarla fino alla settimana 3. Il QA non avrà nulla da testare per l'iterazione successiva, comunque durante la prima settimana.

Ma ti avvertirò in anticipo cosa accadrà (dopo averlo visto in diverse squadre): finirai in una situazione in cui una iterazione ti fa fare due settimane di lavoro, il QA è sovraccarico, vengono da te per quello intera settimana di QA e, nella seguente iterazione, avrai solo una settimana di lavoro svolto. Quell'iterazione, il QA non avrà nulla da fare e penserai di aver risolto il problema. Ma poi alla prossima iterazione ricomincerai il ciclo.

Quindi, non appena hai aggiunto quella settimana, solo per assicurarti che il tuo rilascio sia stabile (perché una cosa che ho imparato è che se perdi la fiducia nel business, Agile diventa esponenzialmente più difficile da implementare), vai dritto sul piano a lungo termine.

Acquista una copia della consegna continua di Jez Humble, leggila , da copertina a copertina, passala intorno alla squadra. Fatti ispirare tutti. Quindi implementa tutto ciò che puoi da esso.

Rendi il processo di compilazione più fluido che puoi. Implementare una politica di unit test e far funzionare quelli su ogni build. Rendi il processo di distribuzione la cosa più semplice che tu abbia mai visto. Tre clic? Non abbastanza liscio.

Una volta fatto tutto questo, non importa molto se il bug di regressione occasionale viene superato. Tu sai perché? Perché sarai in grado di ripristinare (facoltativamente), risolverlo, distribuirlo di nuovo, prima che l'attività cada a pezzi. In effetti il ​​bidello notturno sarà in grado di eseguire il rollback per te, il processo sarà così semplice.

So cosa stai pensando: non abbiamo tempo per farlo. Lascia che te lo dica, lo fai. Se stai sovraccaricando il QA, stai distribuendo troppo per iterazione. Quindi non farlo. Se non li sovraccarichi già, chiedi loro perché non dispongono ancora di suite di test automatizzate. Lo sarai presto.

Fai tutto questo con piena visibilità per il business. Stimare in basso e iniettare parte di questo lavoro nell'iterazione. O, meglio ancora, spezzalo in storie e fagli dare la priorità, insieme a tutto il resto.

Spiega loro che a) migliorerà la stabilità del rilascio eb) migliorerà la tua capacità di rispondere ai problemi per loro ec) acquisterà più velocità in seguito. È un'azienda rara che non vuole queste cose. Non è certamente una società Agile che non li vuole, quindi, se ottieni resistenza, saprai di avere un problema diverso.

Una volta che hai la pat di consegna continua, puoi iniziare ad abbreviare il tempo che arriva al QA alla fine dell'iterazione. È nell'interesse di tutti riportare le iterazioni in parallelo, il più presto possibile. Forse avrai un giorno alla fine dell'iterazione, dove dovrai riempire il tempo. Ho già risposto cosa fare al riguardo altrove .

Senza usare le iterazioni, questo non è un problema perché possiamo sovrapporre il lavoro per le versioni N e N + 1.

Sembra che ci sia un problema con il modo in cui hai deciso cosa costituisce esattamente work for release N.

Per qualche strana ragione (posso solo immaginare che ci siano dei malintesi su particolari ricette Agile) hai in qualche modo deciso che l'approccio agile impone che tutti gli sforzi del team QA vengano incorporati nell'iterazione.

• ^{Se così fosse, suppongo che la popolarità di Agile non sarebbe nemmeno vicina a ciò che vediamo ora. Non riesco a immaginare molti progetti che potrebbero "sopravvivere" alla sincronizzazione obbligatoria delle iterazioni del team di sviluppo con i cicli di test QA.}

C'è un po 'di più su sull'agilità ma prima, risolviamo work for release N...

Guarda, non c'è proprio alcun motivo convincente per il team di sviluppo di definire il lavoro in quel modo. Al contrario, dalla tua descrizione è chiaro che al posto del monolitico "unità di lavoro", ci sono diverse unità di questo tipo, con pietre miliari che sono facili da sentire ...

• ^{Ad esempio, la prima "unità" è indicata da una pietra miliare distinta quando si costruisce un candidato viene passata ai tester e ulteriori pietre miliari corrispondono ai cambiamenti coinvolti nei cicli di test eseguiti dal QA ecc.}

Nota anche che il modo in cui definisci work for release Nnon è forzato dal flusso di lavoro del QA. Da quello che descrivi le cose sembrano avere il loro programma (e abbastanza ragionevole).

Dato sopra, il modo più realistico per definire le unità di lavoro nel tuo caso potrebbe essere il seguente:

1. Attività di sviluppo fino al momento in cui la build viene passata al QA
   Release Candidate N
2. Attività di sviluppo relative al primo ciclo di test QA
   Release Candidate N patch 1
3. Attività di sviluppo relative al secondo ciclo di test QA
   Release Candidate N patch 2
4. ecc., fino alla build finale

Sopra ci sono le tue unità di lavoro, non importa se fai Agile o altro.

Questi sono naturali e convenienti da definire, seguire e tracciare. Ciò si fonde bene con il programma di controllo qualità, consentendo un comodo coordinamento degli sforzi di sviluppo e controllo qualità.

Tuttavia, da quello che ho capito, questo non è compatibile con approcci basati su iterazioni come Scrum o XP. Richiedono che un'iterazione sia rilasciabile alla fine con tutti gli sforzi di test da incorporare nell'iterazione.

Sopra la comprensione della compatibilità con Agile sembra fondamentalmente sbagliata ed ecco perché ...

L'assunto che hai fatto non ha nulla a che fare con Agile, se prendiamo la sua filosofia al valore nominale come indicato dal suo stesso nome, questo è un approccio che favorisce e pratica l' agilità .

Da quella prospettiva, attenersi a un flusso di lavoro "fisso" e ignorare se è conveniente o semplicemente contraddice lo spirito di Agile. Seguire con diligenza la "procedura" porta a pratiche denigrate in modo così eloquente nel Manifesto Agile Mezzo Ars "... abbiamo processi e strumenti obbligatori per controllare il modo in cui tali individui (preferiamo il termine" risorse ") interagiscono" .

Puoi trovare ulteriori informazioni al riguardo in una risposta a un'altra domanda , citata di seguito. Dai un'occhiata alla nota su "rilascio shippable", sembra che allora OP sia stato confuso in un modo simile:

si dovrebbe essere agili sull'applicazione stessa dei principi agili. Voglio dire, se i requisiti del progetto non sono agili (stabili o cambiano lentamente), allora perché preoccuparsi? Una volta ho osservato il top management forzare Scrum in progetti che stavano andando benissimo senza. Che spreco è stato. Non solo non ci sono stati miglioramenti nella loro consegna, ma peggio ancora, sviluppatori e tester sono diventati infelici.

Per me, una delle parti più importanti di Agile sta avendo un rilascio spedibile alla fine di ogni sprint. Ciò implica diverse cose. In primo luogo, è necessario eseguire un livello di test per garantire che non si verifichino bug in grado di mostrare se si ritiene di poter rilasciare la build a un cliente ...

Rilascio disponibile . Hm. Hmmm. Considera di aggiungere una o due dosi di Lean al tuo cocktail Agile. Voglio dire, se questo non è un bisogno del cliente / mercato, ciò significherebbe solo uno spreco di risorse (test).

Io per primo non vedo nulla di criminale nel trattare Sprint-end-release come un semplice checkpoint che soddisfa la squadra.

• ^{dev: sì, uno sembra abbastanza buono da passare ai tester; QA: sì, uno sembra abbastanza buono per il caso se sono necessari ulteriori test shippable - cose del genere. Il team (dev + QA) è soddisfatto, tutto qui.}