Lavorare con Scrum

Storia dell'utente

Le storie degli utenti sono un modo efficace per dichiarare i requisiti per il software in fase di sviluppo. Tali storie contengono brevi consigli per conto dell'utente del software.

Poiché nella metodologia Scrum, la definizione degli obiettivi è solitamente prerogativa del cliente o del proprietario del software, sono considerati il ​​​​modo principale per influenzare il processo di sviluppo. Ogni User Story ha un limite nella quantità di testo e nella complessità della presentazione. La storia è spesso scritta su un piccolo foglio, che di per sé limita il volume.

Grazie alle storie degli utenti, puoi documentare i desideri del cliente e rispondere rapidamente alle richieste del mercato.

La User Story dovrebbe essere considerata una misura semplicistica dei requisiti perché non include una procedura di test di accettazione. La compilazione della user story deve rispettare la procedura di ammissione. Ciò assicurerà che la User Story raggiunga il suo obiettivo.

La struttura della storia è simile a questa: "Come utente <tipo utente>, voglio eseguire <azione> per ottenere <risultato>" (Come proprietario del prodotto voglio...). Una tale struttura non è solo semplice, ma anche comprensibile a tutti.

Vantaggi dell'utilizzo delle User Story:

• Le storie sono piccole e facili da creare.
• Aiutare tutte le parti interessate a discutere il lavoro sul progetto e il suo supporto.
• Non richiedono una manutenzione costante.
• Rilevante solo se utilizzato.
• Migliorare l'interazione con il cliente.
• Grazie a loro, puoi dividere il progetto in piccole fasi.
• Facilitare il lavoro su progetti con requisiti poco conosciuti.
• Semplifica la valutazione delle attività.

Svantaggi delle User Story:

• Senza previo accordo, le procedure possono rendere difficile l'utilizzo come base per un accordo.
• Il loro utilizzo richiede uno stretto contatto con il cliente durante l'intero progetto, il che a volte rende difficile il flusso di lavoro.
• Presentano degli svantaggi durante il ridimensionamento su progetti di grandi dimensioni.
• Direttamente correlato al livello professionale degli sviluppatori.
• Utilizzato per avviare una discussione, ma potrebbe non terminare una discussione e non viene utilizzato per la documentazione del sistema.

Arretrato

Il product backlog è costituito dalle attività correnti sotto forma di un elenco, compilato in ordine di priorità. L'elenco è formato sulla base della tabella di marcia (roadmap) del progetto e dei punti in essa indicati. Le attività più importanti sono solitamente in cima all'elenco. Questo è necessario per capire quale lavoro dovrebbe essere fatto per primo.

Il team di sviluppo sceglie la velocità di completamento delle attività arretrate indipendentemente dai desideri del cliente, ma in base alle proprie qualifiche ed esperienza degli sprint precedenti. È estremamente indesiderabile "regolare" i programmatori. Il team stesso sceglie le attività dal backlog in base alle proprie considerazioni e capacità. L'esecuzione avviene senza interruzioni (Kanban) o diverse iterazioni (Scrum).

Due importanti condizioni di arretrato

Il nucleo di un product backlog consiste in una roadmap, proposte e condizioni di esecuzione. Le Epic contengono condizioni e User Story. Diamo un'occhiata da vicino a un tipico esempio di tabella di marcia.

La creazione del sito Web "Teams in Space" è la prima proposta della tabella di marcia. Deve essere suddiviso in epic (nella figura sono mostrati nei colori verde, blu e turchese) e una User Story per ogni epic.

Il cliente del software forma un elenco da diverse User Story. Se necessario, può modificare l'ordine in cui vengono eseguite le storie, in modo che gli sviluppatori si occupino prima di una delle epopee più importanti (a sinistra) o verifichino come funziona la prenotazione dei biglietti scontati. Per fare ciò, è necessario implementare storie di epiche (a destra). Entrambe le opzioni possono essere visualizzate di seguito.

Sulla base di quali fattori il cliente dovrebbe dare la priorità?

• Rilevanza per gli utenti.
• La presenza di feedback.
• Complessità di sviluppo.
• La relazione tra le attività (per completare "B", devi prima fare "A").

