In Scrum, chi verifica "Fatto"?

Un'idea principale in Scrum è che il team dovrebbe essere d'accordo su una "definizione di fatto". Idealmente, questo è qualcosa come un insieme di criteri oggettivi che chiunque può verificare passando da una lista di controllo.

Ma per ridurre la possibilità che qualcosa sfugga, è perfettamente logico avere una regola che la verifica del "fatto" sia eseguita da qualcuno diverso dalla persona che ha implementato un oggetto - o da un QA designato come te (ma che rischia di farti un collo di bottiglia).

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

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

Tuttavia, ci sono regolarmente più attività rispetto a quelle visibili al proprietario del prodotto, di solito un po 'semi-tecnico nella migliore delle ipotesi, 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, è in definitiva il team a determinare cosa significa "fatto". L'organizzazione può avere standard e diverse parti interessate avranno i propri requisiti. Il supervisore di mischia o i dirigenti competenti di solito sono responsabili per la raccolta e l'applicazione della lista.

Nel tuo esempio, come QA / Test Manager, sei tu a decidere 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 è completata o meno. Il team dovrebbe aver creato una definizione di fatto che dice quando sentono che una storia è finita o meno. Questo in genere include cose come "il codice è stato revisionato", "i test notturni sono stati eseguiti", "tutti i criteri di accettazione sono stati soddisfatti", ecc. Quando queste cose sono state realizzate, il team può sentirsi sicuro di aver fatto tutto ci si aspetta che finiscano una storia.

Durante uno sprint, se stai cercando di determinare se uno di quegli elementi nella definizione di fatto è stato completato, basta chiedere. Scrum e agile è tutto basato sulla comunicazione aperta. Se fai parte del team, chiedi ai tuoi compagni di squadra se qualcuno ha scritto i test, o eseguirli, o ha creato il lavoro notturno, ecc. Se sei uno stakeholder, chiedi al master mischia.

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

In definitiva, è il proprietario del prodotto che firma una storia particolare, quindi alla fine della giornata ha la decisione finale se una storia nel suo complesso è stata realizzata o meno.

Prima domanda che dovresti porvi

Sei lo Scrum Master ? se sì.

Nei processi di mischia sono controllati e gestiti dallo Scrum Master.

Come si fa:

Nella fase dei requisiti puoi utilizzare storie utente per ogni test che deve essere verificato.

In ogni Sprint Gli elementi di lavoro vengono estratti dal backlog del prodotto e diretti dal proprietario del prodotto. Anche loro avranno criteri di verifica.

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

Se il suo risultato può essere trovato solo dalla risposta del proprietario del prodotto.

Ricorda in Agile che "Abbraccia la modifica" anche in ritardo nella fase di sviluppo

La squadra decide. Io uso una checklist, per quello che è considerato 'Fatto'. Cosa è "Fatto" per trama, per scatto, per versione.

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

Accetta che questo è qualcosa che il team di sviluppo / test deve definire, a seconda delle tue pratiche. Alcuni progetti sono così agili da essere disposti a rischiare di rilasciare bug nel loro stream alfa; alcuni considerano qualsiasi errore che esuli dal gruppo di sviluppo un errore del processo.

Il progetto a cui sto lavorando richiede la revisione da parte dei colleghi delle modifiche al codice e richiede che chiunque abbia scritto il codice fornisca / aggiorni i test di regressione o spieghi perché non è possibile farlo. (Inoltre, i loro revisori devono certificare che hanno verificato pratiche errate note. Siamo generalmente molto più felici se possono dimostrare di aver eseguito l'intera suite di test e di aver ottenuto un risultato pulito (o modulo pulito noto problemi aperti, almeno) Il codice deve sopravvivere a un'unità automatizzata intensiva e a test funzionali su piattaforme multiple per dimostrare che non provoca alcuna regressione contro quelli, e viene ulteriormente controllato per antipattern comuni da un sistema di analisi automatica del codice. quindi lo accettiamo nel flusso di sviluppo principale e contrassegniamo l'elemento di lavoro completo. Si noti che il completamento di un elemento di lavoro può essere solo un passo verso il completamento di un'attività o una storia di dimensioni maggiori.

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