Introducing 

Prezi AI.

Your new presentation assistant.

Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.

Loading…
Transcript

Agile Scrum

per il Game development

Cosa è il metodo Agile Scrum

Lo Scrum è un framework agile per la gestione del ciclo di sviluppo del software, iterativo ed incrementale, concepito per gestire progetti e prodotti software o applicazioni di sviluppo.

Chi lo usa?

Chi lo usa?

  • EA
  • CCP (EVE Online)
  • Epic
  • Valve (Leaft 4 Dead)
  • High Moon Studios ( Deadpool)
  • Bioware

Agile Manifesto

Agile Manifesto

  • Le persone e le interazioni sono più importanti dei processi e degli strumenti (ossia le relazioni e la comunicazione tra gli attori di un progetto software sono la miglior risorsa del progetto)

  • E' più importante avere software funzionante che documentazione (bisogna rilasciare nuove versioni del software ad intervalli frequenti, e bisogna mantenere il codice semplice e avanzato tecnicamente, riducendo la documentazione al minimo indispensabile)

  • Bisogna collaborare con i clienti oltre che rispettare il contratto (la collaborazione diretta offre risultati migliori dei rapporti contrattuali)

  • Bisogna essere pronti a rispondere ai cambiamenti oltre che aderire alla pianificazione (quindi il team di sviluppo dovrebbe essere pronto, in ogni momento, a modificare le priorità di lavoro nel rispetto dell'obiettivo finale).

Caratteristiche

  • "Processo Agile" con meccaniche di auto-organizzazione per i team che devono continuamente progredire con il lavoro.
  • Consegnare il massimo del valore nel minore tempo possibile, producendo ongi volta un gioco "giocabile" in tempi ristretti, dove possono essere aggiunte feature o ripensate.

I Ruoli

Product Owner

Product Owner

Il Product Owner rappresenta gli stakeholders ed è la voce del cliente. È responsabile per assicurare che il team fornisca valore al business. Il Product Owner definisce gli item (requisiti di prodotto) centrati sui bisogni dei clienti (tipicamente user stories), assegna loro la priorità, e li aggiunge al product backlog. I team Scrum debbono avere un Product Owner e si raccomanda che questo ruolo non sia combinato con quello dello ScrumMaster.

Team Di sviluppo

Il Team di sviluppo è responsabile della consegna del prodotto, con incrementi di caratteristiche, che sia potenzialmente rilasciabile alla fine di ogni Sprint.

Un Team di sviluppo è composto da 3-9 persone, con competenze cross-funzionali, che realizzano il lavoro effettivo (analisi, progettazione, sviluppo, test, comunicazione tecnica, documentazione...). Il Team di sviluppo in Scrum si auto-organizza

Team Di sviluppo

Scrum Master

Lo ScrumMaster è responsabile della rimozione degli ostacoli che limitano la capacità del team di raggiungere l'obiettivo dello Sprint e i deliverable previsti. Sebbene sia un ruolo manageriale, lo ScrumMaster non è il team leader, ma piuttosto colui che facilita una corretta esecuzione del processo. Lo ScrumMaster detiene l'autorità relativa all'applicazione delle norme, spesso presiede le riunioni importanti e pone sfide alla squadra per migliorarla. Una parte fondamentale del ruolo di ScrumMaster è quello di proteggere il Team di sviluppo e tenerlo concentrato sui compiti fungendo da cuscinetto verso qualsiasi influenza di distrazione. Il ruolo viene anche denominato servant-leader per rinforzare queste due prospettive.

Eventi

Gli eventi previsti sono utilizzati in Scrum per creare regolarità e ridurre al minimo la necessità di riunioni non definite da Scrum stesso. Scrum utilizza eventi time-box, in modo che ogni evento abbia una durata massima. Questo assicura che una quantità appropriata di tempo è trascorsa pianificando senza permettere l'introduzione di sprechi nel processo di pianificazione.

Oltre allo stesso Sprint, che è un contenitore di tutti gli altri eventi, ogni evento in Scrum è una occasione formale per ispezionare e adattare qualcosa.

Sprint

Sprint

  • Base dello sviluppo con la metodologia Scrum
  • Durata Fissa (1-4 settimane)
  • preceduto da una riunione di pianificazione (non si possono cambiare gli obbietivi)
  • A ogni fine sprint il team consegna una versione Potenzialmente completa

Sprint Planning meeting

All'inizio di ogni ciclo di sprint (ogni 7–30 giorni), viene tenuto uno “Sprint planning meeting”

Sprint Planning meeting

  • Selezionare il lavoro da fare
  • Preparare lo Sprint Backlog che dettagli il tempo necessario per fare quel lavoro, con tutta la squadra
  • Identificare e comunicare la maggior parte del lavoro che è probabile sarà effettuato durante l'attuale sprint
  • Ha un limite di otto ore (nel caso di uno Sprint lungo 30 giorni)
  • (Prima parte) l'intero Scrum team: definisce insieme al Product Owner l'obiettivo dello Sprint e l'insieme di storie su cui impegnarsi.
  • (Seconda parte) il Team di sviluppo: definisce un piano per lo Sprint, risultante nello Sprint Backlog.

Daily Scrum

  • Incontro giornaliero
  • Timebox 15 minuti
  • L'incontro inizia puntuale (anche senza alcuni dei membri)
  • riposta a : "cosa è stato fatto? che cosa si farà? ci sono impedimenti/ostacoli?

Daily Scrum

Sprint Review

  • Avviene alla fine di uno sprint
  • Il Product Owner identifica il "fatto" e "non fatto"
  • Il Team discute dell'andamento dello sprint
  • Il Product Owner Discute il product Backlog così come è , e si fa un calcolo della consegna (Burnup chart)
  • all'interno della Sprint Review si fa anche la Sprint Retrospective
Learn more about creating dynamic, engaging presentations with Prezi