Cosa succede tra gli sprint?

I'm working on a project loosely following the scrum model.

Per essere chiari: probabilmente i tuoi manager ti hanno parlato di Scrum, ma quello che esegui non è Scrum.

How long does this typically take?

Riunione di valutazione Sprint + La riunione retrospettiva Sprint termina lo sprint corrente. In brevi 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 lunghezza dello sprint, queste riunioni possono richiedere da 2 a 4 ore.

Should the whole team be involved?

Tutta la squadra deve essere coinvolta in riunioni menzionate nella risposta precedente.

Does it strictly have to finish before developers start working on the next sprint items?

Sì, perché fino a quando la riunione di revisione non viene completata, non si sa se il cliente accetta il risultato dello sprint precedente e non si sa quali saranno le storie degli utenti impegnate nella pianificazione delle riunioni.

Is this when code review and testing take place?

No. La revisione e il test del codice fanno parte dello sprint. Gli sviluppatori devono fare tutto il necessario per soddisfare i requisiti soddisfacenti del codice di lavoro. Questo può includere revisioni di codice e deve sempre includere una sorta di test automatici che convalidano il funzionamento di quel codice e fa ciò che si suppone faccia altrimenti la user story non può essere considerata come fatta.

Il principale spostamento mentale è con il controllo qualità. Molti sviluppatori pensano che il QA sia lì per convalidare quel codice funziona e fa quello che dovrebbe fare. Assolutamente no. Questo è il lavoro degli sviluppatori.

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

Il QA dovrebbe anche eseguire alcuni test manuali per mantenere coerente il 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 fallisce la maggior parte delle aziende che si spostano verso l'agile.

Dalla mia esperienza, non c'è tempo tra gli sprint, a parte il weekend. Verso la metà dello sprint, le squadre con cui ho collaborato con il proprietario del prodotto sono state in grado di eseguire alcune operazioni di preparazione delle storie o di test preliminari in base ai requisiti. È responsabilità del proprietario del prodotto mantenere completo il backlog - quelle storie sono le attività su cui il team lavorerà, con qualche input da parte del proprietario del prodotto in merito alle priorità. Una volta terminato lo sprint attuale, inizierà lo sprint successivo, utilizzando il lavoro che abbiamo svolto per preparare storie e attività per il prossimo sprint.

C'è un sovraccarico (un sacco di riunioni, Q & A e valutazioni dei requisiti), ma nel complesso funziona - facciamo progressi costanti con poco tempo morto. Gli sprint di solito sono durati due o tre settimane. Il QA di solito ha luogo una volta completate le storie. Tuttavia, il team addetto al controllo qualità potrebbe avere altre attività che possono svolgere. Per quanto riguarda la gestione delle storie, le attività possono essere affidate ai membri senior della squadra o all'intera squadra. Può variare a seconda delle dimensioni della squadra e del processo concordato. Le revisioni del codice avvengono di solito mentre 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. Dimensionamento e stima corretti sono molto importanti qui.

... e quando è la stima? pianificazione?

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

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

Lavoravo in un progetto con a volte 2 o 3 giorni tra gli sprint e mi sembra giusto. Ora sto lavorando a un progetto in cui non c'è tempo e tutto è confuso. L'ultima volta dello sprint abbiamo la distribuzione della produzione e questo richiede un po 'di tempo per il mio ultimo sprint day.