Agile e Scrum

Agile Alliance e Agile Manifesto Il 17 Febbraio 2001 17 sw developers si incontrarono per discutere di processi di sviluppo leggeri. Essi pubblicarono il Manifesto for Agile Software Development. Alcuni di loro formarono l’Agile Alliance, una organizzazione nonprofit che promuove lo sviluppo del software in accordo con i principi del manifesto. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more

Principali metodologie Agili eXtreme Programming Feature Driven Developement (FDD) Crystal Clear Dynamic systems development method (DSDM) Kanban Lean Scrum

eXtreme Programming XP si basa su 12 pratiche fondamentali Test Driven Development Continuous Integration Small Releases Coding Standard Pair Programming … …. Le pratiche XP sono usate in molte altre metodologie agili e sono diventate di uso comune nella programmazione

Elementi primari di Scrum Ruoli » ScrumMaster, Product Owner, Team Cerimonie » Sprint Planning, Daily Scrum, Sprint Review, retrospective Artifact » Product Backlog, Sprint Backlog, Burndown Diagram

Scrum

Lo Sprint Scrum è una metodologia iterativa o incrementale che struttura lo sviluppo in cicli di lavoro chiamati “Sprint” Durata dello sprint: da 1 a 4 settimane e finisce sempre in un giorno prestabilito Lo Sprint non è modificabile né in termini di durata, né in termini di deliverables All’inizio di uno Sprint un team “cross-functional” seleziona gli item da una lista prestabilita e si impegna a completarli prima della fine dello Sprint Durante lo Sprint il team si aggiorna brevemente sui progressi e aggiorna dei diagrammi che gli permettono di capire l’andamento dello Sprint

Scrum Roles - Il Product Owner Il Product Owner è responsabile del raggiungimento del massimo valore di business, raccogliendo da tutti gli stakeholders tutti gli elementi di input per il software da sviluppare Il Product Owner struttura gli elementi di input in una lista con priorità In alcuni casi il Product Owner e il cliente sono la stessa persona, ma a volte invece può coincidere con i milioni di utenti sulla rete Il ruolo di Product Owner coincide con il ruolo di Product Manager o Product Marketing Manager in molte organizzazioni

Scrum Roles – Il Team Il team in Scrum è “cross-functional”, ovvero include tutte le competenze necessarie per produrre il prodotto potenzialmente installabile già dai primi Sprint Il team è anche “self-managing”, ovvero decide in autonomia su quali attività impegnarsi (Pigs and Chickens) Tipicamente è composto da 5 a 10 persone

Scrum Roles - Scrum Master Fa tutto ciò che è in suo potere per aiutare il team a raggiungere gli obiettivi Non è il manager del team; invece lui si occupa di proteggere il team dalle interferenze esterne e guida il team nell’uso delle pratiche di Scrum A volte è un membro del team; non dovrebbe mai coincidere con il Product Owner Non è un Project Manager, non si occupa di dire al team cosa fare o assegnare attività

Scrum Artifacts - Product Backlog

Scrum Artifacts - Sprint Backlog All’inizio di ogni Sprint c’è lo sprint meeting, durante il quale si scelgono gli item del Product BackLog da inserire nello Sprint

Scrum Artifacts - Burndown Diagram

Scrum Ceremonies - Sprint Planning Si effettua all’inizio di ciascuno Sprint, ed è divisa in due parti Nella prima parte prima il Product Owner e il Team rivedono il Product Backlog per capire cosa ha in mente il PO Nella seconda parte lo Scrum Team sceglie gli item del Product Backlog da inserire nello Sprint (quelli a priorità più alta) In questa fase si fanno le stime

Scrum Ceremonies - Daily Scrum Si tratta di un breve stand-up meeting (maxm 15 min); Dopo il meeting il team aggiorna l’avanzamento dei task sullo Sprint Backlog Lo Scrum Master aggiorna lo Sprint Burndownm Chart, per capire quanto lavoro manca alla fine dello Sprint

Scrum Ceremonies - Sprint Review Durante lo Sprint Review il team mostra il lavoro effettuato Non è una presentazione o Demo, il team mostra effettivamente il lavoro svolto

Scrum Ceremonies - Sprint Retospective Subito dopo lo Sprint Review, il team effettua lo Sprint Retrospective Si prova ad analizzare cosa ha funzionato e cosa no

Conclusioni E’ basato sul pull scheduling Limita il WIP (Work In Progress) Usa la trasparenza per guidare il processo di miglioramento E’ focalizzato nel consegnare working software presto e spesso Si basa su team cross funzionali che si auto-organizzano Richiede di parcellizzare il lavoro suddividendolo in pezzi Il processo di rilascio viene continuamente ottimizzato basandosi su dati empirici (velocity / lead time) E’ basato su Iterazioni Time-Boxed Il Team si reponsabilizza su una specifica quantità di lavoro per l’iterazione corrente Prevede l’uso delle stime all’inizio dell’iterazione

Tools