Ruoli del Team in Scrum PDF

**Ruoli del Team in Scrum** Lavorare con Scrum spesso significa cambiare le abitudini del team. Devono assumersi più responsabilità, aumentare la qualità del codice e aumentare la velocità di consegna. Questo livello di impegno agisce come agente di cambiamento; man mano che i team si impegnano p...

**Ruoli del Team in Scrum** Lavorare con Scrum spesso significa cambiare le abitudini del team. Devono assumersi più responsabilità, aumentare la qualità del codice e aumentare la velocità di consegna. Questo livello di impegno agisce come agente di cambiamento; man mano che i team si impegnano per gli obiettivi dello sprint sono sempre più motivati ​​a migliorare e più velocemente per consegnare un prodotto di qualità. Un buon punto di partenza con Scrum è parlare dei Ruoli. Ci sono tre ruoli specifici in Scrum. Che sono: - **Product Owner** - **Scrum Master** - **E lo Scrum Team** Gli Scrum Team sono auto-organizzati e cross-funzionali. I Team auto-organizzati scelgono come meglio compiere il lavoro invece di essere diretti da altri al di fuori del team. I Team cross-funzionali hanno tutte le competenze necessarie per realizzare il lavoro senza dover dipendere da nessuno al di fuori del team. Il modello di team in Scrum è progettato per ottimizzare la flessibilità, la creatività e la produttività. Gli Scrum Team rilasciano i prodotti in modo iterativo e incrementale, massimizzando le opportunità di feedback. I rilasci incrementali di prodotto "Fatto" garantiscono che una versione potenzialmente utile del prodotto funzionante sia sempre disponibile. [**Il Product Owner**: ] Lo Scrum Product Owner ha la visione di ciò che vuole costruire e trasmette tale visione al team. Il Product Owner si concentra sui requisiti aziendali e di mercato, dando priorità a tutto il lavoro che deve essere svolto. Costruisce e gestisce il backlog, fornisce indicazioni su quali funzionalità spedire in seguito e interagisce con il team e gli altri stakeholder per assicurarsi che tutti comprendano gli elementi nel product backlog. Il Product Owner non è un Project Manager. Invece di gestire lo stato e i progressi, il suo lavoro è motivare il team con un obiettivo e una visione. Possiamo quindi dire che il Product Owner ha la responsabilità di massimizzare il valore del prodotto e del lavoro svolto dal Team di Sviluppo. Come questo è fatto può variare di molto secondo l'organizzazione, gli Scrum Team e gli individui. Il Product Owner ha la responsabilità esclusiva di gestione del Product Backlog. Tale gestione prevede che: - Gli elementi del Product Backlog siano espressi in modo chiaro; - Gli elementi del Product Backlog siano ordinati per raggiungere meglio gli obiettivi e le missioni; - Il valore del lavoro svolto dal Team sia ottimizzato; - l Product Backlog sia visibile, trasparente e chiaro a tutti e mostri su cosa lo Scrum Team lavorerà in seguito; - E gli elementi del Product Backlog siano compresi al livello necessario dal Team di Sviluppo. Il lavoro che abbiamo qui analizzato può̀ esser fatto dal Product Owner o dal Team di Sviluppo. Tuttavia, il Product Owner rimane il responsabile finale (accountable). Il Product Owner è un'unica persona, non un team di persone. Il Product Owner può esprimere la volontà di un comitato nel Product Backlog, ma chiunque voglia cambiare l'ordine di un elemento deve rivolgersi al Product Owner. Affinché il Product Owner possa agire con successo, all'interno dell'organizzazione tutti devono rispettare le sue decisioni. Le decisioni del Product Owner sono visibili nel contenuto e nell'ordine delle priorità del Product Backlog. Nessuno ha il permesso di dire al Team di Sviluppo di lavorare con un diverso ordine e i Team di Sviluppo non sono autorizzati ad ascoltare chi sostiene il contrario. [**Lo Scrum Master**: ] spesso considerato il coach del team, lo Scrum Master aiuta il team a svolgere il miglior lavoro possibile. Ciò significa organizzare riunioni, gestire ostacoli e sfide e lavorare con il Product Owner per garantire che il product backlog sia pronto per lo sprint successivo. Lo Scrum Master è responsabile di assicurare che il processo di Scrum sia compreso, approvato e seguito dal Team. Lei o lui non ha autorità sui membri del team, ma ha autorità sul processo. Ad esempio, lo Scrum Master non può dire a qualcuno cosa fare, ma potrebbe proporre una nuova cadenza di sprint. Gli Scrum Master fanno questo assicurandosi che lo Scrum Team aderisca ai valori, alle pratiche e alle regole di Scrum. La denominazione che viene data a questo ruolo, lo Scrum Master, è anche quella di: Servant Leader (Leader a Servizio) dello Scrum Team. Lo Scrum Master aiuta coloro al di fuori dello Scrum Team a capire se le loro interazioni con lo Scrum Team sono utili oppure no. Lei o lui aiuta tutti a modificare queste interazioni per massimizzare il valore creato dallo Scrum Team. **Lo Scrum Master al servizio del Product Owner** Lo Scrum Master rende un servizio al Product Owner in vari modi, tra cui: - Trovare le tecniche per una gestione efficace del Product Backlog; - Aiutare lo Scrum Team a comprendere come creare gli elementi del Product Backlog in modo chiaro e conciso; - Comprendere la pianificazione del prodotto in un ambiente empirico; **Lo Scrum Master al servizio del Team di Sviluppo** Lo Scrum Master rende un servizio al Team di Sviluppo in vari modi, tra cui: - Coaching al Team di Sviluppo per l'autogestione e la cross-funzionalità; - Aiutare il Team di Sviluppo a creare prodotti di alto valore; - Eliminare gli ostacoli ai progressi del Team di Sviluppo; - Facilitare gli eventi Scrum come richiesto o necessario; e, - Fare Coaching al Team di Sviluppo in ambienti organizzativi in cui Scrum non è ancora pienamente adottato e compreso. **Lo Scrum Master al servizio dell'Organizzazione** Lo Scrum Master rende un servizio all'Organizzazione in vari modi, tra cui: - Fare Leading e Coaching all'organizzazione per l'adozione di Scrum; - Pianificare le implementazioni di Scrum all'interno dell'organizzazione; - Aiutare i dipendenti e gli stakeholder a capire e mettere in atto Scrum e lo sviluppo del - prodotto in maniera empirica; - Provocare il cambiamento che aumenta la produttività dello Scrum Team; - Lavorare con altri Scrum Master per aumentare l'efficacia dell'applicazione di Scrum nell'organizzazione. [**Scrum Team**: ] Vediamo come è composto e come deve funzionare lo Scrum Team. Il Team di Sviluppo è costituito da professionisti che lavorano per produrre un incremento "Fatto" di prodotto potenzialmente rilasciabile alla fine di ogni Sprint. Soltanto i membri del Team di Sviluppo creano l'incremento. I Team di Sviluppo sono strutturati e autorizzati dalle organizzazioni per organizzare e gestire il proprio lavoro. La sinergia risultante ottimizza l'efficienza e l'efficacia del Team di Sviluppo. Lo Scrum Team è composto da cinque o sette membri. Tutti nel progetto lavorano insieme, si aiutano a vicenda e condividono un profondo senso di cameratismo. A differenza dei tradizionali team di sviluppo, non ci sono ruoli distinti come programmatore, designer o tester. Tutti completano insieme il set di lavoro. Lo Scrum Team possiede il piano per ogni Sprint; anticipa quanto lavoro può completare in ogni iterazione. **I Team di Sviluppo hanno le seguenti caratteristiche:** - Sono auto-organizzati. Nessuno (neanche lo Scrum Master) dice al Team di Sviluppo come trasformare il Product Backlog in Incrementi di prodotto potenzialmente rilasciabili; - Sono cross-funzionali, con tutte le competenze come team necessarie a creare un incremento di prodotto; - Scrum non riconosce alcun titolo ai membri del Team di Sviluppo al di fuori di Sviluppatore, indipendentemente dal lavoro eseguito dalla persona; non ci sono eccezioni a questa regola; - Non contengono sotto-team dedicati a particolari domini come il testing o la Business Analysis; non ci sono eccezioni a questa regola; - I singoli membri hanno competenze specialistiche e aree di focus, ma è il Team di Sviluppo nel suo complesso ad avere la responsabilità finale. **La Dimensione del Team di Sviluppo** La dimensione ottimale del Team di Sviluppo è abbastanza piccola da rimanere agile e abbastanza grande da completare un lavoro significativo all'interno dello Sprint. Avere meno di tre persone nel Team di Sviluppo diminuisce l'interazione e comporta un minore guadagno in termini di produttività. Team di Sviluppo più piccoli potrebbero incontrare limiti dovuti alla mancanza di skill durante lo Sprint, che potrebbero rendere impossibile la consegna di un incremento potenzialmente rilasciabile durante lo Sprint. Avere più di nove persone nel Team di Sviluppo richiede un eccessivo lavoro di coordinamento. I Team di Sviluppo di grandi dimensioni generano molta complessità rispetto a quella gestibile da un processo empirico. I ruoli del Product Owner e dello Scrum Master non sono inclusi nel conteggio, a meno che non stiano eseguendo anche loro il lavoro contenuto nello Sprint Backlog.