Un team agile allo sprint!
1 like536 views
Il documento riguarda l'applicazione del metodo agile, in particolare il framework Scrum, all'interno di un team. Sottolinea l'importanza di pratiche come la comunicazione efficace, la collaborazione e il miglioramento continuo, oltre ai ruoli chiave come developer, tester, scrum master e product owner. Viene discusso anche il valore di incontri regolari per la pianificazione e la retrospettiva, mirati a raccogliere feedback e ottimizzare il processo di sviluppo.
Un team agile allo sprint!
- 1. Un team agile allo sprint Università degli Studi Roma Tre Facoltà di Economia “Federico Caffè” 12 Aprile 2013 Emiliano Soldi PMP, PMI-ACP, CSM Agile Practice Leader & Coach http://www.EmilianoSoldiPMP.info @EmilianoSoldi #PMIRome_APM
- 2. …una questione di leggerezza COMPLESSITÀ VARIABILITÀ SPRECHI SOVRA-ALLOCAZIONI COLLI DI BOTTIGLIA DEBITO BUSINESS/TECNICO RIDURRE TEMPI ATTESA RIDURRE PASSAGGI DI CONSEGNE RIDURRE SOVRA-PRODUZIONE PREVEDERE TIME-BOXING RIDURRE BATCH DI LAVORO DIMENSIONE SIMILE BATCH DI LAVORO APPROCCIO ITERATIVO EVITARE IL MULTI-TASKING COMUNICAZIONE EFFICACE PIANIFICAZIONE VISUALE MIGLIORAMENTO CONTINUO 2
- 3. Come fare? 3
- 4. Il framework Scrum Regole, ruoli, responsabilità, cerimonie, strumenti, che soddisfano i principi lean. 4
- 5. Il team agile E’ lo “strumento” che mette in pratica nel quotidiano, ciò che il framework prescrive. Deve possedere precise caratteristiche, per sostenere la sfida. 5
- 6. COLLABORAZIONE, COOPERAZIONE, CONDIVISIONE, COORDINAMENTO 6
- 10. CORAGGIO 10
- 11. Competenza tecnica Dimensione ridotta Capacità di adattamento Auto-organizzazione Orientamento al risultato Miglioramento continuo 11 11
- 13. Sprintiamo? 13
- 14. Vi presento il team 14
- 16. Planning Meeting Spiegazione dei requisiti da parte del Product Owner. Analisi dettagli funzionali Commitment del team su cosa realizzare nell’iterazione in partenza Team scompone in task tecnici. Definizione dei criteri di accettazione. 16
- 17. Stand-up Daily Meeting Condivisione stato di avanzamento e eventuali impedimenti. Co-creazione della giornata lavorativa. Cosa ho fatto? Cosa farò? Quali i problemi? Stand-up meeting: Efficacia Focalizzazione Urgenza 17
- 18. Lavoro giornaliero: DEVELOPER • Richiede chiarimenti al Product Owner su dettagli funzionali • Approfondisce l’architettura • Affianca il tester per la definizione degli scenari di test • Sviluppa test unitari, codifica, rifattorizza • Rilascia il prodotto ai tester per controllo qualità • Effettua Bug-fixing 18
- 19. Lavoro giornaliero: TESTER • Ingaggia il Product Owner per definire i criteri di accettazione dei requisiti • Verifica scenari di test con il Product Owner • Pairing con sviluppatore per revisione interfacce, prototipi, regole di business • Crea gli script di automazione dei test • Effettua i test e segnala eventuali bug • Effettua primo sign-off funzionale qualitativo di quanto sviluppato 19
- 20. Lavoro giornaliero: SCRUM MASTER • • • • • • Supervisiona il processo Scrum Aiuta il team a migliorare le performance Si prende carico e risolve gli impedimenti Protegge il team da ‘incursioni’ Training/coaching team e altri stakeholders Support Il Product Owner nella gestione del product backlog • Promuove cultura di incessante del miglioramento continuo (kaizen) 20
- 21. Lavoro giornaliero: PRODUCT OWNER • Alimenta e manutiene il product backlog • Prioritizza i requisiti in base al valore di business, al costo e ai rischi • Ingaggia gli altri stakeholder • Fornisce le informazioni necessarie al team per la realizzazione del prodotto • Verifica quanto realizzato • Fornisce l’accettazione finale, per la messa in demo 21
- 22. Demo/Review Meeting Il team mostra a tutti gli stakeholders interessati, quanto è stato sviluppato e fornisce i dati inerenti le perfomance Il Product Owner raccoglie eventuali feedback provenienti dalla platea al fine di raccoglierli nel product backlog per sviluppi futuri Si vuole creare un clima di fiducia e impegno reciproci 22
- 23. Retrospective Meeting Team riflette sui risultati sprint terminato Si identifica ciò che è andato bene e ciò che non ha funzionato Si identificano azioni di miglioramento, da mettere in pratica immediatamente 23
- 24. Falsi Miti sui Team Agili I team o sono disciplinati o agili Auto-organizzazione = Anarchia Requisiti e architettura chiari subito I team agili non stimano, giocano a poker I tester nei team agili non servono Facciamo unit testing non servono test di integrazione Senza un Gantt il team non sa cosa fare 24