Ruoli
I membri di un team Scrum eseguono almeno uno dei tre ruoli previsti. La maggior parte degli utenti esegue il ruolo del team che ha la responsabilità di creare il software. Il proprietario del prodotto, inoltre, verifica che i clienti siano rappresentati nel team, mentre lo ScrumMaster aiuta il team e il proprietario del prodotto a seguire in modo efficace i processi Scrum.
In questo argomento
Team
Il team è costituito dagli utenti responsabili per la creazione del software. Il team seleziona storie utente all'inizio dello sprint, collabora per implementare e testare le storie utente durante lo sprint e presenta il software completato durante la revisione dello sprint. Il team è auto-organizzato in quanto gestisce se stesso e il proprio lavoro. Il team è interfunzionale in quanto dispone delle competenze necessarie per fornire le storie utente nel backlog del prodotto. In MSF for Agile Software Development v5.0 non viene fatta una distinzione dei ruoli all'interno del team in base a criteri quali la disciplina di progettazione o l'area di competenza.
Caratteristiche di un buon team
La costituzione di un buon team software è difficile e richiede tempo. Esempi di team efficienti sono sotto gli occhi di tutti: equipe medico-chirurgiche, squadre di basket, cani pastore e relativi addestratori. Ogni membro del team può avere la propria specializzazione, ma il team lavora insieme e successi o insuccessi sono condivisi dall'intero gruppo.
Team software efficienti sono costituiti inoltre da utenti che agiscono in sintonia verso un obiettivo comune. Un team software non dovrebbe essere visto semplicemente come un insieme di esperti, ognuno dei quali a turno esegue solo le attività in cui è specializzato. Un team dovrebbe piuttosto considerato come un gruppo di persone le cui abilità e competenze collettive hanno un peso maggiore rispetto alla competenza di un singolo utente. Attraverso la collaborazione, la comunicazione, la fiducia e la franchezza, un team può raggiungere il successo e crescere al di là delle capacità individuali dei membri per diventare un'unità ad alte prestazioni.
Un buon team include le persone e le competenze necessarie per fornire software funzionante. I membri del team a tempo pieno dovranno disporre della maggior parte o di tutte le competenze necessarie per la realizzazione del progetto. Utenti specializzati quali progettisti, responsabili delle operazioni, architetti o esperti di una specifica tecnologia potrebbero non essere disponibili a tempo pieno. Il team può coinvolgere specialisti esterni nelle attività a breve termine. Tuttavia, i membri del team a tempo pieno dovranno essere rappresentati da un gruppo di persone in grado di coprire la maggior parte delle competenze necessarie per eseguire il lavoro.
Responsabilità principali del team
La responsabilità primaria del team consiste nel creare software che risponda sia alle aspettative del cliente sia ai criteri del team per il software completato. Le responsabilità del team inizia alla riunione di pianificazione dello sprint e terminano con la riunione di revisione dello sprint. Alla riunione di pianificazione dello sprint, il team suddivide le storie utente in attività. Alla riunione di revisione dello sprint il team presenta il software funzionante al proprietario del prodotto e possibilmente ai clienti.
Il team è responsabile inoltre dei propri risultati. Il team gestisce se stesso nella definizione e nel completamento del lavoro selezionato e nella collaborazione tra i membri del team per ottimizzare l'efficacia del team stesso. Il team deve impegnarsi continuamente a migliorare i propri risultati svolgendo le attività seguenti:
Definire i criteri per gli elementi completati e terminare ogni attività prima di avviare la successiva.
Adottare procedure di progettazione efficaci.
Per ulteriori informazioni, vedere Procedure di progettazione.
Supportare il proprietario del prodotto a elaborare e classificare in ordine di priorità le storie utente correnti.
Stima delle storie utente.
ScrumMaster
In qualità di ScrumMaster, si è responsabili della compilazione e della gestione di un team integro, conforme ai processi Scrum. Si opererà inoltre come agente delle modifiche per aiutare il team a superare le difficoltà.
Qualità di uno ScrumMaster
Per essere un buon ScrumMaster, è consigliabile possedere o creare eccellenti capacità di comunicazione, negoziazione e risoluzione dei conflitti. Queste competenze verranno utilizzate giornalmente per favorire lo sviluppo del team. È necessario non solo ascoltare attivamente le parole dette e scritte dalle persone ma anche come vengono pronunciate, prestando attenzione al linguaggio del corpo, alle espressioni del viso, all'intonazione della voce e agli altri tipi di comunicazione non verbale. È consigliabile porre domande che rivelino i problemi nascosti e avere conferma di ciò che si è compreso. È consigliabile utilizzare queste capacità per identificare i problemi potenziali sul team e cercare di impedire che diventino problemi effettivi. È più conveniente per correggere un bug subito dopo averlo individuato ed è più facile e meno caotico correggere un problema del team quando è contenuto e gestibile piuttosto che quando è diventato importante e fuori controllo. È consigliabile che il team, il proprietario del prodotto e le altre parti interessate dell'azienda siano a proprio agio mentre si conduce il team verso un significativo aumento della produttività. È consigliabile raggruppare, analizzare e presentare i dati alle parti interessate dell'azienda in modo da dimostrare come il team migliora e cresce. Ad esempio, se il team ha aumentato significativamente il valore aggiunto e vengono generati meno bug, è necessario mostrare tale miglioramento alle parti interessate dell'azienda.
Responsabilità principali di uno ScrumMaster
La responsabilità primaria è quella di assicurarsi che il team e il proprietario del prodotto seguano i processi Scrum. Ad esempio, è consigliabile che la riunione Scrum giornaliera non diventi una discussione aperta della durata di 45 minuti. Sarà inoltre opportuno assicurarsi che il proprietario del prodotto non chieda al team di aggiungere lavoro a uno sprint dopo l'inizio. Si impedirà al team di presentare storie utente durante la riunione di revisione dello sprint se tali storie non sono interamente completate.
Sarà necessario aiutare il team a risolvere i problemi di blocco che si possono verificare. Potrebbe essere necessario eseguire le piccole attività, ad esempio approvare un ordine di acquisto per un nuovo computer di compilazione, o eseguire attività più grandi e impegnative, come risolvere i conflitti tra i membri del team. Quando le relazioni all'interno del team diventano difficoltose, è necessario agire per ristabilire la normalità e lavorare in modo più efficiente in futuro.
Proprietario del prodotto
La funzione primaria del proprietario del prodotto consiste nel fungere da interfaccia tra i clienti e il team. Una varietà di clienti e parti interessate cercherà di esortare il proprietario del prodotto in più direzioni.
Caratteristiche di un buon proprietario del prodotto
È necessario analizzare le esigenze del cliente e definirle come storie utente. È necessario avere buone capacità di negoziazione in modo da aiutare i clienti a comprendere i compromessi tra le funzionalità richieste e il loro impatto sulla pianificazione. È necessario collaborare con i clienti per classificare in ordine di priorità il backlog del prodotto, in modo che il team possa produrre il prodotto o il sistema più valido, procedendo per singoli incrementi. È necessario disporre di esperienza nell'area o nel settore aziendale del sistema che verrà compilato. Se, ad esempio, il team deve compilare un sistema sanitario per un ospedale, sarà necessario disporre di competenze nel settore sanitario e in quello assicurativo in campo sanitario. Senza queste competenze, non sarà possibile classificare in ordine di priorità il backlog del prodotto o illustrarne gli elementi al team. Saranno inoltre utili competenze finanziarie di base, come la capacità di calcolare il periodo di recupero del capitale investito in un sistema, l'ammortamento del budget e la preparazione di un budget di spesa e capitale. Per la riuscita del team è inoltre molto importante la conoscenza dei processi Scrum e l'impegno verso gli stessi.
Responsabilità principali del proprietario del prodotto
Le responsabilità principali consistono nel rappresentare al team le esigenze del cliente e delle parti interessate e di rispondere alle domande poste dal team. È necessario mantenere il backlog del prodotto aggiornato e classificato in ordine di priorità. Per gestire il backlog del prodotto, è necessario comunicare regolarmente con i clienti, le parti interessate e il team. È necessario incontrare le parti interessate almeno ogni due settimane. L'ordine nel quale vengono implementate le storie utente influirà sul periodo di recupero del capitale investito e sulla quantità di lavoro che il team dovrà eseguire. Il team spiegherà in quale modo la sequenza delle storie utente influisce sul lavoro. È necessario aiutare le parti interessate a capire gli effetti di tali decisioni di classificazione. È inoltre possibile ridurre la necessità di specifiche dettagliate mostrandosi disponibili nei confronti dei membri del team quando hanno domande sull'implementazione delle funzionalità. Per non bloccare il team, è necessario avere le risposte o essere in grado di trovarle molto rapidamente nel giro di poche ore. In caso di non disponibilità, i risultati del team subiranno un impatto negativo.
Nota
Il livello di dettaglio nelle specifiche dipende da molti fattori compreso il tipo di applicazione che il team sta sviluppando. Per molte applicazioni, le specifiche più efficaci sono costituite da storie utente elaborate in modo corretto e linee di comunicazione aperte. Un'applicazione che elabora test di laboratorio può tuttavia richiedere specifiche dettagliate, in modo che il team possa analizzare minuziosamente l'impatto delle modifiche apportate nel corso del tempo.
È inoltre compito del proprietario del prodotto operare sia con il team sia con le parti interessate alla compilazione di test di verifica della compilazione. I test di accettazione consentono di determinare se una determinata storia utente è completa e pronta per la revisione sprint. È necessario conoscere, identificare e descrivere il rischio sia al team che alle parti interessate.