Dilemma di QA contro iterazioni

We understand QA as an extra bit of verification to a certain build (release candidate) before this build gets deployed to the customer.

Non c'è nulla di intrinsecamente incompatibile tra questa forma di QA e le metodologie basate su iterazioni come Scrum.
All'interno di Scrum, il team consegna un risultato su un ciclo X-settimanale come suo cliente. La parte importante qui è che, se il team di sviluppo sta facendo Scrum, il loro cliente è il team di QA, non l'utente finale del tuo prodotto.

Come sviluppatore, considererei un prodotto spedibile a QA se ha una possibilità di superare tutti i test. Questo probabilmente significa che alcuni dei test QA sono già stati eseguiti sui build giornalieri, ma il modo in cui questo influisce sui test di rilascio ufficiali da parte del team addetto al controllo qualità dipende dalla tua organizzazione.

Per la maggior parte delle situazioni di vita reale, l'agile si ferma alla consegna al QA / UAT o qualunque sia il suo nome.

Lo sforzo per passare dal QA alla produzione in un ambiente di vita reale è spesso sottovalutato. In molti casi ciò coinvolge veri utenti business nei test, la gestione si disconnette dalla linea reale dei manager aziendali, pianifica il rilascio con operazioni, ecc. Ecc. Questo non è banale!

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

In queste circostanze è semplicemente impossibile prevedere più di una release per trimestre tranne per le correzioni di bug.

Diventa peggio per un prodotto software serio. La documentazione deve essere verificata e pubblicata. Le brochure di marketing devono essere modificate. Agli addetti alle vendite è necessario dire cosa stanno vendendo (non è un compito facile!) Ecc. Ecc. Davvero non vuoi far passare questo business più di una volta all'anno.

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

Ma ti avvertirò in anticipo cosa succederà (visto questo in diverse squadre): finirai in una situazione in cui una ripetizione di lavoro della durata di due settimane, il controllo qualità sono sovraccarichi, stanno arrivando per tutta la settimana del QA e, nella seguente iterazione, avrai solo una settimana di lavoro. Quella iterazione, il controllo qualità non avrà nulla da fare e penserai di aver risolto il problema. Ma dopo l'iterazione successiva ricomincerai il ciclo.

Quindi, non appena avrai 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 di Jez Humble Consegna continua , leggilo, copri-a-copertina, passalo in giro Il gruppo. Fai ispirare tutti. Quindi implementa tutto ciò che puoi da esso.

Rendi più fluido il processo di costruzione. Implementa una politica di unit test e ottieni quelli in esecuzione su ogni build. Fai in modo che il processo di distribuzione sia la cosa più intelligente che tu abbia mai visto. Tre clic? Non abbastanza lucido.

Una volta che hai fatto tutto questo, non importa tanto se il bug di regressione occasionale passa attraverso. Tu sai perché? Perché sarai in grado (facoltativamente) di tornare indietro, ripararlo, distribuirlo di nuovo, prima che l'azienda cada a pezzi. Infatti il custode notturno sarà in grado di eseguire il rollback per te, il processo sarà così semplice.

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

Fai tutto questo con piena visibilità al business. Stimare in basso e iniettare parte di questo lavoro nell'iterazione. O, meglio ancora, suddividilo in storie e fagli prendere la priorità, accanto a tutto il resto.

Spiega loro che a) migliorerà la stabilità del rilascio e b) migliorerà la tua capacità di rispondere ai problemi per loro e c) li acquisterà più velocemente in seguito. È una società rara che non vuole queste cose. Non è certo un'azienda agile che non li vuole così, se ottieni resistenza, saprai che hai un problema diverso.

Una volta scaricata la consegna continua, puoi iniziare a ridurre il tempo che il QA ottiene alla fine dell'iterazione. È nell'interesse di tutti riportare le iterazioni in parallelo, il prima possibile. Forse avrai un giorno alla fine dell'iterazione, dove dovrai riempire il tempo. Ho già ha risposto cosa fare in merito altrove .

Without using iterations, this is no problem because we can overlap the work for releases N and N+1.

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

Per qualche strana ragione (posso solo supporre che ci sia qualche incomprensione di particolari ricette Agile) hai in qualche modo deciso che l'approccio agile impone tutti gli sforzi del team QA da incorporare nell'iterazione.

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

C'è un po 'di più in agility sotto, ma prima, risolviamo work for release N ...

Guarda, non vi è alcun motivo convincente per il team di sviluppo di definire il lavoro in questo modo. Al contrario, dalla tua descrizione è chiaro che al posto della "unità di lavoro" monolitica, ci sono diverse unità di questo tipo, con pietre miliari facili da percepire ...

• ^{Ad esempio, la prima "unità" è indicata da una milestone distinta quando la build candidata viene passata ai tester, e ulteriori milestone corrispondono alle modifiche coinvolte nei cicli di test eseguiti dal QA ecc.}

Nota anche che il modo in cui definisci work for release N non è forzato dal flusso di lavoro di QA. Da quello che descrivi le cose sembra che abbiano il loro programma (e abbastanza ragionevole).

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

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 del QA
   Release Candidate N patch 1
3. Attività di sviluppo correlate al secondo ciclo di test del QA
   Release Candidate N patch 2
4. etc, fino alla build finale

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

Sono naturali e convenienti per definire, seguire e tracciare. Questo si integra bene anche con il programma di QA, consentendo un coordinamento coordinato odf dev e sforzi di QA.

However, from what I understand, this is not compatible with iteration-based approaches like Scrum or XP. They demand an iteration to be releasable at its end with all testing effort to be incorporated in the iteration.

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

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

Da quella prospettiva, attenendosi a un particolare flusso di lavoro "fisso" e ignorando se sia conveniente o meno semplicemente contraddire lo spirito di Agile. Seguire pedissequamente la "procedura" porta a pratiche >> denigrato così eloquentemente in Haf-Arsed Agile Manifesto "... abbiamo processi e strumenti obbligatori per controllare come quegli individui (preferiamo il termine 'risorse') interagiscano" .

Puoi trovare ulteriori informazioni al riguardo in una risposta a un'altra domanda , riportata di seguito. Dai un'occhiata alla nota su "versione shippable", sembra che all'epoca OP fosse confuso in un modo simile:

one should be agile about very application of agile principles. I mean, if the project requirements aren't agile (stable or change slowly), then why bother? I once observed top management forcing Scrum in projects that were doing perfectly well without. What a waste it was. Not only there were no improvements in their delivery but worse, developers and testers all became unhappy.

For me, one of the most important parts of Agile is having a shippable release at the end of each sprint. That implies several things. First, a level of testing must be done to ensure no showstopping bugs if you think you could release the build to a customer...

     

Release Shippable vedo. Hm. Hmmm. Considera l'aggiunta di uno o due shot di Lean nel tuo cocktail Agile. Voglio dire, se questo non è un bisogno di cliente / mercato, questo significherebbe solo uno spreco di risorse (di test).

     

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

     

• ^{dev: sì quello sembra abbastanza buono da passare ai tester; QA: sì, uno sembra abbastanza buono per il caso se sono necessari ulteriori test di spedizione - roba del genere. Team (dev + QA) è soddisfatto, il gioco è fatto.}