Le priorità nel lavoro sono determinate dal cliente, ma altre parti possono esprimere la loro opinione al riguardo. Il successo del backlog dipende, tra l'altro, dalle opinioni di clienti e programmatori. Insieme, possono ottenere risultati migliori e garantire la consegna tempestiva del prodotto finito.

Come mantenere un arretrato

Se l'arretrato è già stato creato, dopodiché è necessario modificarlo periodicamente nel corso di ulteriori lavori. Il cliente del software deve assicurarsi che il backlog sia compilato correttamente prima di pianificare ogni nuova iterazione. Questo aiuterà a chiarire le priorità oa cambiare qualcosa dopo l'analisi dell'ultima iterazione. La regolazione del backlog in Agile è talvolta chiamata "grooming" o "perfezionamento" o "manutenzione del backlog".

Se il backlog è già relativamente ampio, il cliente deve raggruppare le attività in base all'esecuzione a breve ea lungo termine. Gli incarichi a breve termine dovrebbero essere esaminati attentamente prima che venga assegnato loro questo status. Dovrai comporre una User Story, scoprire tutte le sfumature all'interno del team.

Per quanto riguarda le attività a lungo termine, è altamente auspicabile che gli sviluppatori diano loro la loro valutazione. In questo modo sarà più facile stabilire le priorità. Forse qualcosa cambierà, ma il team migliorerà la comprensione dei compiti e porterà a termine il lavoro più velocemente.

Il backlog è una componente importante tra il cliente e il team di programmazione. Il cliente può sempre modificare le priorità in base al feedback, alle previsioni o ai nuovi requisiti del cliente.

Si raccomanda di evitare di apportare modifiche direttamente durante il funzionamento. Ciò ha un effetto negativo sul flusso di lavoro e sullo stato emotivo dei programmatori.

Sprint

Uno sprint è un breve periodo durante il quale deve essere completata una quantità di lavoro precedentemente concordata. Gli Sprint si basano sulle metodologie Scrum e Agile. La scelta degli sprint giusti aiuta un team agile a sviluppare software di qualità.

“Utilizzando Scrum, puoi sviluppare un prodotto in diverse iterazioni con una durata chiara: gli sprint. Aiuta a suddividere i progetti di grandi dimensioni in attività più piccole", afferma Megan Cook, Jira Lead di Atlassian.

In che modo Scrum pianifica ed esegue gli sprint?

Secondo gli autori della metodologia Scrum, per pianificare lo sprint futuro, tutti devono incontrarsi in una riunione separata. In questo evento, i membri del team devono trovare le risposte a due domande principali: cosa è necessario fare in questo sprint e come farlo al meglio?

Il cliente del software, lo Scrum master e i programmatori sono coinvolti nella determinazione dell'elenco delle attività lavorative. Il cliente spiega l'obiettivo dello sprint e le attività del backlog.

Quindi il team sviluppa un piano in base al quale verranno completati i compiti nello sprint. Questo piano, insieme agli elementi di lavoro selezionati, è chiamato sprint backlog. Dopo la riunione di pianificazione, il team si mette al lavoro. Gli sviluppatori selezionano le attività dal backlog, man mano che il lavoro viene completato, lo stato di ciascuna attività cambia da "In corso" a "Completato".

Durante lo sprint, il team tiene quotidianamente riunioni Scrum (stand-up) per discutere questioni attuali e progressi. Tali incontri sono necessari per identificare le difficoltà che possono influire sul completamento dello sprint.

Se lo sprint è completato, il team mostra i risultati del proprio lavoro sulla revisione dei risultati (demo). Ogni partecipante al progetto può conoscere i risultati. La familiarizzazione dovrebbe essere eseguita prima che il codice finito venga unito all'ambiente di produzione.

La retrospettiva completa il ciclo degli sprint. Su di esso, il team identifica le aree che devono essere migliorate in uno sprint futuro.

A cosa prestare attenzione e cosa non fare

La maggior parte dei team giovani trova difficile introdurre gli sprint nel proprio flusso di lavoro per la prima volta. Per evitare problemi, ti consigliamo di rivedere l'elenco delle azioni che richiedono un'attenzione prioritaria.

