Cosa succede tra gli sprint?

11

Sto lavorando a un progetto che segue vagamente il modello di mischia. Facciamo sprint di due settimane. Qualcosa su cui non sono chiaro (e non ho un libro da consultare) è esattamente ciò che dovrebbe succedere tra gli sprint: dovrebbe esserci un processo di "avvolgimento", in cui il prodotto viene costruito e consegnato, ma:

quanto tempo richiede in genere?
dovrebbe essere coinvolto l'intero team?
deve assolutamente finire prima che gli sviluppatori inizino a lavorare sui prossimi elementi dello sprint?
è questo quando si verificano la revisione e il test del codice?

Esistono tre sviluppatori, per un massimo di circa 1 ETP. Quindi gli sprint sono davvero molto brevi.

agile scrum sprint

— Steve Bennett
fonte

1

Come ha detto JW01, dovresti cercare di ridurre al minimo il tempo tra gli sprint. È una cattiva abitudine / processo imperfetto avere sempre del tempo libero nel mezzo. Tuttavia, è sempre possibile aggiungere altri test, avviare un mock-up della GUI per lo sprint successivo, magari aggiungere commenti utili a un bug esistente. È facile lasciarsi trasportare e iniziare a passare del tempo su cose che il tuo manager non apprezzerà necessariamente.

— Giobbe

13

What happens between sprints?Feste LAN, ovviamente ...

— yannis il

I fine settimana, si spera.

— MrFox,

13

Sto lavorando a un progetto che segue vagamente il modello di mischia.

Per chiarire: i tuoi manager probabilmente ti hanno parlato di Scrum ma ciò che esegui non è Scrum.

Quanto tempo richiede in genere?

La riunione di revisione Sprint + La riunione di retrospettiva Sprint termina lo sprint corrente. In breve sprint dovrebbero prendere qualcosa tra 30 minuti - 1 ora insieme. Il giorno lavorativo successivo inizia un nuovo sprint eseguendo le riunioni di pianificazione Sprint 1 e 2. In base alle dimensioni del team e alla durata dello sprint, questa riunione può richiedere da 2 a 4 ore.

L'intero team dovrebbe essere coinvolto?

L'intero team deve essere coinvolto nelle riunioni menzionate nella risposta precedente.

Deve rigorosamente finire prima che gli sviluppatori inizino a lavorare sui prossimi elementi dello sprint?

Sì perché fino al termine della riunione di revisione non sai se il cliente accetta il risultato dello sprint precedente e non sai quali storie degli utenti verranno impegnate nella pianificazione delle riunioni.

È quando si verificano la revisione e il test del codice?

No. La revisione e il test del codice fanno parte dello sprint. Gli sviluppatori devono fare tutto il necessario per fornire un codice di lavoro che soddisfi i requisiti. Ciò può includere revisioni del codice e deve sempre includere una sorta di test automatizzati che confermano che il codice funziona e fa quello che dovrebbe fare altrimenti la user story non può essere considerata come fatta.

Il principale cambiamento mentale è con il QA. Molti sviluppatori pensano che il QA sia lì per convalidare il funzionamento del codice e fa quello che dovrebbe fare. Assolutamente no. Questo è un lavoro da sviluppatore.

Il QA dovrebbe partecipare allo sviluppo del prodotto. La loro principale responsabilità nello sprint dovrebbe essere la comunicazione con il proprietario del prodotto e la creazione di test di accettazione automatizzati per i criteri di accettazione (definizione del fatto) che confermeranno che la storia dell'utente è realmente fatta e l'applicazione supera tutti i nuovi requisiti. Nei piccoli team ciò può essere responsabilità anche degli sviluppatori.

Il QA dovrebbe anche eseguire alcuni test manuali per mantenere la coerenza del prodotto e scoprire funzionalità mancanti, convalidare l'esperienza utente con l'interfaccia utente, ecc. Il QA non è lì per cercare bug e test di regressione - i test di regressione dovrebbero essere altamente automatizzati.

Nella mia esperienza, è qui che la maggior parte delle aziende che si spostano verso l'agile falliscono.

— Ladislav Mrnka
fonte

