Codifica e prova nello stesso sprint

Se non si verifica una User Story (Stati Uniti) e si verifica che i criteri di accettazione siano soddisfatti, questa storia non viene eseguita. Se non è stato fatto, questo US andrà al prossimo sprint, naturalmente. E se tutti i tuoi Stati Uniti sono in questo stato, lo sprint è terminato senza alcun valore aggiunto al progetto. Dal punto di vista del cliente non riesco a distinguerlo dall'intero team di sviluppo in vacanza.

Uno dei principi lean (agile non finisce con la mischia) dice "la qualità è incorporata". Qualcosa è fatto solo se soddisfa i criteri di qualità che definisci. Questo è fondamentale per avere un vero processo agile, terminare la primavera con valore zero o test separati dallo sviluppo sono i sintomi di un grosso problema.

Ci sono molte cose che puoi fare:

• l'automazione è la chiave del successo. Almeno a livello di test unitario e anche altre pratiche come l'IC sono importanti. Questo non è abbastanza, ma se fatto bene questi tipi di test risultano in pochi o nessun bug scoperto nei test manuali (di solito cose minori dell'interfaccia utente). Se hai persone QA dedicate, possono essere quelle che automatizzano i test di accettazione e parte di questa automazione può iniziare prima di finire uno sprint.

• Guarda le dimensioni delle tue User Story. Se hai un USA che ha terminato i primi due giorni dello sprint, il terzo giorno una persona del QA può testarlo. A mio parere, avere una piccola (SMART) user history una delle cose più importanti per il successo nello sviluppo agile, e molte persone non sembrano rendersene conto.

• La collaborazione tra tester e sviluppatori è un'altra parte fondamentale del successo. Nel mio precedente progetto, quando un americano è finito da uno sviluppatore, una persona di controllo qualità fa "coppia di test" con lo sviluppatore (può essere manuale, può essere lanciando alcuni automatizzati, o meglio entrambi), funziona abbastanza bene.

Il problema essenziale è che hai programmatori che codificano ma non testano e tester che testano ma non codice.

Risolvi il problema e non avrai questo problema e un team forse più efficiente.

Un modo per me ha funzionato in passato è stato quello di suggerire programmatori e tester per accoppiare storie con l'esplicito compito di fornire una storia completamente testata. Insieme a ciò ho cancellato tutte le forme di pensiero "dev complete": nessuna colonna "dev complete" sulla tabella scrum / kanban / trello, nessun atteggiamento "dev done" da parte dei programmatori.

Quello che è successo è stato:

• Le coppie erano responsabili della pubblicazione di storie e sarebbero entrambe fallite se una storia non fosse stata completata. Sono stati trattati come professionisti responsabili incaricati della consegna del software e lo hanno fatto, nella maggior parte dei casi.

• Il lavoro di testing è stato molto inferiore perché i tester sono stati esposti a test di unità e di integrazione, quindi non hanno ripetuto lo stesso test manualmente.

• Alcuni test sono stati automatizzati quando gli sviluppatori hanno capito meglio di cosa avevano bisogno i tester.

• Alcune persone si sono arrabbiate.

• Le storie sono state rese più veloci in media perché il ciclo code-commit-pull-test è diventato quasi istantaneo

Naturalmente, questa è solo la mia esperienza aneddotica, ma potresti provare tu stesso, se puoi.

Nel tuo caso, dato il tuo commento che i tester e gli sviluppatori sono autorevolmente separati nella tua azienda, il messaggio mi sembra chiaro. C'è una barriera evidente alla comunicazione e alla collaborazione regolata dalle regole aziendali.

Questo è un problema di comunicazione , non un problema agile . Adottare una metodologia agile sta semplicemente rendendo evidente. I team di Silo sono un anti-pattern di gestione noto , quindi abbracciare la non adattabilità di agile in questo caso!

Il vero ruolo del tuo controllo qualità è vicino ai test di accettazione. Immagino che ciò sia fatto da un team separato, che agisce più come proprietario del prodotto piuttosto che come parte del team di sviluppo.

Esempio: durante uno sprint, è necessario aggiungere una funzione che consente di filtrare i risultati della ricerca secondo criteri diversi. Hai già implementato il tuo meccanismo di ricerca, ma i risultati sono ordinati in ordine alfabetico.

• Durante lo sprint:

  1. Il team disegna il design della nuova funzione e l'impatto sulla base di codice effettiva.

  2. Gli sviluppatori scrivono test di unità che assicurano che l'ordine funzioni come previsto e, allo stesso tempo, scrive il codice effettivo.

  3. La nuova funzione è attentamente testata per garantire che non si rompa nulla (test di regressione) e che funzioni come previsto (unit test).

  4. Se possibile e appropriato , che non è il caso nella maggior parte dei progetti , il proprietario di un prodotto (e quindi il tuo team di QA) può valutare costantemente la nuova funzionalità per evitare che la squadra vada nella direzione sbagliata. Ciò richiede una continua integrazione con dozzine di build ogni giorno.

• Dopo lo sprint, il proprietario del prodotto valuta la nuova funzione per verificare che corrisponda alle esigenze del cliente. Il tuo team di QA è effettivamente qui, dopo lo sprint terminato.

Credo che i tuoi problemi attuali siano i seguenti:

• Ambito di applicazione . Uno sprint riguarda il tuo team e solo il tuo team, non il tuo QA effettivo che agisce più come proprietario di un prodotto.

• Test . Il fatto che tu abbia un team di controllo qualità non significa che tutto ciò che devi fare è scrivere codice. Il lavoro del tuo team è quello di fornire una funzionalità che funzioni come previsto, non di buttare fuori codice da testare per gli altri. Se ti affidi al team di QA per fare il test per te, questo aumenterà il costo complessivo, dal momento che i bug verranno risolti una o due settimane dopo invece di essere corretti quasi istantaneamente.

if all or most of the coding is not done until the end of the sprint?

Perché non finisce prima? Questa limitazione chiave è la fonte dei tuoi problemi e ho visto due approcci avere successo. Uno si adatta bene all'approccio agile (ma non ad altre pratiche comuni) e gli altri ritmi agili un po '(ma è più comune).

Il primo è che non si codifica fino alla fine dello sprint. In realtà scrivere codice è una parte relativamente piccola dello sviluppo. Se finisci all'incirca a metà dello sprint, questo fornisce un sacco di tempo per il controllo qualità a svolgere il loro lavoro. Inoltre ti lascia un sacco di tempo per scrivere documentazione, ripulire il debito tecnico, fare progetti per gli articoli arretrati ... Tutte le altre cose che devi fare per un prodotto di qualità. L'unico lato negativo di ciò che ho visto è che è quasi impossibile ottenere la funzionalità e dei test unitari fatti in fretta. Personalmente, penso che sia del tutto corretto fare test unitari dopo lasciando che QA inizi a dare un'occhiata alla funzionalità, ma i sostenitori di TDD (e altri) non saranno d'accordo.

La seconda opzione è fare in modo che il QA gestisca uno sprint dietro il personale di sviluppo come il tuo PM odia. Tendo anche a non gradirlo. Elimina il concetto di "prodotto rilasciabile" alla fine dello sprint, anche se hai un processo di escalation per le tue versioni. Peggio ancora, gli sviluppatori si concentreranno su cose "nuove" quando il QA arriva da loro con domande o errori dai test. È inoltre improbabile che gli sviluppatori risolvano bug in questo accordo. Ma ho visto che produce software di qualità in tempo.

La guida Scrum richiede che i team siano interfunzionali. Tutti i membri del team sono considerati sviluppatori, indipendentemente dalla loro specializzazione individuale. Gli utenti di Silo (coder, tester, qa, ux, ecc.) Non sono di aiuto in Scrum. I membri del team si aiutano reciprocamente, ovunque possono. Non esiste il concetto di "passare l'oggetto a qa".

Nella tua situazione, sembra che tu possa avere un problema di stima. Quando si stimano gli articoli del backlog del prodotto, è necessario considerare le attività tutte , vale a dire: codifica, test, peer review, distribuzione, integrazione, qualunque sia la definizione delle richieste fatte.

Come regola approssimativa, si prevede di portare tra 5 e 15 articoli del backlog di prodotto in uno sprint. Questo ti dà un'idea di quanto dovrebbe essere grande ogni articolo del backlog prodotto. Ti dà anche un'eccellente possibilità di portare a termine il lavoro entro lo sprint.

Infine, il compito del team è quello di spostare un articolo del backlog del prodotto su "fatto" e poi passare a quello successivo. A volte, ciò significa che le persone si calpestano le une alle altre e quindi ha senso girare più di un backlog di prodotti alla volta. Tuttavia, la tua linea guida dovrebbe essere quella di ridurre il work in progress (WIP) e spostare gli elementi del backlog del prodotto su done.

Test e codifica vanno di pari passo. Potresti programmarlo modulo per modulo. Una volta che il modulo è finito, puoi fornirlo ai tester. L'intero scenario dipende anche dalla fase di test su cui si sta lavorando. Il modello SDLC a spirale sembra buono. In questo, i test e la codifica simultanei sono convenienti. Un altro approccio potrebbe essere V modello .

La mia risposta, che all'inizio è probabilmente piuttosto strana, sarebbe: non trovi il tempo di testare perché ritieni che il test debba essere eseguito sugli effetti collaterali del codice. E con effetto collaterale intendo il termine di informatica :

a function (...) is said to have a side effect if, in addition to returning a value, it also (...) has an observable interaction with (...) the outside world.

Ho sollevato la citazione per enfatizzare la parte "interazione con il mondo esterno": vuoi che i test avvengano sull'interfaccia utente mentre viene stampata sullo schermo ("[avviare i test] non è realmente possibile dal momento che generalmente bisogno di un'interfaccia utente funzionale per registrare o creare test automatici da ").

Altre risposte ti hanno detto di automatizzare questo "test di accettazione", in modo che possa accadere rapidamente. Questo è giusto, ma non affronta completamente il tuo problema originale: cosa succede se non c'è abbastanza tempo per scrivere quei test di accettazione?

Devi lasciare andare la tua visione del test una volta che il codice ha interagito con il mondo esterno, cioè ha stampato qualcosa e si aspetta qualche input. Il problema degli effetti collaterali è che sono, in effetti, non verificabili. Mi è venuto in mente mentre leggevo un'intervista con Guido van Rossum, in cui diceva che una dichiarazione che spegne il computer può funzionare solo eseguendola.

La soluzione a tale "non testabilità" è capire che, se hai dimostrato una volta che la dichiarazione funziona, puoi usarla ovunque e fare affidamento su di essa per fare il suo lavoro. Isolarlo in una funzione e testare tutto il resto .

Avvicinando l'esempio alla tua domanda, la funzione ora è probabilmente un'intera libreria o framework, e invece di spegnere il computer, stampa qualcosa: un'interfaccia utente. Tieni le chiamate più stupide e il più possibile stabili , perché una volta inserita questa parte della tua applicazione, puoi testare solo attraverso costosi test di accettazione, cioè qualche tipo di osservazione esterna.

Considerare l'interfaccia utente come "territorio straniero" è in realtà un punto di vista corretto, dal momento che non è necessario testare la logica di una libreria che non è stata fornita da te, e forse sorprendentemente, è un punto di vista realistico: ti aspetti veramente di provare quella chiamata, ad es MyWidget.draw() fa quello che ti aspetti, al livello di un singolo pixel?

Questo non vuol dire che il test di accettazione non sia importante o che possa essere saltato. È lì per restare e automatizzarlo, come suggeriscono altre risposte, ha enormi vantaggi. Ma se vuoi trovare il tempo per testare e programmare nello stesso sprint, prova a mantenere il tuo codice libero dagli effetti collaterali il più possibile.