La revisione del codice è in ritardo rispetto al ciclo di consegna / test

Nel nostro processo Agile abbiamo Sprint di 2 settimane. Le attività vengono consegnate su base giornaliera (build giornaliere) e il team di test completa i test immediatamente il giorno successivo o addirittura lo stesso giorno.

Abbiamo anche recensioni di codici Dev, che richiedono un po 'di tempo (1-2 ore), quindi sono programmate 3 volte a settimana: Lun-Mer-Ven. Gli sviluppatori si riuniscono e suggeriscono come migliorare / refattare il codice.

Il nostro problema è che, al momento della comparsa degli articoli di azione dopo una revisione del codice, la maggior parte delle attività sono già state testate. I tester non vogliono testare nuovamente ciò che ha già superato i test. A loro non importa delle modifiche interne agli sviluppatori.

Stiamo fraintendendo il processo Agile? Le revisioni del codice sono incompatibili con un ciclo di rilascio / test giornaliero? Non possiamo tenere recensioni di codice ogni giorno, poiché occupano tutto il tempo.

I tester non vogliono ripetere il test è un po 'come dire "i programmatori non vogliono refactoring". Fa parte del lavoro. Il processo può essere riformulato in questo modo: le attività vengono create. Il codice viene generato. Il codice è stato testato. Il codice è stato rivisto. Le imperfezioni si trovano nel codice. Vengono create nuove attività per affrontare queste imperfezioni (ad es. Il codice viene refactored). Queste nuove attività richiedono nuovi test.

Se hai intenzione di rivedere il codice ad un certo punto, non è più costoso fare la revisione in anticipo. E sembra che tu abbia un costoso processo di test, quindi non vuoi testarlo due volte. Pertanto è più economico rivedere il codice prima del test. La revisione del codice dopo il test non rende il lavoro più veloce. Rende più lento e ti invita a fornire codice scritto male ma testato con successo. Nel tempo tutto questo codice non rivisto renderà il lavoro sempre più lento. Quindi un concorrente più efficiente offre un prodotto migliore a un costo inferiore e il gioco è finito.

Inoltre, automatizza i test. I test manuali sono quindi del 1970.

Se stai trovando difficoltà nel far sì che le revisioni del codice avvengano nel tempo che hai attualmente prima del QA, dovresti considerare di rendere le revisioni del codice più leggere, come Revisione del codice in Agile Teams, Parte II di cui parla @Dukeling.

Ho scoperto che anche la cosa più semplice che potrebbe essere definita una revisione del codice ha dato benefici: prima di eseguire il commit del codice (o di inviare un DVCS), chiama un altro sviluppatore e guidalo attraverso la tua modifica. Questo potrebbe richiedere cinque o dieci minuti. L'obiettivo di questa recensione del codice è "Ha senso per l'altro sviluppatore?" L'obiettivo non era puntellare sulle implementazioni del design o conformarsi completamente alle idee personali del recensore su come avrebbe dovuto essere scritto. Ha dato questi vantaggi:

• Conoscenza condivisa migliorata del funzionamento del codice
• Catturato codice confuso o potenzialmente errato perché l'atto di spiegare il codice era sufficiente per far ripensare le cose all'autore
• Ha contribuito a far evolvere gradualmente i modi di dire e lo stile del team, perché ha reso più facile spiegare le cose
• Pochissime lamentele da parte della squadra

Revisioni più approfondite del codice funzionano assolutamente meglio per trovare problemi. Ma devi essere in grado di farli e agire su di essi per ottenere il valore. Un processo leggero che puoi fare tutto il tempo può essere più utile di un processo pesante che continua a rimandare o semplicemente aggiunge cose al backlog.

Una soluzione a questo problema è fare una rapida revisione del codice da parte di un altro peer una volta terminata la storia dell'utente, in modo che non ci siano errori di base / ovvi nel codice.

Ma questo deve accadere prima del ciclo di prova. Quindi ci sarebbero meno modifiche al codice dopo il test, quando si eseguono revisioni più ampie con tutti i team insieme.

A quanto pare, i tester non vogliono ripetere il test perché il test è un processo doloroso / costoso.

L'automazione dei test sia da parte degli sviluppatori che dei tester è un enorme vantaggio per i team che cercano di lavorare in modo agile. Più i test sono più economici, più facili e riproducibili, più è possibile eseguirli e minore è la resistenza al cambiamento.

Hai fatto un refactor rapido basato su alcuni feedback degli sviluppatori? Premi il grande pulsante rosso che esegue la tua suite di regressione / fumo ed esegui un rapido manuale una volta per verificare la presenza di eventuali problemi visivi che potrebbero essere spuntati. Facile!

Una volta che ti trovi in ​​un posto come quello, riprovare non sarà un lavoro ingrato - sarà una seconda natura.