Cosa dobbiamo fare:

• Verifica che il team comprenda lo scopo dello sprint e come avrà successo. Ciò è necessario affinché tutti si muovano insieme verso un risultato di successo.
• Dovresti avere un arretrato chiaro e comprensibile. Se il backlog non è stato mantenuto correttamente, questo può diventare un problema che può danneggiare il flusso di lavoro.
• Assicurati che la tua stima del ritmo di lavoro sia corretta, tenendo conto delle vacanze estive e di altri fattori.
• Partecipare attivamente alla pianificazione dello sprint. Incoraggia i membri del team ad espandere il piano per storie, bug e incarichi.
• Rifiuta le attività durante le quali gli sviluppatori non saranno in grado di risolvere i problemi di dipendenza.
• Dopo l'approvazione del piano, nomina un dipendente che sarà responsabile dell'inserimento dei dati nel programma di gestione del progetto (carte Jira, ecc.).

Cosa evitare:

• Non abusare di un gran numero di storie, valutare con sobrietà il ritmo del lavoro e non assegnare compiti che saranno difficili da completare in uno sprint.
• Sii consapevole della qualità del tuo lavoro. Controlla se hai abbastanza tempo per il controllo di qualità e per correggere i bug nel codice.
• Assicurati che tutti i membri del team comprendano chiaramente il contenuto dello sprint. Non inseguire la velocità. L'intera squadra deve muoversi insieme.
• Non sovraccaricare gli sviluppatori con lavoro extra. Un altro sprint in arrivo.
• Se il team esprime preoccupazione per il carico di lavoro o la scadenza, dovresti tenere conto della loro opinione. Affrontare i problemi e correggerli se necessario.

bordo di mischia

La Scrum Board è uno strumento che mostra come viene svolto il lavoro dello Scrum Team. È possibile visualizzare le informazioni su tale scheda su carta, sul muro o in formato elettronico (JIRA, Trello).

Una Scrum board ha almeno tre colonne: Da fare, In corso e Fatto. Ecco un esempio di scheda:

La Scrum board contiene tutte le informazioni del backlog, precedentemente approvato per la pianificazione. Di norma, le schede delle attività aziendali sono appuntate sul tabellone in base alla priorità dall'alto verso il basso. Puoi suddividerli in tipi specifici di lavoro (lavoro su codice, progettazione e altro).

Dopo che parte del lavoro è stata completata, la carta viene spostata su tutta la linea nella colonna successiva. Per mostrare la visibilità dello stato di avanzamento del lavoro del team, aiuta il “lavoro rimanente” per giorno sul Burndown Chart.

Puoi anche usare una lavagna a fogli mobili. Su di esso, i nomi delle opere sono scritti su adesivi di carta e attaccati alla lavagna. Non appena il lavoro è completato, gli adesivi vengono spostati in un'altra colonna.

grafico di combustione

Il grafico burndown mostra la quantità di lavoro svolto e la quantità di lavoro rimanente. Viene aggiornato quotidianamente ed è a disposizione di tutti gli interessati. Il grafico è necessario per mostrare i progressi nel lavoro sullo sprint.

Esistono due tipi di grafici:

• Grafico Burndown che mostra l'avanzamento del lavoro in uno sprint.
• Grafico Burndown che mostra lo stato di avanzamento dei lavori fino al rilascio del prodotto (i dati sono riassunti da diversi sprint).

Esempio grafico:

Questo esempio utilizza la psicologia: il grafico non mostra il numero di attività completate, ma il numero di attività rimanenti (non completate).

Cioè, se il team ha svolto 90 attività su 100, potrebbe esserci la falsa sensazione che tutto sia pronto. Dopotutto, il progresso da 90 a 100 attività non cambia davvero nulla.

Se visualizzi il numero di attività rimanenti, non puoi fare a meno di notare come ogni volta diventano sempre meno. Questo spinge inconsciamente i partecipanti al progetto a raggiungere l'obiettivo più velocemente: non dovrebbero esserci compiti incompiuti sulla lavagna.