Processi in Scrum

Pianificazione dello sprint

La pianificazione dello sprint è la fase iniziale dello sprint di Scrum. Determina l'ambito e le modalità di lavoro durante lo sprint. L'intero team Scrum è coinvolto nella pianificazione.

Uno sprint è un periodo di tempo chiaramente definito durante il quale deve essere completata una specifica parte di lavoro. Uno sprint deve essere pianificato prima di iniziare. Prima di tutto, devi determinare la durata e l'obiettivo dello sprint.

Al workshop di pianificazione vengono concordati l'elenco delle attività e l'obiettivo dello sprint. È importante caricare il team con la giusta motivazione al lavoro, in modo che ogni membro sia concentrato sul successo.

Se lo sprint è mal pianificato, questo può portare la squadra al fallimento. Gli sviluppatori non saranno in grado di far fronte alle aspettative riposte su di loro, perché i compiti si sono rivelati irrealistici.

Domande da considerare quando si pianifica uno sprint:

• Il cliente o il proprietario del software annuncia l'obiettivo dello sprint, spiegando lungo il percorso come raggiungerlo. Il team Scrum scopre quali attività possono essere completate in uno sprint futuro per raggiungere questo obiettivo.
• Gli sviluppatori distribuiscono tra loro un piano di lavoro, concordato con il cliente del software.
• Il cliente (proprietario) del prodotto partecipa sempre alla stesura dello sprint plan. Stabilisce un obiettivo e il team di programmazione deve scoprire se può essere raggiunto in uno sprint.
• Il piano dovrebbe utilizzare un backlog di prodotto, le cui informazioni possono essere aggiunte al piano.
• I membri del team dovrebbero terminare la riunione di pianificazione con una chiara comprensione di ciò di cui hanno bisogno per raggiungere il risultato. È possibile visualizzare l'ordine delle azioni future nello sprint backlog.

La pianificazione non dovrebbe superare le due ore settimanali. Lo Scrum Master deve spiegare a tutti che ci sono limiti di tempo. Se tutti i problemi di lavoro vengono risolti rapidamente, la riunione può terminare prima del solito. Non esiste una durata minima per tale riunione.

Valutazione del compito

Valutare la complessità del lavoro non ha bisogno di esagerare. Il processo di pianificazione non richiede una valutazione esatta, ma almeno approssimativa della complessità dello sviluppo. La squadra non deve solo capire l'obiettivo dello sprint, ma anche confrontare l'obiettivo con le capacità della propria squadra.

Per valutare la complessità, puoi utilizzare le solite taglie di abbigliamento per tutti (L, XL, XXL). Naturalmente, questo non garantisce l'accuratezza, ma comunque.

Affinché la valutazione della complessità sia più accurata, è necessaria la comprensione reciproca. I membri del team dovrebbero condividere apertamente le loro opinioni e non aver paura di porre domande al proprietario del prodotto.

Le critiche nei confronti del team dopo il completamento del lavoro possono portare al fatto che quando si pianifica il prossimo sprint le previsioni saranno meno ottimistiche. Ciò aiuterà il team a evitare di ripetere l'errore e a proteggerlo da valutazioni negative in futuro.

Valutazione della difficoltà in punti, punti e ore

In genere, i team di sviluppo stimano la complessità del loro lavoro nel tempo. Ma alcuni team Agile scelgono di valutare la difficoltà in punti o punti. Questa è una migliore indicazione del costo totale richiesto per implementare un elemento del backlog o un'altra attività assegnata.

I punti vengono assegnati in base alla complessità e al volume del lavoro. Inoltre, vengono presi in considerazione i possibili rischi. Il punteggio con questo metodo aiuta a suddividere efficacemente il lavoro in piccoli passaggi.

Utilizzando regolarmente il metodo di punteggio (punti) durante la pianificazione, i team hanno una comprensione migliore e più accurata di quanto tempo avranno bisogno per completare il lavoro. Inoltre, ci sono anche altri vantaggi.

• La stima del tempo non tiene conto del lavoro che non è direttamente correlato al progetto, anche se apparirà sicuramente. Discutere problemi di lavoro tramite un messenger, tenere riunioni: tutto ciò richiede tempo anche per i membri del team.
• Le emozioni possono influenzare la scelta delle date. Il punteggio durante la valutazione del lavoro elimina questo fattore.
• La valutazione della complessità del lavoro e, di conseguenza, la velocità di completamento delle attività può essere diversa per ciascuna delle squadre. Il lavoro con i punti realizzati non può essere considerato un indicatore di velocità. Cioè, non c'è pressione psicologica sulla squadra.
• Distribuendo correttamente i costi e la complessità del lavoro, è possibile dividere rapidamente e senza conflitti i punti per il lavoro svolto tra i partecipanti.
• Il numero di punti ricevuti per il completamento di un'attività dipende dalla sua complessità e non dal tempo impiegato. Pertanto, i programmatori penseranno a migliorare la loro efficienza e non a quanto tempo ci vorrà.

Lo svantaggio della stima della complessità è che spesso viene utilizzata in modo improprio. Ad esempio, questo metodo non può essere utilizzato per valutare i dipendenti.

I team dovrebbero utilizzare un sistema di punteggio per comprendere meglio la quantità di lavoro loro assegnato e stabilire correttamente le priorità.

