In Scrum, chi verifica "Fatto"?

Sono un responsabile del controllo qualità / test nella mia organizzazione e fino ad oggi ho verificato la qualità del software (test scritti ed eseguiti e bug corretti). Chi lo verificherà in Scrum? Come faccio a sapere che il team ha scritto ed eseguito tutti i test giusti? D'altra parte temo che se continuo a fare la verifica la squadra non si sentirà sufficientemente autorizzata. Ma ho bisogno di un processo di verifica che "Fatto" sia effettivamente "Fatto". Cosa suggerisci?

Un'idea importante in Scrum è che il team dovrebbe concordare una "definizione di fatto". Idealmente, questo è qualcosa come una serie di criteri oggettivi che chiunque può verificare attraverso una lista di controllo.

Ma per ridurre la possibilità che qualcosa sfugga, ha perfettamente senso avere una regola secondo cui la verifica del "fatto" deve essere eseguita da una persona diversa dalla persona che ha implementato un oggetto - o da un tipo designato come te (ma che rischia di farti un collo di bottiglia).

In caso di dubbi, discutere con il team e lo Scrum Master e decidere insieme.

Penso che ci sia un presupposto implicito nella domanda. Esiste una differenza tra "accettato", quando un Product Owner dichiara che un articolo di backlog o un'attività ha soddisfatto il Product Owner e "fatto" significa che tutto il lavoro associato all'elemento di backlog è completo.

Tuttavia, ci sono regolarmente più attività da svolgere rispetto a quelle visibili al Product Owner, di solito nella migliore delle ipotesi semi-tecniche, inclusi test (automatici e manuali), documentazione e revisione. Il Product Owner raramente è in grado di conoscere gli aspetti tecnici, figuriamoci se sono stati completati.

Pertanto, spetta alla squadra determinare cosa significa "fatto". L'organizzazione può avere standard e diverse parti interessate avranno i propri requisiti. Il mastro scrum o i gestori pertinenti di solito sono responsabili per la raccolta e l'applicazione dell'elenco.

Nel tuo esempio, come QA / Test manager, sei tu a dire se i test sono completi. Tuttavia, potresti non essere la persona migliore per dire se il codice è stato rivisto, i requisiti di sicurezza sono soddisfatti, il prodotto è internazionalizzato, la documentazione è completa o qualsiasi altra cosa costituisce "fatto".

L'unico concetto di "fatto" è se una storia nel suo insieme è o meno completata. Il team avrebbe dovuto creare una definizione di fatto che dice quando sentono che una storia è finita o no. Questo di solito include cose come "il codice è stato rivisto", "i test notturni sono stati eseguiti", "tutti i criteri di accettazione sono stati soddisfatti", ecc. Quando queste cose sono state raggiunte, il team può sentirsi sicuro di aver fatto tutto si aspettavano da loro di finire una storia.

Durante uno sprint, se stai cercando di determinare se uno di quegli elementi nella definizione di done è stato realizzato, basta chiedere. Scrum e agile si basano sulla comunicazione aperta. Se fai parte del team, chiedi ai tuoi compagni di squadra se qualcuno ha scritto i test, o li ha eseguiti, o ha creato il lavoro notturno, ecc. Se sei un stakeholder, chiedi allo scrum master.

Se ti siedi fuori dal team ma devi comunque rivedere i test, fai aggiungere al team "i test devono essere esaminati dall'utente user3251930" come parte della definizione di done. Se è quello che serve per fare una storia, sii onesto e rendila parte del processo. Il punto centrale della "definizione di fatto" è che il team possa sapere con certezza di aver fatto ciò che è necessario per fornire software di qualità. Se parte di ciò è una revisione esterna, così sia.

In definitiva, è il proprietario del prodotto a firmare una storia particolare, quindi alla fine della giornata ha la decisione finale sul fatto che una storia nel suo complesso sia o meno realizzata.

Prima domanda che dovresti porti

Sei lo Scrum Master ? se si.

I processi di Scrum sono controllati e gestiti dallo Scrum Master.

Come si fa:

Nella fase dei requisiti è possibile utilizzare le user story per ognuna è presente un test che deve essere verificato.

In ogni Sprint Gli articoli di lavoro vengono estratti dal portafoglio ordini del prodotto e diretti dal proprietario del prodotto. Ciascuno di essi avrà anche criteri di verifica.

Ora in Scrum i requisiti non cambiano dopo che lo sprint è iniziato. Alla fine dello Sprint è possibile analizzare la verifica in base ai criteri per ogni articolo fatto.

Se fatto, può essere trovato solo dalla risposta del proprietario del prodotto.

Ricorda in Agile che "Abbraccia il cambiamento" anche in ritardo nella fase di sviluppo

La squadra decide. Uso una lista di controllo, per quello che è considerato 'Fatto'. Cos'è "Fatto" per storia, per scatto, per uscita.

Come altri hanno già detto, in definitiva la decisione spetta al proprietario del prodotto.

Concorda sul fatto che questo è qualcosa che il team di sviluppo / test deve definire, a seconda delle tue pratiche. Alcuni progetti sono così agili che sono disposti a rischiare di rilasciare bug nel loro flusso alfa; alcuni considerano qualsiasi errore che esce dal gruppo di sviluppo un fallimento del processo.

Il progetto a cui sto lavorando richiede una revisione tra pari delle modifiche al codice e richiede che chiunque abbia scritto il codice fornisca / aggiorni i test di regressione o spieghi perché non è possibile farlo. (Loro e i loro revisori devono anche certificare di aver verificato la presenza di cattive pratiche conosciute. In genere siamo molto più felici se possono dimostrare che hanno eseguito l'intera suite di test e hanno ottenuto un risultato pulito (o noto modulo pulito problemi aperti, almeno) Il codice deve quindi sopravvivere a unità automatizzate intensive e test funzionali su più piattaforme per dimostrare che non provoca regressioni contro di esse e viene ulteriormente verificato per gli antipattern comuni da un sistema di analisi del codice automatizzato. quindi lo accettiamo nel flusso di sviluppo principale e contrassegniamo l'elemento di lavoro come completo.

Ciò ovviamente non garantisce che nessuno trovi un nuovo modo di fallire, ma riduce il rischio a un livello accettabile senza ostacolare notevolmente la velocità di sviluppo.