Cosa fare se un membro del team perde una pianificazione dello sprint?

Diciamo che un membro del team è in ferie annuali. Non parteciperà alla pianificazione dello sprint ma tornerà entro la metà dell'iterazione / sprint. Supponiamo che abbia una capacità del 50%, ad esempio poiché sarà disponibile per la metà successiva dell'iterazione, se dovessimo:

1. avere una sessione di pianificazione con lui dopo che è tornato.

2. avere una sessione di pianificazione con lui prima che vada in ferie annuali, cioè prima della pianificazione dello sprint.

3. non programmarlo per nessuna attività e assegnarlo a attività non sprint, ad esempio picchi, ecc

4. avere il piano dei suoi colleghi per suo conto durante la pianificazione dello sprint e una persona assente può quindi aggiungere compiti quando è tornato e se non può fare tutto il lavoro che può decifrare.

5. farlo sedere con un altro sviluppatore e accoppiare la programmazione per un po '.

6. qualunque altra cosa..

sono interessato a sapere cosa stai facendo ..

Nota: stiamo facendo (1) e non sembra giusto.

La pianificazione riguarda l'impegno e la suddivisione delle storie degli utenti impegnate in attività.

avere una sessione di pianificazione con lui dopo che è tornato.

Assolutamente no. La pianificazione della sessione dopo il suo ritorno non ha senso perché l'impegno deve essere già stato fatto.

avere una sessione di pianificazione con lui prima che vada in ferie annuali, cioè prima della pianificazione dello sprint.

Assolutamente no. Non ci dovrebbe essere alcuna pianificazione quando lo sprint corrente non è completato = il risultato dello sprint corrente non è noto e nessuno sa se tutte le storie degli utenti saranno completate e il cliente sarà soddisfatto con la recensione.

non programmarlo per nessuna attività e assegnarlo a attività non sprint, ad esempio picchi, ecc

Assolutamente no. Tornerà e la sua capacità dovrebbe essere usata come bersaglio dello sprint.

avere il piano dei suoi colleghi per suo conto durante la pianificazione dello sprint e una persona assente può quindi aggiungere compiti quando è tornato e se non può fare tutto il lavoro che può decifrare.

Questo è corretto. Il team si impegna, non un particolare membro del team. Il team si impegna a mettere insieme le storie degli utenti perché conoscono la loro velocità e in base alla loro ipotesi professionale possono modificare l'impegno per il prossimo sprint in base alla capacità disponibile. Non dovrebbero essere assegnate attività al singolo sviluppatore in anticipo. Gli sviluppatori dovrebbero essere interfunzionali anche se non è sempre possibile, dovrebbero comunque essere in grado di dividere almeno la storia dell'utente in attività. Ci possono essere problemi con la stima delle attività, ma secondo me non è affatto necessario.

farlo sedere con un altro sviluppatore e accoppiare la programmazione per un po '.

Assolutamente no. La programmazione delle coppie dovrebbe essere coperta dalla velocità stessa. Se non conti con lo sviluppatore, è come dire che sarà via per tutto lo sprint. Perché il cliente dovrebbe pagare il tempo dello sviluppatore che non ha fatto nulla durante lo sprint?

In un ideale agile i membri del team sono a proprio agio con tutte le tecnologie utilizzate in un progetto e qualsiasi attività può essere eseguita da (quasi) qualsiasi membro di un team. In tal caso, dopo aver ridimensionato le attività nel backlog, dopo aver definito l'iterazione e i membri del team che hanno scelto la prima serie di attività dal backlog, è possibile lasciare il resto delle attività nel secchio e verranno raccolte dal team membri incluso quello che ha perso la sessione di pianificazione.

In un'altra situazione comune i membri del team sono specializzati (uno è un utente dell'interfaccia utente, un altro è un esperto di database, il terzo è un guru del middleware, ecc.) In tal caso il membro del team mancante verrebbe assegnato i suoi compiti in assenza. Potrebbe aver bisogno di ridimensionarli dopo essere salito a bordo.

In un team in cui "scrum" sta lavorando, il team stesso prenderà in giro il gioco e troverà una soluzione creativa. Questa situazione non si presenta abbastanza spesso da giustificare la descrizione di casi speciali, basta "seguire il flusso" per il resto dello sprint. Dopotutto, questi sprint non sono comunque molto lunghi.

Le vacanze, se pianificate / non pianificate, sono solo una parte del gioco. @Asim Ghaffar, i metodi suggeriti - almeno la maggior parte di loro sembrano, criminalizzare una persona che si è astenuta dall'incontro di pianificazione dello sprint. In una squadra che ha un sano rispetto reciproco capirà i bisogni personali di una persona e in tali squadre c'è una buona fiducia sul tipo di lavoro che svolge. È con questa fiducia che pianificano ciò che possono fare, considerando il momento in cui diverse persone sarebbero fuori dal lavoro per una particolare iterazione / sprint.

Sono i tempi difficili a dire quanto sia professionale una squadra. In un team di medie dimensioni, nella nostra azienda c'è sempre una persona che perde la riunione di pianificazione dello sprint. Non lo criminalizziamo. Crediamo che sia abbastanza maturo per prendere la sua decisione :)

Apprezzo la tua domanda fintanto che hai sete di apprendere e apprezzare lo spirito della metodologia Agile per lo sviluppo del software.

Dove lavoro, 4 sarebbe la soluzione comune presa. Le persone che mancano alla riunione possono essere in vacanza, ammalate o avere qualcos'altro che deve essere fatto invece per alcuni casi in cui solo perché manca qualcuno non significa che lo sprint non debba continuare. L'idea qui è che il team riconosca quali tipi di aggiustamenti possono essere fatti se qualcuno è in trasferta per metà di uno sprint anche se alla fine potrebbero esserci più di alcuni aggiustamenti.

Le persone tendono sempre ad avere una vacanza :-) nessun danno fatto.

In un gruppo agile se qualcuno ha bisogno di ferie se l'agile funziona correttamente una persona scomparsa non dovrebbe fare molta differenza, sì, il gruppo può fare meno del normale, ma significa solo fare meno funzioni in quella iterazione.