Riunione giornaliera di Scrum

I workshop sono importanti: in essi i membri del team condividono le loro opinioni, comunicano e concordano ulteriori azioni. Le riunioni quotidiane di mischia sono necessarie anche per aumentare lo spirito di squadra e annunciare le notizie attuali.

Lo stand-up è un breve incontro dei partecipanti chiave al progetto: il proprietario del software, i programmatori e lo scrum master. La struttura dello stand-up consiste in tre domande.

• Cosa siamo riusciti a fare ieri?
• A cosa stiamo lavorando oggi?
• Cosa ci impedisce di ottenere risultati?

Porre queste domande stimola lo sviluppo e aiuta a identificare i problemi all'interno del team. Quando ogni partecipante comunica come aiuta a raggiungere un obiettivo comune, ciò migliora la comprensione reciproca all'interno del team.

È importante ricordare che non esiste un unico modello su come condurre gli stand-up. Ogni squadra tiene le riunioni secondo un proprio modello, in base alle caratteristiche della squadra.

E ora discutiamo di ciò che è necessario per il perfetto stand-up e facciamo conoscenza con esempi di stand-up efficaci.

Per prima cosa devi scegliere un orario adatto a tutti. Di solito gli stand-up per le squadre dello stesso ufficio si tengono all'inizio della giornata lavorativa, tra le 9 e le 10 del mattino. Questo ti dà il tempo di pianificare meglio il tuo programma per la giornata. Se i membri del team lavorano in regioni diverse, viene scelto un orario adatto a tutti. Ad esempio, se alcuni membri del team vivono in California e Sydney, lo stand-up inizia alle 15:30 ora della California. Certo, stare in piedi dopo cena non è conveniente per tutti, ma permette di tenersi in contatto con i colleghi dall'altra parte dell'oceano.

Tieni traccia della produttività in piedi. Non tenere la riunione troppo a lungo: la concentrazione dell'attenzione dovrebbe rimanere al meglio. Se possibile, mantieni gli stand-up per non più di 15 minuti.

Usa la palla. Può essere lanciato l'un l'altro a turno. Quindi tutti saranno coinvolti nella discussione. Questo gioco aiuta a mantenere l'attenzione nel gruppo. Usa la retrospettiva del team. Gli stand-up sono utilizzati in molte metodologie Agile, questo non ci impedisce di discutere l'efficacia degli stand-up nelle retrospettive. Qualcuno si incontra ogni giorno, altre squadre un paio di volte a settimana. Se è difficile per la squadra trarre vantaggio dallo stand-up, trova le ragioni per questo e cambia qualcosa.

Recensione Sprint

La revisione primaverile viene eseguita nella fase finale dello sprint. È necessario controllare l'incremento del prodotto e adattare il backlog. L'intero team di scrum e tutti gli stakeholder partecipano alla revisione dei risultati dello sprint. L'incontro si svolge in un formato rilassato per migliorare l'interazione dei partecipanti al progetto.

La Sprint Results Review include i seguenti elementi:

• Il proprietario del software mostra cosa del backlog è stato completato e cosa no.
• I programmatori discutono su cosa è andato bene, dove sono apparse le difficoltà e come sono state eliminate.
• Il team di sviluppo mostra i risultati del proprio lavoro durante lo sprint e quale incremento di prodotto ha ricevuto.
• Il Product Owner condivide i suoi pensieri sull'attuale arretrato. Fornisce inoltre una previsione per il prossimo obiettivo e la scadenza per la sua attuazione.
• Tutti discutono su cosa è meglio fare dopo in base alla valutazione del mercato e agli interessi degli utenti.
• È in corso uno scambio di opinioni sui tempi, sul budget e sulle prospettive di aumento dell'arretrato.

Il risultato è un backlog aggiornato con nuovi obiettivi per gli sprint successivi. L'arretrato può essere modificato se la situazione lo richiede.

Retrospettiva Sprint

La Sprint Retrospective è un workshop che discute su come migliorare il tuo flusso di lavoro. Crea anche un piano di miglioramento per il prossimo sprint. L'incontro di solito si svolge dopo lo sprint review e non dura più di tre ore. A guidare la riunione è lo Scrum Master.

Gli obiettivi principali della Sprint Retrospective includono:

• Sprint analysis (lavoro dei partecipanti, risultati e problemi).
• Discutere le possibili soluzioni per migliorare il flusso di lavoro negli sprint successivi.
• Creazione di un piano per l'implementazione dei miglioramenti da parte dei membri del team durante l'implementazione del progetto.

Lo Scrum Master invita i membri del team a dare suggerimenti su come migliorare l'efficienza dello sviluppo. Il team discute le proposte e suggerisce alcuni modi e tecniche per la loro attuazione.

Alla fine della Sprint Retrospective, il team dovrebbe evidenziare alcuni suggerimenti di miglioramento da implementare nello sprint successivo. I suggerimenti possono essere implementati in qualsiasi momento, ma Sprint Retrospective offre l'opportunità di dare uno sguardo più approfondito al loro possibile adattamento dal punto di vista del team.

Qui è dove terminiamo la nostra discussione sulla metodologia Scrum. Puoi saperne di più nella documentazione tematica o nel tuo primo posto di lavoro.