Scrum: arretrati e attività del prodotto

2

Recentemente ho letto il libro, Scrum Scorciatoie senza angoli di taglio di Ilan Goldstein. Goldstein menziona che quando si pratica la mischia, si scrivono storie di utenti e si scriverà un compito per quelle storie di utenti che verrebbero quindi assegnate a un individuo. Il problema è che quando sono entrato nel libro, Goldstein afferma che i compiti di scrittura sono fatti in un modo specifico. Dà il seguente esempio:

User Story

"Come nuovo utente, vorrei iscrivermi al sito Web XYZ per poter iniziare a utilizzare i suoi fantastici servizi"

Attività 1: progettare test funzionali end-to-end.
Attività 2: generare dati di test.
Attività 3: sviluppo del livello del database.
Attività 4: sviluppo del livello della logica aziendale.
Attività 5: sviluppare il livello dell'interfaccia utente.
Attività 6: sviluppo del test di automazione funzionale end-to-end.

Continua dicendo che questo è logico e diretto ed è come sto facendo le cose ora ma è più un modello di sviluppo a cascata che vogliamo evitare perché è meno efficiente quando si vuole essere agili.

Ciò che preferisce è questo:

User Story

"Come nuovo utente, vorrei iscrivermi al sito Web XYZ per poter iniziare a utilizzare i suoi fantastici servizi"

Attività 1: sviluppo della funzionalità di nome utente / password (compresa progettazione e automazione del test)
Attività 2: sviluppare la funzionalità di autenticazione della posta elettronica (compresa la progettazione e l'automazione del test)
Attività 3: sviluppare la funzionalità della pagina di destinazione (compresa la progettazione e l'automazione del test)

Egli menziona che piuttosto che una cascata, abbiamo più di un breve filo. E 'grandioso ma mi sta allontanando un po'. In una squadra per il mio progetto, avrò persone diverse che lavorano su API, front-end e design. Pertanto, per le attività sopra riportate, sembra che tutti e tre i membri del team lavoreranno su una sola attività quando un solo membro dovrebbe essere assegnato a un'attività.

Sono solo molto confuso su questo. La mia squadra è un caso speciale perché ognuno di noi è specializzato piuttosto che essere un programmatore generale? Esiste un modo diverso per scrivere le attività in modo che si riferiscano a un solo membro del mio team? Dovremo lavorare con lo sviluppo della cascata piuttosto che il risultato incapsulato di ciò che può essere? Voglio essere il più agile possibile ma sembra che mi stia imbattendo nei muri. Qualsiasi direzione / aiuto / soluzione sarebbe grandiosa.

    
posta Nick Rucci 23.06.2016 - 21:46
fonte

1 risposta

1

L'obiettivo della mischia è quello di consentire al team di essere auto-diretto. Non esiste un modo universale per scrivere storie e compiti. L'obiettivo è che il team lavori insieme per portare a termine un compito.

Quando scrivi una storia e diventa parte dello sprint, la tua squadra ha bisogno di lavorare insieme per far sì che la storia avvenga. Il primo passo è una sessione di pianificazione in cui si suddividono le storie in attività. Ogni storia è diversa, così come lo è ogni sprint, non esiste una strategia adatta a tutti per le attività.

Poiché è il team che deve svolgere il lavoro, le attività che sviluppi devono funzionare per il tuo team. Ciò potrebbe significare che la strategia che impieghi deriva direttamente da un libro, o se sei una squadra matura significa che lo fai esattamente come vuoi con totale disprezzo per tutti i libri. In realtà, la maggior parte delle squadre cade da qualche parte nel mezzo. In questo caso, i libri forniscono un buon punto di partenza se non sai da dove iniziare.

Nessun libro conosce il tuo prodotto, le tue storie, il tuo team o il tuo ambiente di lavoro. L'obiettivo è collaborare per creare un ottimo software. Dovrai capire cosa funziona meglio per te.

Se hai appena iniziato, fallo dal libro per uno sprint . Forse due. Fai le tue retrospettive e prendile sul serio. Scopri quali parti di ciò che hai provato ha funzionato e quali parti non hanno funzionato così bene. Se si scopre che hai scelto il libro sbagliato, devi affrontarlo solo per uno sprint. Impara, schiocca, risciacqua, ripeti.

Alla fine della giornata, hai una stanza piena di (fiduciosamente!) persone intelligenti e motivate. Tutto quello che devi fare è rispondere alla domanda "In che modo noi forniremo questa storia alla fine dello sprint?" . Dimentica tutti i rituali, i consigli e le metodologie e focalizza il tuo team su due aspetti: distribuire il software e migliorare il modo in cui il software viene consegnato ogni volta che si esegue lo sprint.

    
risposta data 23.06.2016 - 23:01
fonte

Leggi altre domande sui tag