Gestione del progetto in SCRUM

Come funziona?

In pratica, questo significa che l'intero processo viene costantemente ottimizzato e adattato alle esigenze del cliente. squadra e il prodotto durante l'intero periodo di lavoro sul progetto. Responsabilità della gestione sviluppo del prodotto è ripartito tra il proprietario del prodotto (PO) e il team di progettazione. Il PO è la persona responsabile delle decisioni relative alla direzione dello sviluppo del prodotto e ha una "visione" olistica di ciò che il prodotto deve diventare. La gestione dei compiti si basa sulla lavagna Kanban (in combinazione con il sistema di gestione delle attività). sprint funzionalità chiamata SCRUM board). Ogni partecipante al processo può aggiungere compiti al backlog, ma il PO è responsabile della definizione delle priorità. Il team di progetto è responsabile della "trasformazione" delle idee del PO in compiti specifici e della pianificazione della loro attuazione.

Corso del ciclo

Il processo è suddiviso in iterazioni (sprint). Nell'ambito di uno sprint della durata di circa 2 settimane, il team di progetto implementa e testa la parte di funzionalità precedentemente pianificata.

Lo sprint inizia con la "pianificazione", in cui il team discute e prepara i compiti che sono stati precedentemente curati e impostati dal PO in cima al backlog. Successivamente, viene stimata la difficoltà di questi compiti e vengono assegnati dei punti in base alla difficoltà. Con una composizione del team e condizioni di lavoro relativamente costanti, il numero di punti eseguiti in ogni sprint è ripetibile e consente di pianificare il lavoro futuro. Al termine della riunione di pianificazione, vengono selezionati i compiti con un numero totale di punti da completare entro uno sprint e inizia un nuovo sprint.

A metà dello sprint, si verifica il grooming. Si tratta di una riunione in cui il PO presenta al team ulteriori aspettative e idee, mentre il team di progetto le analizza, le suddivide in compiti più piccoli e presenta possibili suggerimenti al PO. Quando pianifica i compiti futuri, il PO si consulta con analisti, utenti, UX e designer grafici. Ulteriori analisi (mercato ricerca e scienza dei dati) sono spesso necessari in questa fase. Solo dopo aver analizzato e formulato le cosiddette User Story, il PO le pubblicherà in un backlog. La User Story deve contenere informazioni su ciò che il PO si aspetta da un determinato compito o gruppo di compiti e sui criteri da utilizzare per riconoscere se il compito è stato completato.

Durante lo sprint, ogni giorno si tengono i cosiddetti "Daily standup meeting". In queste riunioni, ogni sviluppatore racconta al resto del team cosa ha fatto nell'ultimo giorno ed eventualmente informa su eventuali problemi o blocchi che impediscono il proseguimento del lavoro. Grazie a questo scambio di informazioni sullo stato attuale, è possibile individuare molto più rapidamente i potenziali conflitti tra i vari compiti ed evitare la situazione in cui lo sviluppatore si blocca su un problema e non riesce a fare progressi. L'ipotesi dello standup giornaliero deve essere il più breve possibile, ma allo stesso tempo svolgere il suo ruolo. La formula della riunione incoraggia il team a mantenerla breve.

Durante lo sprint, i compiti vengono spostati sulla lavagna SCRUM in base al loro stato attuale. La scelta delle colonne di solito corrisponde al sistema di lavoro dell'azienda o del team ed è associata al sistema di controllo delle versioni e alla frequenza dei rilasci. Per noi è la seguente:

• Da fare - attività in attesa di essere completate
• In corso - attività in corso
• Codice revisione - attività in attesa di essere controllate da un altro sviluppatore
• Preparati - compiti controllati e accettati dagli sviluppatori
• Staged - attività situate in un'istanza di staging e in attesa dell'approvazione della PO
• Accettato - attività accettate dall'OP
• Fatto - attività pronte che si trovano sull'istanza di produzione

Dopo lo sprint, si svolge una retrospettiva. Si tratta di una riunione dedicata all'ottimizzazione del lavoro. L'intero team discute di ciò che è andato bene nell'ultimo sprint e di ciò che deve essere migliorato. Spesso facciamo anche riferimento alla retrospettiva precedente e verifichiamo se siamo riusciti a implementare tutte le idee per migliorare il lavoro. I problemi discussi durante la retrospettiva possono essere di qualsiasi tipo, dagli strumenti di sviluppo, alla pressione, alla difficoltà dei compiti, ai problemi di comunicazione (sia tra gli sviluppatori e il team che con l'OP).

Responsabilità dello SCRUM master

La persona responsabile del corretto svolgimento del processo SCRUM è lo SCRUM master. Questo è spesso il ruolo più incomprensibile all'interno del team. Lo SCRUM master non ha alcun potere decisionale. Le decisioni vengono prese congiuntamente dal team e dall'OP, mentre il ruolo dello SCRUM master è quello di rimuovere gli ostacoli al corretto svolgimento del processo.

I compiti dello SCRUM master includono i seguenti:

• Conduzione di riunioni SCRUM, tra cui pianificazione, preparazione, riunione di standup giornaliera e retrospettiva.
• Garantire che i compiti sulla lavagna SCRUM siano regolarmente curati dal team e prioritarizzati dal PO.
• Funziona da collegamento tra il team e l'OP; quindi, spesso è lo SCRUM master ad avere un ruolo difficile nel tradurre il linguaggio dei programmatori in quello aziendale e viceversa. Questo è dovuto al fatto che, nella nostra azienda, lo SCRUM master è uno sviluppatore, quindi una persona tecnica. Il quadro generale del lavoro dello SCRUM master non lo richiede.
• Impedire al team di andare fuori tema e controllare l'ordine del giorno delle riunioni.
• Cura dell'atmosfera nel team, soprattutto durante le riunioni.
• Risolvere i conflitti che si presentano.

Leggi anche:

• Le buone pratiche di Codest per la creazione di software. Il nostro approccio al viaggio del cliente
• Le buone pratiche di Codest per la creazione di software: GitFlow
• Le buone pratiche di Codest per la creazione di software. Come si realizza l'analisi dei requisiti?