Pianificazione attività su una squadra agile

Il nostro team in effetti fa entrambe le cose, a seconda della storia dell'utente. Bene, in realtà eseguiamo ancora un grosso compito chiamato "Risolvi" o qualcosa del genere, quindi il grafico di burndown funzionerà ancora sul nostro strumento.

La differenza per noi è quanto sia facile prevedere i compiti in anticipo. Ad esempio, facciamo software incorporato e ogni volta che abbiamo una nuova scheda per l'avvio è molto difficile predire le singole parti, ma per esperienza sappiamo quanto tempo ci vuole normalmente per tutto insieme. Una volta gli orologi potrebbero essere perfetti, ma alcuni power rail sono instabili, la prossima volta potrebbe essere il contrario.

Inoltre, alcuni team suddividono le loro storie utente in parti più piccole di altre. Il nostro team ha una media di circa 12 per sprint. Altre squadre nella mia compagnia sono in media 3 o 4 per sprint. Più piccole sono le tue storie, meno hai bisogno di compiti.

Si riduce a scegliere ciò che funziona meglio per lo stile della tua squadra individuale. Se non puoi immaginare di lavorare senza compiti, questo non dovrebbe farti sentire inferiore. D'altra parte, se ritieni che i compiti siano un ostacolo, dovresti sentirti libero di scartarli.

Ho lavorato a una cosa del "grande quadro" con una squadra Agile prima: lavoro magnificamente. Abbiamo dedicato tutto il nostro tempo al lavoro, piuttosto che alla pianificazione del processo, alla creazione di attività e all'organizzazione del progetto.

Dovresti provarlo, è incredibile quello che puoi fare quando ti allontani dai processi proibiti.

Naturalmente, dipende da te - se hai bisogno di compiti per renderti produttivo, continua a farlo. Se non hai bisogno di compiti per essere produttivi, eliminali immediatamente. Non è questo lo spirito di Agile ?

Dipende tutto da come il team vuole gestire il suo tempo e consumare storie, e quanto bene funzioni per lo Scrum Master e altri membri dello staff di gestione che si occupano delle metriche.

La ripartizione delle attività è un buon modo per un team di verificare la complessità stimata originaria della storia (di solito stimata in una "riunione di pianificazione fondamentale" data solo una visione di alto livello delle funzionalità richieste) e di pianificare la divisione del lavoro basata sui vari "percorsi critici" attraverso le storie dello sprint backlog. Rompendo le storie in attività, puoi vedere i tuoi progressi di giorno in giorno su un grafico di burndown, senza dover registrare le ore effettive spese e le ore stimate che rimangono su ogni storia; quando l'attività è terminata, le ore stimate sono al di sopra della media e i risultati sono gli stessi che gli sviluppatori inserivano costantemente nel tempo stimato rimanente (e chi lo vuole fare tutto il giorno?).

È utile al punto di necessità in due situazioni comuni:

• La metrica "ore per punto" del tuo team è maggiore di quella di un giorno dello sviluppatore. Se uno sviluppatore segnalasse regolarmente che stanno lavorando sulla stessa storia per due o più standup, quindi per avere un'idea del progresso di giorno in giorno attraverso lo sprint, è virtualmente un requisito per descrivere quel progresso in termini di pezzi più piccoli di la storia più grande (proprio come la maggior parte di tutto in Agile è descritta), cioè i compiti. Altrimenti, se a uno sviluppatore è stata assegnata una storia che gli richiederà l'intera iterazione da completare, il valore dei punti della sua storia rimane lì nel burn-down fino all'ultimo giorno, quando fa o interrompe lo sprint.

• Due o più sviluppatori lavoreranno alla storia. Se due sviluppatori devono dividere il lavoro, è fondamentale che suddividano il lavoro in blocchi da condividere tra loro, per evitare che entrambi facciano lo stesso lavoro o nessuno dei due faccia qualcosa di importante.

Ora, se la natura delle storie che la tua squadra porta regolarmente in uno sprint è tale che uno sviluppatore potrebbe completare almeno una volta al giorno, allora quella base per un "puntatore unico" significa che un burndown basato su punti rende più senso, e la ripartizione dei compiti è meno preoccupante. Le tue storie sono già "di dimensioni ridotte", sia effettuando una scomposizione della storia di lavori più grandi o semplicemente perché sei in "modalità di manutenzione" e sono richieste solo piccole modifiche incrementali, in modo tale che anche se si segnalano solo storie completate, il burndown rifletterà in modo accurato il lavoro rimanente.