"No. La revisione e il test del codice fanno parte dello sprint." - fico, è quello che stavo chiedendo. :)

— Steve Bennett il

2

Penso che " deve includere una sorta di test automatizzato" è un po 'forte. Non c'è nulla che dica che i test devono essere automatizzati. In effetti, in alcuni casi è chiaramente impossibile. Potresti sviluppare un nuovo foglio di stile e il "test" deve essere un'ispezione visiva. Non è possibile automatizzare "sembra giusto?". Sì, i test dovrebbero essere automatizzati se possibile, ma dire che devono esagerare un po '.

— Bryan Oakley,

@BryanOakley: sono d'accordo. Ho indirizzato quella parte della mia risposta solo a un sottoinsieme di attività di sviluppo in cui sono possibili test automatici.

— Ladislav Mrnka,

1

Questo non riesce a rispondere alla domanda.

— Edward Anderson,

8

Dalla mia esperienza, non c'è tempo tra gli sprint, tranne il fine settimana. Verso la metà dello sprint, i team con cui sono stato membro del lavoro con il proprietario del prodotto per fare un po 'di preparazione della storia o valutazioni preliminari in base ai requisiti. È responsabilità del proprietario del prodotto mantenere pieno l'arretrato: queste storie sono ciò su cui il team lavorerà, con alcuni suggerimenti del proprietario del prodotto in merito alle priorità. Una volta terminato lo sprint corrente, inizierà lo sprint successivo, utilizzando il lavoro svolto per preparare storie e attività per lo sprint successivo.

C'è un certo sovraccarico (molte riunioni, domande e risposte e valutazioni dei requisiti), ma nel complesso funziona: facciamo progressi costanti con tempi di inattività ridotti. Gli sprint di solito sono durati due o tre settimane. Il QA di solito avviene una volta completate le storie. Tuttavia, il team addetto al controllo qualità potrebbe avere altre attività che può svolgere. Per quanto riguarda la preparazione delle storie, i compiti possono essere affidati a membri senior del team o all'intero team. Può variare a seconda delle dimensioni della squadra e del processo concordato. Le revisioni del codice di solito avvengono quando si verifica il QA o alla fine dello sprint se il tempo è compresso. E se non c'è abbastanza tempo per finire le storie, in pratica queste storie vengono spinte al prossimo sprint. Il dimensionamento e la stima corretti sono molto importanti qui.

— JW8
fonte

Ok, quindi il tuo QA si svolge all'interno dello sprint. Quando si verifica la distribuzione? Aspetti che tutti gli sviluppatori abbiano eseguito il QA di tutto il loro lavoro, quindi una persona dispiegherà?

— Steve Bennett,

Di solito abbiamo almeno due schieramenti: uno a metà dello sprint e un altro alla fine. Altre possono essere distribuite al QA man mano che le storie vengono completate. Avere storie più brevi che possono resistere da sole aiuta molto. Le storie più grandi di solito sono divise in più piccole. Le storie tecniche necessarie per far funzionare le cose di solito sono approvate dal responsabile / responsabile dello sviluppo - il controllo qualità non viene coinvolto a meno che non ci sia un output che può essere testato (registri, schermate utente o altro output).

— JW8,

0

... e quando è la stima? pianificazione?

Le storie dovrebbero essere davvero facili da non avere tempo tra gli sprint.

E non so di che tipo di test stai parlando, ma gli sviluppatori faranno test di unità e integrazioni, niente di più.

Stavo lavorando in un progetto a volte 2 o 3 giorni tra gli sprint e mi sembra giusto. Ora sto lavorando a un progetto in cui non c'è tempo ed è tutto sfocato. L'ultima volta dello sprint è stato distribuito in produzione e questo richiede un po 'di tempo del mio ultimo giorno di sprint.

— Zurdo
fonte

Nella vera mischia, gli sviluppatori in genere non scrivono test di accettazione, ma possono e dovrebbero di volta in volta. La qualità è la responsabilità di tutto il team. Anche se ci sono (speriamo!) Specialisti dei test, gli sviluppatori dovrebbero presentarsi un po '. Dire che non fanno "niente di più" dei test unitari e di integrazione non è vero SCRUM.

— Bryan Oakley,