Scrum Sprint Stories in Testing

Se sei lo scrum master e il product owner sei un project manager che finge di fare scrum.

Il proprietario del prodotto deve essere assolutamente qualcuno del cliente che ha il potere di approvare storie, dare priorità alle storie e accettare storie come complete. Ciò è necessario perché costringe il cliente a essere coinvolto nel processo e le aspettative dovrebbero essere più strettamente correlate perché approvano e accettano ciò che accade e quando. Se il tuo cliente non vuole essere coinvolto a questo livello è davvero difficile fare scrum.

I modi migliori per aiutare a gestire le aspettative dei clienti sono continuare a incoraggiarli a coinvolgere almeno una persona e ad assicurare che ogni storia abbia una solida definizione di fatto che sia te che il cliente comprendano.

Se il problema dei clienti che non sono disponibili a testare è più un problema di temporizzazione, piuttosto che i clienti non sono disposti a trascorrere del tempo, è possibile eseguire "sprint di QA" in parallelo con gli sprint di sviluppo. È decisamente più pesante e pesante, ma può essere fatto funzionare. Essenzialmente si chiuderebbe lo sprint 1 e si spostasse in un ambiente QA / Staging e si iniziasse a lavorare su sprint 2. Durante quel periodo il client può testare sprint 1 e possono creare nuove storie per risolvere i problemi che trovano, possono anche decidere se queste cose sono in grado di aspettare di essere fatto nello sprint 3 o se qualcosa dovrebbe essere portato fuori dallo sprint 2 per fare spazio. Quando sei pronto per un rilascio, probabilmente dovresti interrompere lo sviluppo e fare in modo che lo "sprint di rilascio" sia focalizzato sulla creazione del rilascio e sulla risoluzione di eventuali problemi con lo sprint di sviluppo precedente.

we were having a lot of issues in Customer expectation

Trovare la causa principale di questo è il modo migliore per migliorare. I sintomi possono essere trattati ma i miglioramenti saranno minimi o inesistenti. I desideri erano capiti male? I criteri di accettazione erano carenti? Gli incrementi non sono stati fatti? Il framework Scrum è compreso da tutte le parti coinvolte?

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”

The Scrum Guide

Il cliente non definisce la definizione di Fatto.

Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment The Scrum Guide

Il test del cliente non può impedire a un articolo di diventare Fatto.

A Sprint Review is held at the end of the Sprint to inspect the Increment The Scrum Guide

Una volta completato l'incremento, è necessario rivederlo con il cliente. Il feedback di questo evento può creare nuovi elementi nel Product Backlog.

Semplicemente, il backlog e in particolare il backlog sprint devono includere solo elementi che possono essere completati dal team di sviluppo. Questo è il team di sviluppo nel senso Scrum: cioè, chiunque e chiunque faccia parte del team Scrum. Potrebbero essere sviluppatori reali, QA, amministratori di infrastrutture, amministratori di database, ecc. Il punto è che sono queste persone che stanno effettivamente facendo il lavoro e, soprattutto, sono queste persone che stanno facendo lo sprint planning e i quotidiani.

Inoltre, la tua definizione di Done dovrebbe includere solo gli elementi che il team di sviluppo è in grado di fornire. Un PBI viene completato quando il team di sviluppo ha completato tutto il lavoro su di esso e ha raggiunto la definizione di accordo concordata. Dal momento che solo il team di sviluppo è responsabile della conduzione dello sprint e che tutti i PBI vengono "fatti", non ci può essere alcuna influenza esterna nella definizione di fatto.

Considerate queste due cose, la verifica e l'approvazione delle parti interessate non devono far parte della definizione di fatto o parte dello sprint. Piuttosto, sarebbe parte della pianificazione del tuo rilascio. Uno degli aspetti più brillanti di Scrum che le persone sembrano mancare completamente è che gli sprint non devono essere seguiti dalle pubblicazioni. Il team offre un incremento del software funzionante e funzionante che è potenzialmente rilasciabile, ma non ci sono condizioni su quando o anche se deve essere effettivamente rilasciato. In genere, le persone che hanno iniziato a incasinare in Scrum arrivano qui. Iniziano a provare ad aggiungere ogni sorta di condizioni per stabilire se qualcosa è stato "fatto" o meno ai fini dello sprint, in base a condizioni arbitrarie al rilascio del software.

Quando ci sono forze esterne coinvolte nel decidere se un PBI è fatto o no, finirai per perdere gli obiettivi sprint ogni volta. Semplicemente, non controlli le parti interessate, ed è impossibile assicurare che rivedranno l'incremento prima dello sprint. Di conseguenza, finirai con tutti i tuoi PBI seduti nella colonna "in corso" al termine dello sprint.