Agile workshop based on the board game "Agile: the Board Game" -
http://code.google.com/p/agile-the-board-game
(Italian Version).
During this 1day workshop participants embrace the Agile values and Lean principles using the Agile board game and the A3 Airplane game.
The spirit of the workshop is learning by doing.
You can download and use freely these slide under CC3 License.
Come abbiamo introdotto la metodologia agile, attraverso SCRUM, in una piccola agenzia web multi progetto seguendo un approccio lean per gestire sia i team che i progetti.
Come funziona Scrum? Quali sono i suoi mattoni base? Questa presentazione è il primo tassello della collana divulgativa di Agile Reloaded su Agile e Lean Software Development. Lasciate i vostri commenti, li utilizzeremo per il cartone animato!
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...Roberto Bettazzoni
2006
Prima serata di una serie di Talk serali all' ERLUG (Emilia Romagna Linux User Group) Presentazione delle Metodologie Agili (confronto con la situazione esistente)
Presentazione delle Pratiche Agili
Esempio d'applicazione di tecniche Agili
Agile e OSS distribuito
eXtreme Programming
Una breve incursione nel mondo delle metodologie agili di sviluppo del software. Le slide sono intese per fornire una base per successive puntate in cui analizzare meglio i diversi aspetti di tale metodologia.
Slide aggiornate del workshop di una giornata con il gioco da tavolo Agile the Board Game che spiega in pratica, usando i lego, come funziona Scrum.
Non manca durante la giornata anche l'esercitazione su A3 Reporting, il metodo Lean per apportare continui cambiamenti ai processi eliminando le cause di spreco.
Potete usare le slide per divulgare Agile e Lean, anche a livello commerciale. Ricordatevi solo di rispettare i termini della licenza Creative Common :-)
Commenti e miglioramenti sempre ben accetti!
Come abbiamo introdotto la metodologia agile, attraverso SCRUM, in una piccola agenzia web multi progetto seguendo un approccio lean per gestire sia i team che i progetti.
Come funziona Scrum? Quali sono i suoi mattoni base? Questa presentazione è il primo tassello della collana divulgativa di Agile Reloaded su Agile e Lean Software Development. Lasciate i vostri commenti, li utilizzeremo per il cartone animato!
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...Roberto Bettazzoni
2006
Prima serata di una serie di Talk serali all' ERLUG (Emilia Romagna Linux User Group) Presentazione delle Metodologie Agili (confronto con la situazione esistente)
Presentazione delle Pratiche Agili
Esempio d'applicazione di tecniche Agili
Agile e OSS distribuito
eXtreme Programming
Una breve incursione nel mondo delle metodologie agili di sviluppo del software. Le slide sono intese per fornire una base per successive puntate in cui analizzare meglio i diversi aspetti di tale metodologia.
Slide aggiornate del workshop di una giornata con il gioco da tavolo Agile the Board Game che spiega in pratica, usando i lego, come funziona Scrum.
Non manca durante la giornata anche l'esercitazione su A3 Reporting, il metodo Lean per apportare continui cambiamenti ai processi eliminando le cause di spreco.
Potete usare le slide per divulgare Agile e Lean, anche a livello commerciale. Ricordatevi solo di rispettare i termini della licenza Creative Common :-)
Commenti e miglioramenti sempre ben accetti!
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Manifesto per lo Sviluppo Agile di SoftwareAmmLibera AL
In Ingegneria del SW, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste.
Esistono un certo numero di tali metodologie e la Agile alliance, formatasi nella stesura del manifesto in oggetto, è una organizzazione no-profit creata allo scopo di diffonderle.
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle montagne dello Utah, diciassette persone sono incontrate per parlare, sciare, rilassarsi, cercare di trovare un terreno comune e, naturalmente, mangiare. Il risultato è stato il Manifesto per lo Sviluppo Agile di Software (Agile Software Development Manifesto). I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e altri simpatizzanti erano accomunati della necessità di trovare un'alternativa ai pesanti processi di sviluppo software e alla stesura della relativa documentazione.
Questo ebook presenta i 12 punti del Manifesto, corredato dalla presentazione di Jim Highsmith, pubblicato in inglese su http://agilemanifesto.org/ , e nel libro tradotta in italiano.
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
C’è chi sogna che la sua azienda “passi a agile”, chi lo sta facendo e chi lo ha fatto.
In tutti questi casi le aspettative sono alte e il cambiamento forte.
Ma cosa avviene veramente dal “sogno alla realtà”?
A volte il processo di adozione dell’agilità non è così lineare e prevedibile e può dare risultati diversi da quelli attesi.
In questo talk condivideremo la nostra esperienza sul campo, riportando quello che abbiamo visto durante le fasi tipiche delle trasformazioni agili raccontando esperienze di vita vissuta come coach ma anche come PO, SM e sviluppatori.
Metaware & Agile - Un Dev Team può creare valore (solo per il cliente?)Ciro Donato Caiazzo
In quanti modi un team di sviluppo Agile può creare valore?
In questa presentazione è proposto un caso di successo di applicazione delle metodologie Agile per la creazione di team per sviluppare progetti e prodotti software con un focus particolare sul continuous improvement e l’ innovazione tecnologica creando valore per il cliente, l’ azienda e i talenti geek.
"Extremely Scaled Agile": situazioni "estreme" in cui si adottano metodologie Agili (esempio: trasformazione di enormi organizzazioni, con prodotti molto complessi, clienti per nulla Agili). Vedremo quali sono i problemi principali da affrontare (con particalare riferimento ai PO), quando si "scala" Agile in tali organizzazioni: mancanza di ownership, Managers tradizionali, clienti che impongono certificazioni, codice legacy, dipendenze tra i Team, problemi architetturali, difficoltá nel rimuovere impedimenti a livello piú alto, mancanza di feedback dal cliente e di Visione. Come puó, chi crede fortemente nell´Agilitá, sopravvivere a tutto cio?
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Manifesto per lo Sviluppo Agile di SoftwareAmmLibera AL
In Ingegneria del SW, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste.
Esistono un certo numero di tali metodologie e la Agile alliance, formatasi nella stesura del manifesto in oggetto, è una organizzazione no-profit creata allo scopo di diffonderle.
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle montagne dello Utah, diciassette persone sono incontrate per parlare, sciare, rilassarsi, cercare di trovare un terreno comune e, naturalmente, mangiare. Il risultato è stato il Manifesto per lo Sviluppo Agile di Software (Agile Software Development Manifesto). I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e altri simpatizzanti erano accomunati della necessità di trovare un'alternativa ai pesanti processi di sviluppo software e alla stesura della relativa documentazione.
Questo ebook presenta i 12 punti del Manifesto, corredato dalla presentazione di Jim Highsmith, pubblicato in inglese su http://agilemanifesto.org/ , e nel libro tradotta in italiano.
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
C’è chi sogna che la sua azienda “passi a agile”, chi lo sta facendo e chi lo ha fatto.
In tutti questi casi le aspettative sono alte e il cambiamento forte.
Ma cosa avviene veramente dal “sogno alla realtà”?
A volte il processo di adozione dell’agilità non è così lineare e prevedibile e può dare risultati diversi da quelli attesi.
In questo talk condivideremo la nostra esperienza sul campo, riportando quello che abbiamo visto durante le fasi tipiche delle trasformazioni agili raccontando esperienze di vita vissuta come coach ma anche come PO, SM e sviluppatori.
Metaware & Agile - Un Dev Team può creare valore (solo per il cliente?)Ciro Donato Caiazzo
In quanti modi un team di sviluppo Agile può creare valore?
In questa presentazione è proposto un caso di successo di applicazione delle metodologie Agile per la creazione di team per sviluppare progetti e prodotti software con un focus particolare sul continuous improvement e l’ innovazione tecnologica creando valore per il cliente, l’ azienda e i talenti geek.
"Extremely Scaled Agile": situazioni "estreme" in cui si adottano metodologie Agili (esempio: trasformazione di enormi organizzazioni, con prodotti molto complessi, clienti per nulla Agili). Vedremo quali sono i problemi principali da affrontare (con particalare riferimento ai PO), quando si "scala" Agile in tali organizzazioni: mancanza di ownership, Managers tradizionali, clienti che impongono certificazioni, codice legacy, dipendenze tra i Team, problemi architetturali, difficoltá nel rimuovere impedimenti a livello piú alto, mancanza di feedback dal cliente e di Visione. Come puó, chi crede fortemente nell´Agilitá, sopravvivere a tutto cio?
The objectives of this book are to assure an awareness of the importance of project management in modern business environment, to understand the role of the project manager, to develop the capacity to assess business opportunities, to get familiarity with the project management toolkit, and to develop the capacity for teamwork and leading the team and individuals. This book guides students through fundamental project management concepts and behavioural skills needed to successfully initiate, plan, implement and close a project.
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...Vittorio Polizzi
Perché i progetti falliscono? Gli approcci tradizionali nei progetti di sviluppo hardware e software sono davvero efficaci in un mercato in continua evoluzione e con prodotti ad elevata obsolescenza? Le caratteristiche dell’approccio Agile possono essere applicate per ideare e creare soluzioni innovative in modo efficace ed economico?
In occasione di questo incontro affronteremo questi quesiti e le metodologie agili che possono dare una risposta.
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15Stefano Saladino
La diffusione globale del virus può essere un momento che rivela se i datori di lavoro sono pronti a rispondere rapidamente a cambiamenti imprevisti sul posto di lavoro. I viaggi d’affari potrebbero diminuire o arrestarsi completamente. Un numero maggiore di dipendenti potrebbe dover lavorare al di fuori degli “orari di lavoro» locali e utilizzare la videoconferenza per operare all’interno dei fusi orari. E, se va abbastanza male, a molti potrebbe effettivamente essere domandato, o richiesto, di lavorare in remoto. Le organizzazioni sono pronte? Probabilmente no. Come prepari la tua organizzazione non solo a rispondere in modo flessibile a questa potenziale interruzione, ma anche a sfruttarla come un’opportunità per reinventare il lavoro in senso lato?
Agile Project Management: Integrare metodologie di progetto tradizionali con ...Codemotion
Negli ultimi anni, anche secondo l'approccio Lean Startup, il modo migliore per rilasciare prodotti - non solo software - è tramite framework Agili. Quando si è agili all'interno di un organizzazione più tradizionale, questo approccio spesso si scontra con le prassi di gestione progetti più tradizionali. Nonostante lo scontro - principalmente filosofico - è in realtà possibile integrare metodologie di progetto tradizionali con quelle agili. Durante il talk, dopo una breve introduzione, saranno presentati dei modelli di ciclo di vita Agile e Tradizionale e la struttura consigliata dei team.
Workshop su Agile Project Framework e Agile PM per il PMI®-NIC Branch Lombardia. Cosa è Agile, l'Agile Project Framework e Agile Project Management e le tecniche MoScoW e il Timeboxing. Come si struttura un Team Agile.
Intervento dell'Ing.Rea durante l'evento L'IMPRESA AGILE & MOBILE 2.0, svoltosi il 9 e 10 ottobre presso l'Hotel Caesius Thermae & Spa Resort, Bardolino (Vr).
Similar to Agile Project Management - the Board Game workshop (20)
What a Platform is? Which is the role of Engineers? How to improve time-to-market and reduce total cost of ownership moving from project to product mindset?
Those are just of some questions that Platform Engineers are answering everyday. This is a draft presentation of my next presentation about Platforms and Software Engineering.
Platform governance, gestire un ecosistema di microservizi a livello enterpriseGiulio Roggero
A livello enterprise, le moderne architetture distribuite coinvolgono molti team differenti, centinaia di sviluppatori e operations e migliaia microservizi ed API in produzione. Come si può gestire questa
e o
un'esplosione di costi e preservando il time-to-market?
Molte aziende hanno costruito negli anni sistemi informatici complessi che gestiscono i processi interni e i processi di gestione i clienti/fornitori. Con il cambiamento delle abitudini dei consumatori quello che una volta si faceva intermediato da un agente, commesso o addetto che usava il sistema gestionale per rispondere alla richiesta del cliente ora si fa in modalità self service semplicemente con uno smartphone, il cliente si aspetta di essere autonomo nel rapporto con l’azienda. L’esperienza che ci si aspetta come consumatore è quella che si vive usando piattaforma native digitali come ad esempio Netflix e Spotify. Il problema è che la maggior parte delle aziende non è partita nativamente digitale e non è possibile azzerare tutto e ripartire da capo senza correre rischi di business continuity importanti che vedono milioni di clienti coinvolti e impatti significativi a livello economico in caso di down. Se non è possibile ripartire da zero, quindi come fare? Una risposta è un approccio graduale di evoluzione architetturale e tecnologica dove Kubernetes, e il suo ecosistema, giocano un ruolo chiave. In questa presentazione vedremo i tre principi cardine sulla quale si basa questa strategia: API as a Product; architetture evolutive; fast data con pattern CQRS; che si uniscono per creare una strategia di Modernizzazione delle Applicazioni utilizzando i componenti dell’ecosistema del landscape CNCF (https://landscape.cncf.io). Da qui capiremo quali siano i benefici nel breve, medio e lungo termine e quali passi iniziare a fare per avviare questa strategia.
E’ meglio separare i microservizi per layer o per scopo? Quanti gateway devo avere? E’ necessario un pub/sub per far comunicare i microservizi? La persistenza dove la metto? Quali linguaggi uso? Sono alcune delle domande tipiche che ci si pone quando si parte a disegnare e sviluppare una piattaforma moderna basata su microservizi e containers. In questo talk vedremo alcuni stili architetturali e buone pratiche di test, deploy, monitoraggio e business continuity per creare piattaforme robuste e scalabili. Spoiler: non parlerò di Twelve-Factor App :-)
Do pair programming with an artificial intelligenceGiulio Roggero
Si prevede che nel 2022 il 40% dello sviluppo di applicazioni software sia co-sviluppato insieme ad una intelligenza artificiale (sorgente Gartner 2019).
Ci pensate? Come sarà sviluppare in pairing? Saremo più produttivi? Faremo meno errori? Il codice sarà più pulito? La gestione dei feature toggle sarà più semplice? I rilasci saranno ancora più semplici?
Immaginate fare ping-pong programming con la vostra intelligenza artificiale personale, quanto sarebbe motivante e divertente scrivere codice. E se applichiamo TDD potremmo arrivare ad un livello di clean code mai visto. Anche le persone meno esperte potrebbero imparare a sviluppare in modo pulito ed efficace.
In questa mezz’ora voglio esplorare insieme a voi questo modo che sembra lontano (vi ricordate 10 anni fa delle macchine che guidano da sole? :-) ) ma in realtà è già intorno a noi e si sta facendo sempre più pervasivo.
Come i Microservizi favoriscono il lavoro dei Feature TeamsGiulio Roggero
In un contesto Agile i Feature Teams sono una delle strutture organizzative più efficaci per sviluppare un ecosistema complesso in modo rapido, mantenendo alta la qualità e basso il TCO (total cost of ownership). Spesso questi team sono però vincolati da architetture monolitiche, o a lasagna/spaghetti, che non consentono di operare end-to-end sulle feature, creando dipendenze tra team, colli di bottiglia e frustrazione. Lo stile architetturale a Microservizi (sì, è uno stile e non un pattern e quindi va interpretato a seconda dei casi) da una mano a questi team ad essere più indipendenti tra loro e li aiuta a lavorare tutti con lo stesso scopo: generare valore per gli utenti finali in modo continuo. In questo talk vedremo come organizzare più team che lavorano su uno stesso prodotto e come lo stile architetturale a Microservizi supporti questa organizzazione evolvendo con l'evolversi dei team.
La crescita veloce è uno degli aspetti più rilevanti dell'economia negli ultimi anni. Startup, scaleup e unicorni sono tutte aziende che, anno su anno, crescono in modo vertiginoso a livello di numeri di business e di persone, facendo scaling dei sistemi IT.
Le aziende "pre native digitali" stanno guardando a queste realtà come a potenziali (o reali) competitor e si stanno organizzando per scalare. Ma un conto è avere una struttura di business nata per scalare, un conto è scalare con un business avviato da almeno 20/30 anni. Cultura aziendale, sistemi IT e tecnologie si sono stratificati nel tempo e possono essere un ostacolo a questa corsa verso l'alto.
In questo talk vedremo buone pratiche, tecniche e modelli per scalare realtà enterprise sia a livello tecnico (e tecnologico), sia a livello organizzativo. Lo faremo attraverso esempi concreti di casi reali e proponendo spunti su come superare le difficoltà che si incontrano durante il percorso.
Parleremo di Cloud Native, di migrazione da Monoliti e Microservices, di API as a Product, di Organizzazioni Enterprise in stile Open Source e di Cultura Aziendale.
Microservices, Microfrontends and Feature TeamsGiulio Roggero
Quali sono le buone pratiche per progettare un'architettura in stile Microservices?
Come rendere evolutiva un'applicazione Frontend senza che invecchi dopo poco tempo?
Come organizzare più team che lavorano su una Piattaforma che ha centinaia di Microservices e decine di Frontend?
A queste tre domande risponderò durante il talk con esempi pratici e casi di vita vissuta.
L’eccellenza tecnica è uno dei principi cardine dell’agilità e come tale favorisce la creazione di valore mantenendo le architetture semplici e i processi snelli. I sistemi legacy sono però un ostacolo per la ricerca dell’eccellenza tecnica. Di fatto il debito tecnico che si stratifica negli anni non aiuta la continua innovazione e la business agility.
Le nuove tecnologie, come Cloud e Big Data, sono degli abilitatori per creare applicazioni semplici e mantenibili nel futuro. Ma da soli non bastano.
Il problema è che ogni tecnologia ha le sue complessità e spesso queste sono indipendenti dalle logiche applicative. Può succedere che il team spenda più tempo a mettere in piedi l’infrastruttura e la connessione a tutti i servizi Cloud, che a scrivere le parti applicative. E questo tempo spesso si replica N-volte quanti sono gli N-progetti sviluppati da diversi team.
Manca un concetto comune di infrastruttura e piattaforma.
In questo talk vedremo come l’ “infrastruttura invisibile” possa semplificare il lavoro dei team favorendo l’eccellenza tecnica e la business agility.
Piccola anticipazione. L’infrastruttura invisibile é come le rotaie per un viaggiatore in treno: si gode il viaggio sorseggiando la sua bevanda preferita senza preoccuparsi della complessità che letteralmente viaggia sotto i suoi piedi.
Agile è entrato nel gergo comune di molte aziende che hanno a che fare con progetti IT. Questa è una buona cosa: il termine è conosciuto e accettato come una buona prassi, le persone sono ben disposte ad adottare metodi e pratiche che consentono di migliorare la gestione del ciclo di vita di un prodotto software e sono favorevoli al cambiamento.
Quando però si parte veramente mi sono trovato in diverse situazioni dove Agile si limitava alla parte “persone” e “organizzazione” ma non entrava nel merito di come si sviluppa il codice!
La provocazione “Stop Meeting, Start Coding” vuol ridurre all’essenziale i momenti di confronto e concentrarsi a scrivere buon codice, insieme!
In questo talk presenterò alcune buone pratiche di coding che favoriscono anche l’efficacia organizzativa.
Il software che oggi produce valore è stato scritto parecchi anni fa. Il costo di manutenzione ed evoluzione sta diventando sempre più alto.
Parallelamente stiamo vivendo una forte accelerazione sul digitale: omnicanalità, self-service e ubiquità sono fattori che stanno influenzando i comportamenti delle persone. Alle aziende si chiede sempre più innovazione e semplicità dei servizi offerti.
In questa presentazione guarderemo avanti nel futuro, sui software che produrranno valore nei prossimi 10 anni e che stiamo costruendo ora.
Proveremo a dare una possibile risposta a questa domanda:
“come possiamo evitare di accumulare un debito tecnico difficilmente ripagabile e nel contempo seguire l’accelerazione che il mercato ci sta chiedendo senza impattare sul business esistente?”
La multicanalità è il contesto del Cliente digitale di oggi e le spaghetti API stanno prendendo il sopravvento. Il Business e l'IT sono in prima linea a garantire time-to-market e qualità mettendo sotto stress la struttura organizzativa e le tecnologie. Organizzarsi in modo agile non basta, serve anche una strategia chiara di piattaforma!
La presentazione introduce il problema che oggi le aziende hanno a livello IT: tante applicazioni sparse che accedono ai sistemi core in modo non organico (spaghetti API). Questo comporta: rallentamento del time-to-market, attriti nelle relazioni e prodotti poco coerenti tra di loro. Durante una trasformazione digitale si pensa in primo luogo a riorganizzare persone in modo da snellire i processi. Questo è di sicuro aiuto ma da solo non è sufficiente: se i sistemi sui quali lavorano i team non evolvono i team possono essere agili quanto vogliono ma non riescono a tenere il passo con il mercato. La zavorra del debito tecnico di codice e API a spaghetti non è facilmente ripagabile. E’ necessario cambiare le strategie architetturali e creare un sistema che si possa rifare a pezzi e far evolvere. Vedremo come una strategia di Piattaforma Digitale possa essere a supporto per la trasformazione Agile.
This is the updated version of the presentation https://www.slideshare.net/GiulioRoggero/how-a-kanban-board-works.
Do you have a team that works on both project and maintenance? Do you need to organize your team activities? Do you have a lot of activities in parallel and the time to market it's a problem? With a Kanban board and an Agile approach you can solve your problems!
Take a look of the animation of the slides to discover how it works.
--- BONUS ---
Here you can find a more details on lead time and CFD and a new board about Scrum Team Roadmap.
API Conf 2017 - Allineare il business e la tecnologia grazie alle apiGiulio Roggero
Spesso i termini usati dal business non si ritrovano nell'architettura informatica sottostante. E questo alla lunga genera incomprensioni e problemi. In questi 10' vedremo come, in 3 semplici passi, sia possibile allineare i termini usati dal business e dai tecnici. Per facilitare la spiegazione vedremo due brevi esempi di casi reali: Trenord e Foorban.
Talk Agile O'Day Napoli - 2017
Cosa contraddistingue uno sviluppatore affidabile? In questa presentazione si parla di:
- Semplicità
- Debito tecnico e valore
- Test prima!
- Tutto automatico
- Utenti al centro
Agilità interculturale
I valori dell'Agile Manifesto come fattore abilitante alla collaborazione dei team interculturali.
La collaborazione tra persone avviene grazie anche a una buona comunicazione. Culture differenti possono interpretare in modo diametralmente opposto atteggiamenti, frasi e situazioni. Se non opportunamente gestita la situazione porta a problemi critici di collaborazione all'interno del team minando le possibilità il successo del progetto.
L'approccio Agile al progetto tende a mitigare questo rischio grazie alla intrinseca resilienza dei principi ai quali si ispira. Comunicazione trasparente e feedback continui sul prodotto incrementale riducono notevolmente il rischio di non capirsi e di remare in direzioni diverse.
In questa presentazione vedremo alcune pratiche che favoriscono la collaborazione e fanno emergere il potenziale che i team interculturali possono dare ad un progetto.
Agile Project Management - the Board Game workshop
1. Agile Project Management
Un giornata di workshop con il gioco Agile: The Board Game
Giulio Roggero - Scrum Master,PMI-ACP, PMP, Prince2
2. Agile Manifesto
www.agilemanifesto.org
• Individuals and interactions
over processes and tools
• Working software
over comprehensive documentation
• Customer collaboration
over contract negotiation
• Responding to change
over following a plan
3. Documentazione?
• La documentazione è importante, molto
importante
• E’ importante se è vera
• Il progetto evolve la documentazione non
sempre!
• E’ un costo molto alto tenere aggiornata la
documentazione
In un progetto software qual’è il documento che
rispecchia meglio la realtà?
5. Contratto
• Oggetto del contratto
• Elenco Specifiche: A, B, C
• Dettaglio Specifiche
• Assunzioni e Limiti
• Tempi: 3 mo
• Costi: 100.000$
• Modalita’ di approvazione del prodotto/servizio
• Pagamento
• Diritti di recesso
Firma e
approvazione
• Penali
16/06/2011
6. … e dopo un mese?
• Oggetto del contratto: OK
• Elenco Specifiche: A, B, C, D, E
• Dettaglio Specifiche: in realtà C è D+E
• Assunzioni e Limiti
• Tempi: 4 mo
• Costi: 120.000$
• Modalita’ di approvazione del prodotto/servizio
• Pagamento
• Diritti di recesso
• Penali
e ora chi paga?
Firma e
approvazione
16/06/2011
7. Esercizio
• L’azienda My Oil S.p.A. deve aggiornare il
sistema di monitoraggio delle trivellazioni
petrolifere secondo la norma che entrera’ in
vigore fra un mese da oggi
• Il signor White è l’incaricato di My Oil per
fornirvi tutte le informazioni necessarie,
l’importante è che il nuovo sistema sia
operativo in tutte le 100 sedi entro
un mese
• Non ci sono limiti di budget
Come procedete?
• 10’ per discussione
• 5’ per gruppo di incontro con il signor White
8. Collaborazione con il cliente
Domande di difficile risposta
• Che bisogni ha il cliente?
• Come lavora il cliente?
• Cosa vede il cliente?
• Come comunicare con lui?
• Quali aspettative ha?
1. Lavorare a stretto contatto con il cliente
2. Respirare la stessa “aria”
3. Avere le stesse aspettative
Fa superare più facilmente la conflittualità intrinseca dei contratti
1. Lavorare a stretto contatto con il cliente
2. Respirare la stessa “aria”
3. Avere le stesse aspettative
Fa superare più facilmente la conflittualità intrinseca dei contratti
9. Esempi di contratti “Agili”
• A forchetta minima e massima (PERT
aiuta)
• A condivisione del rischio: 50%-50% sul
budget risparmiato
• A bande: si concorda il budget, si fissa di
volta in
volta lo step a
prezzo fisso
• Time and material
classico
10.
11. Storia
Jeff Sutherland introdusse nel 1995 l’idea che i
team si muovessero sull’orlo del caos e si auto-controllassero
come succede in natura.
Ken presento’ con Jeff al OOPSLA95 il primo paper
su SCRUM.
L’ultima edizione e’ del gennaio 2011
http://jeffsutherland.com/ScrumPapers.pdf
Gli autori affermano che:
“Scrum non e’ una metodologia o un processo
formale ma un algoritmo di compressione delle
migliori abitudini in ambito dello sviluppo del
software osservate in tutto il mondo negli ultimi 50
anni”
jeffsutherland.com
kenschwaber.wordpress.com
14. Product Owner
Cosa fa
Massimizza il valore di
ogni Sprint
Decide quali sono gli item
piu’ importanti di ogni
Sprint
Puo’ cambiare le priorita’ di
volta in volta
Raffina i backlog
Prende le decisioni che
impattano sul prodotto
Cosa non dovrebbe fare
Il project manager
Sviluppare
Decidere tecnologie e
processi
15. Team (pigs)
7 persone ± 2
Cross-funzionale: non solo sviluppatori ma anche tester,
interaction design, content managers e tutte le figure
professionali necessarie per sviluppare un prodotto di valore
Preferibilmente co-located: riduce i tempi di comunicazione e
migliora i rapporti del team
Full-time sul progetto: le “abitudini” di Scrum prevedono una
dedizione al progetto giorno per giorno e un ritmo sostenibile
difficilmente da parte di membri del team “multi-tasking”
FOCUS!
16. Team (pigs)
Cosa fa
Sviluppa il prodotto
indicato dal product owner
Da idee al Product Owner
su come migliorare il
prodotto
Si auto-organizza
all’interno dello sprint
Tiene traccia degli item di
backlog completati
Stima gg per gg il backlog
rimanente
Cosa non dovrebbe fare
Implementare item che
non sono nell sprint
backlog
Aggiungere item allo sprint
backlog
Cambia spesso i suoi
membri
17. Stakeholders (chickens)
• Sono tutti gli appartenenti all’organizzazione che possono
essere impattati dal progetto.
• Possono partecipare ai meetings ma senza diritto di parola
18. Le persone del team
belbin.com
• “Plant”: creativa e brava a risolvere i problemi in modi non convenzionali. Uno
per team.
• Monitor Evaluator: il logico, prende decisioni imparziali e pesa in modo
razionale le opzioni del team.
• Co-ordinators: aiuta a mantenere il focus del team, fa emerge i membri del
team e delega in modo appropriato.
• Resource Investigators: migliora i processi e porta la voce del team fuori.
• Implementers: il motore che pianifica strategie efficaci e le porta a compimento.
• Completer Finishers: intervengo alla fine per completare il task rimuovendo
errori e ottimizzando la qualita’.
• Teamworkers: sono il collante del team, si identificano con il team e aiutano nel
lavoro di squadra.
• Shapers: il leader, fa in modo che il team non perda focus e spinta.
• “Specialist”: ha una conoscenza molto specifica nella key area del progetto.
emerged.
19. Scrum Master
• Una persona con backgroud differenti, es:
Engineering, Testing, Quality Control,
Product Management, Project Management
• Energica e umile
• Dedicata full-time su grossi progetti
• In Team piccoli può essere un membro
del Team
• ATTENZIONE PM o Team Leaders che
diventate Scrum Master: dovete
cambiare molto il vostro approccio,
è un lavoro completamente diverso!
Favorire l’auto-organizzazione!
20. Scrum Master
Cosa fa
Tutor del team
Aiuta Team e PO ad avere
successo nel progetto
Protegge il Team dai fattori
esteri
Facilita le relazioni
Toglie gli impedimenti
E’ al servizio del Team
Aiuta a capire il flow-value
dello Scrum
Cosa non dovrebbe fare
Il project manager
Il team leader
Il product owner
Assegna Task
Dice alle persone cosa fare
21. Scrum roles – note importanti
• Scrum Master e Productr Owner NON possono essere lo stesso individuo
• E il Project Manager? NON ESISTE!
• I ruoli di PM sono divisi tra i tre ruoli di Scrum:
• Scrum Master
• Product Owner
• Team
• Un cambio di approccio è fondamentale!
Passare da assegnare attività everificare lo stato (SAL) a
Aiutare, supportare, fare coaching e mentoring, rimuovere gli
impedimenti
Essere al servizio del team!
24. Product Backlog
• Lista di features con priorita’
• Roadmap del prodotto
• Responsabilita’ del Product Owner
• Tutto quello che e’ nel Product backlog e’ il prodotto
• Quello fuori NON ESISTE!
• Il product backlog evolve nel tempo:
• Priorita’
• Descrizione e dettagli (raffinamento del Product
Backlog)
• Stime
• NE ESISTE UNO SOLO
26. Cosa include
• Funzionalità/requisiti cliente
• Miglioramenti tecnici/tecnologici
• Esplorazioni su nuovi aspetti del
prodotto/del software
• Bugs conosciuti
27. Come viene descritto
• Scrum non definisce un metodo
• Le user stories sono uno dei metodi piu’ usati
• Si possono usare anche Work Breakdown
Structure (WBS)
• A volte viene creato un Release Backlog
come sottoinsieme del BP per definire l’ambito
della release del prodotto
28. User Story
"As a <role>, I want <goal/desire> so that <benefit>"
29.
30. Una user story su excel
User Story ID Front Back Busin
alarm.search "As a User I want to
search alarms by
name, type,
application, date,
range of dates and
free text search so
that I can analyze
problems on the
system"
filters are
automatically added
looking at column
names and can be
combined in OR and
AND (like workflow in
console)
ess
Value
Priorit
y
Estim
ated
Story
Point
TBD VH 5
31. Sprint Backlog
• L’insieme di task da completare in uno sprint
• Uno o piu’ task sono relativi a un item del Product
Backlog
• Ogni task ha una stima in ore
• Ogni task e’ assegnato a una persona che lo richiede
in modo volontario
32.
33. Definition of Done
• Definizione di completato
• Tipicamente e’ una regola di backgroud di tutto il progetto
• Es: una feature si considera completata se:
• Codificata
• Gli unit test sono tutti passed
• Il codice e’ commentato
• La funzionalita’ e’ utilizzabile dall’utente e soddisfa i requisiti
di usabilita’ definiti nella sua user story
• E’ integrata nel setup/ambiente di deploy
• E’ taggata sotto repository
• Ha la documentazione utente
La definition of done NON deve variare di volta in volta, e’
fissa! Una volta che e’ decisa si segue sempre quella.
34. PSPI
Potentially Shippable Product Increment
• Ogni Sprint idealmente finisce con un prodotto
potenzialmente rilasciabile
• MAI lasciare le cose a meta’: meglio chiudere
una cosa in meno e spostarla nel prossimo sprint
che lasciare le cose aperte a fine sprint
Chiudere sempre secondo la Definition of Done concordata!
35. Motivazioni del PSPI
• Permette di raccogliere i feedback
velocemente
• Riduce i rischi (bugs non alla fine)
• Aiuta il cliente finale a prendere
confidenza del prodotto
• Migliora l’apprendimento
36. Previsioni e Stime
1.Una previsione metereologica e’ valida
1-2 giorni
2.Al terzo giorno e’ gia’ molto incerta
• Oltre il terzo e’ una speculazione
38. Pianificare in Agile???
• Si pianifica di piu’ e piu’ spesso!
• Me tenere sotto controllo il flusso
del valore (Value Flow) la
pianificazione e la stima sono
fondamentali
• Riflettere sulle sitme a posteriori
aiuta a stimare meglio la volta
dopo
39. Stime
• Il Product Owner e’ responsabile per assegnare il
business value di ogni item del BP
• Il Team e’ responsabile per stimare l’effort di
sviluppo di ogni item del PB
• Il Team e il Product Owner fanno un’analisi di
rischio
• Lo Scrum Master aiuta in questa fase
• Scrum non definisce tecniche di stima
• Story Points e Ideal Time
• Range Estimation
• PERT
41. Stime – Poker Game
• Ogni membro del team si crea delle carte con la sequenza di
Fibonacci: 1, 2, 3, 5, 8, 13, 21, BIG
• Le user stories sono visibili a muro o sul pavimento o su un
tavolo
• Lo scrum master sceglie una User Story rappresentativa della
quale si conoscono abbastanza dettagli e che sia piccola
• Il team concorda che quella vale 1
• Lo Scrum Master scegli un’altra User Story
• Ogni membro del team di nascosto sceglie una carta
• Quanto tutti hanno scelto scoprono la carta
• La maggioranza vince, si discute sulle differenze se ci sono
disaccordi e si rivota
• Si itera il processo fino a quando non sono finite le User
Stories selezionate
43. Successo
Il successo in
Agile e’
misurato sul
valore generato
dal progetto
Il valore dipende dal contesto del progetto ed e’ definito con il Cliente
44. Priorita’!
3 variabili
CCoosstoto VVaalolorree RRisiscchhioio
PPrrioiorritiata’’
Product Owner
Priorita’ massima: minor costo, maggior valore (rischio minimo)
48. Il tempo non basta mai
sett 1 sett 2 sett 3 sett 4 sett 5
DDoonnee
DDoonnee
DDoonnee
49. Funziona?
Pro
Si pensa di essere piu’
produttivi
Diversificare aiuta a non
annoiarsi
Si puo’ star dietro a piu’
clienti
Si possono sfruttare i
“tempi morti”
Contro
Sotto stress
Ore piccole
Tempo perso nel cambio di
contesto
50. … e se fossimo monotasking?
sett 1 sett 2 sett 3 sett 4 sett 5
DDoonnee
DDoonnee
DDoonnee
51. Pomodoro Technique
• Scegli il task da completare
• Imposta il Pomodoro a 25 minuti
(Il Pomodoro è il timer)
• Lavora sul task senza distrazioni o
interruzioni fino a che il Pomodoro
non suona, dopo metti una spunta
nel tuo foglio della To Do List
• Prenditi un piccolo break (5 minuti vanno bene)
• Ogni 4 pomodori prenditi una pausa un po' più
lunga
www.pomodorotechnique.com
52. L’importanza del time-boxing
• Aiuta a concentrarsi su una singola attivita’
• Da quell’adrenalina positiva per portare a termine un
compito
• Permette di semplificare i task
• Riduce il lavoro inutile
• Incrementa la concretezza (stare con i piedi per
terra)
• Permette di avere un ritmo nel lavoro (non ci sono
piu’ riunioni senza fine che finiscono con un ‘?’)
• Aiuta a trovare accordi con se stessi e con il team
• Permette di pianificare meglio le attivita’ e stimarne il
costo
53.
54. Sprint Planning – Part 1
• Durata: 2-4 ore
• Partecipanti: Product Owner, Scrum Master, Team
• Strumenti: Product Backlog a muro, Definition of Done
• Obiettivo: estrazione degli item per lo sprint
55. Sprint Planning – Part 2
• Durata: 2-4 ore
• Partecipanti: Scrum Master, Team
• Strumenti: Sprint Backlog a muro
• Obiettivo: definizione e stima dei task per lo Sprint Backlog
56. Running the Sprint
• Durata: 1-4 settimane (2 consigliate)
• Partecipanti: Product Owner,
Scrum Master, Team
• Strumenti: Product & Sprint Backlog a muro, Definition of Done
• Attivita’:
• Sviluppo
• Rifinitura del Product Backlog (5-10%)
• Ri-Stima degli item del backlog
• Ri-Prioritizzazione del product backlog
• Analisi di dettaglio
57. Daily Meeting
• Durata: 15’, ogni gg, alla stessa ora, nello stesso
posto (possibilmente in piedi davanti allo Sprint
Backlog)
• Partecipanti: Scrum Master, Team
• Strumenti: Sprint Backlog a muro
• Attivita’:
• Ogni team member dice: cosa ha fatto, cosa fara’,
che impedimenti ha
• Si fissano le riunioni
58. Sprint Review
• Durata: 2-4 ore
• Partecipanti: Product Owner, Scrum Master, Team
• Strumenti: PSPI
• Obiettivo: validare con il Product Owner la chiusura
dello Sprint
60. Report in Scrum
• Product Burndown Chart
• Sprint Burndown Chart
• Test reports
• Architecture diagram status
61. Trasparenza a diversi livelli
• I Chicken NON dovrebbero vedere lo Sprint
Burndowchart
• La trasparenza è sulle features completate
• NON su come il team si auto organizza
• Lo sprint backlog è per il team, meglio su carta!
66. Lean
• Ha origini dal TPS (Toyota Production System) sviluppato tra il 1948-1975
• TPS si basa su
• Continuo miglioramento - Kaizen
• Rispetto per le persone
• Una vision a lungo termine
• Il giusto processo crea i giusti risultati
• Creare valore attraverso lo sviluppo delle persone
• Risolvere subito i problemi
• Ha due pilastri
• Just-in-time
• Automation
• Due scopi
• Ridurre gli sprechi
• Dare valore subito al cliente
67. Lean Flow
Spostare l’attenzione dalla creazione del
prodotto al processo produttivo:
“the production flow”
http://www.lean.org/WhatsLean/Principles.cfm
68. 5 principi di Lean
1. Definire il valore, per ogni famiglia di prodotto, dal punto di vista
del cliente finale.
2. Identificare i passi del value stream, per ogni famiglia di prodotto,
eliminando possibilmente tutti gli step che non creano
valore.
3. Assicurarsi che i vari passi del value siano vicini e possano creare
un flusso veloce verso il cliente finale.
4. Una volta che il value stream e’ attivato favorire l’intervento del
cliente per atto ad aumentare il valore degli step.
5. Una volta che il valore e’ definito, il value stream identificato, gli
sprechi rimossi e il flusso introdotto ricominciare di nuovo il
processo fino a quando il valore e’ prodotto senza sprechi.
70. 10 maggiori cause di spreco
Qualsiasi cosa che non aggiunge valore al cliente
finale e’ considerata uno spreco:
1. Produzione di cose non necessarie
2. Attesa
3. Delegare il lavoro
4. Processi non necessari
5. Lavoro non completato
6. Cambio continuo di attivita’
7. Evidenziare i difetti alla fine del progetto
8. Team che non lavora al suo potenziale
9. Perdita di conoscenza
10.Assecondare i desideri piu’ che le necessita’
razionali
71. Inbox
La posta non letta e’ un esempio di spreco:
• Aumento consistente di giorno in giorno della
posta non letta (“teoria del vetro rotto”)
• Mancanza di evidenza dell’importanza dei vari
messaggi
• Maggior tempo per discriminare la posta
importante da quella meno importante
• Lentezza del client di posta!
Google ha proposto la priority
inbox e funziona!
Oppure cancellate la posta che
non vi serve
72. Bugs
• Una lista molto lunga di bugs “vecchi” non
aiuta a mantenere il flusso di valore:
• Se un bug e’ piu’ vecchio di X mesi significa che
non e’ importante (altrimenti sarebbe venuto giu’ il
mondo!)
• Avere tanti bugs e non risolverli non aiuta a
dare le giuste priorità
Meglio mettere nel cassetto
i bugs e riaprire il cassetto quando
si avra’ il tempo
Meglio non avere bugs!
73. Gemba
• In Toyota e’ la pratica di andare a vedere la
linea di produzione
• I manager non guardano email, grafici, report,
ma direttamente la linea di produzione
• I problemi sono vissuti sul campo, ci si rende
conto della complessita’ e delle persone.
Nei progetti software cos’e’ il Gemba?
75. Title: What you are talking about.
Background
Current Situation
Goal
Analysis
Recommendations
Plan
Follow - up
Why are you talking about it?
Where do we stand?
Where we need to be?
What is the specific change you want to
accomplish now?
-What is the root cause(s) of the problem?
-
What is your proposed
countermeasure(s)?
What activities will be required for
implementation and who will be
responsible for what and when?
How we will know if the actions have the
impact needed? What remaining issues
can be anticipated?
A3 -Verble/Shook
What’s the problem?
77. Sprint Retrospective
• Durata: 1.5-3 ore
• Partecipanti: Scrum Master, Team
• Strumenti: Sprint Backlog, PSPI
• Obiettivo: evidenziare le cose positive dello sprint e
ricercare i motivi degli errori, metabolizzare il processo
78. Com’è organizzato
• Impostare il meeting – 5% del tempo
• Raccogliere i dati – 30-50% del tempo
• Approfondire i motivi – 20-30% del tempo
• Decidere cosa fare – 15-20% del tempo
• Chiudere la retrospettiva – 10% del tempo
79. Esempio di meeting retrospective
• Impostare il meeting – ESVP
(Esploratore, Shopper, Vacanziere, Prigioniero)
• Raccogliere i dati – Timeline
• Approfondire i motivi – 5Whys
• Decidere cosa fare – SMART Goals
(deve essere:
Specific, Measurable, Attainable (raggiungibile), Relevant, Timely)
• Chiudere la retrospettiva – ROTI
(Return of Time Invested) (0-4)
Maggiori dettagli su Agile Retrospectives (Derby, Larsen)
82. Limiti di Scrum
• Si tende a pianificare solo lo sprint successivo.
• Si tende ad isolare il team dal management.
• Si tende ad applicare prima di avere software di
qualita’ e testato in modo automatico.
• Scrum non dice come fare le cose
• Si pensa che i team auto-organizzati, da soli, possano
migliorare il processo. Non basta! Il middle-management
ha un ruolo findamentale.
• La colocation e il single project sono molto utopici.
84. Pratiche XP
• Pair Programming: sviluppare le parti piu’ critiche insieme sullo stesso
pc condividendo le scelte e il codice
• Test Driven Development: scrivere il test e poi sviluppare la
funzionalita’
• Continuos Integration: integrare in modo continuo tutti i componenti
software riducendo il rischio di integrazione posticipata
• Refactoring: rivedere periodicamente il codice migliorandolo e
rendendolo piu’ mantenibile
• Collective Code Ownership: il codice sorgente e’ di tutti e tutti sanno
metterci le mani
• Simple design: tenere sempre il sistema semplice
85. WIP
Ridurre il Work In Progress aiuta a:
•Aumetare la qualita’ del lavoro finito
•Semplificare processi e procedure
•Aumentare la reattivita’ a richieste spot
•Migliorare la vita in azienda
87. Questa e’ molto molto
semplice. Tipicamente si
mettono le fasi di progetto e le
code di attesa.
- WIP limitato
- Persone assegnate solo
quando server
- Continua revisione priorita’
- Piu’ progetti insieme, anche di
diversa natura
91. Scrum di Scrum
• Ogni team lavora con un suo Scrum
• Ogni settimana un membro del team si incontra con
gli altri membri degli altri team per fare un Daily
meeting
• Puo’ essere scalato in modo indefinito
• I rappresentanti possono cambiare di volta in volta
92. Team Virtuali
• E’ possibile applicare Scrum da remoto su team dislocati
geograficamenti
• E’ difficile farlo funzionare
• I tools di comunicazione sono fondamentali, devono
permettere un editing live degli oggetti (es: Google Docs)
• Chat, Call e Video Call devono essere sempre accessibili
• Il repository del codice sempre condiviso
• I server di test e di continuos integration hanno un ruolo molto
importante perche’ evidenziano i problemi che di solito non
emergono naturalmente nei team co-located
93. Cosa evitare
• Fare Scrum Team per componenti
• Il codice e’ di tutti, non del Team singolo, NO
CODICE PRIVATO
• Non esistono gruppi speciali: il gruppo degli
architect, il gruppo dei designer ecc I gruppi
sono Cross Funzionali
Feature Teams! SI’!
97. Come aiutare
• Fare un A3 della situazione con Value Stream
Mapping
• Affrontare un problema alla volta
• Non cercare di ottimizzare tutto subito
• Avere una spinta molto forte dai top-manager
• Cercare consenso dal basso
• Introdurre un Changing Agent
• Chiedere la consulenza di un Coach. Il Coach e’ una
persona che riduce di molto la fase di caos e poi se
ne va.
98. Una ricetta per Kanban
• Concentrarsi a rilasciare sempre software di Qualita':
TDD, Code Inspection, Arcihtecture and Design Patterns
e Software Factories
• Ridurre il Work-in-Progress (WIP)
• Rilasciare spesso
• Bilanciare la domanda di nuove funzionalita' con il lavoro
che si riesce a smaltire (Throughput)
• Dare priorita' alle cose
• Ridurre le cause di variabilita' migliorando la predicibilita'
da “Kanban: Successful Evolutionary Change for Your Technology Business”
100. La chiusura di un progetto
Raccogliere le lesson learned
Celebrare il successo e imparare degli errori
Non disperdere il know-how
http://www.svgopen.org/2008/papers/47-
Real_time_monitor_in_SVG_a_use_case_in_Machining_Technology_HMI/
104. Progetti
Progetti
Complessi Complessi
PPeerrssoonnee
Mercato e Requisiti
dinamici
Mercato e Requisiti
dinamici
Controllare il
Progetto
Controllare il
Progetto
Motivare il
Team
Motivare il
Team
Prodotti/Servizi di
Qualita’ e Valore
Prodotti/Servizi di
Qualita’ e Valore
A
G
I
L
E
!
Agile quando?
106. Diritti
Tutti i cartoon sono di
Michael Vizdos - www.implementingscrum.com.
Potete usare questo materiale come meglio ritenete opportuno secondo
la licenza Creative Common Attribution-ShareAlike 3.0
http://creativecommons.org/licenses/by-sa/3.0/
Trovate altro materiale su http://www.slideshare.net/GiulioRoggero/
I giochi qui utilizzati sono di mia concezione, li trovate Open Source:
•http://code.google.com/p/agile-the-board-game/
•http://code.google.com/p/a3-airplane-game/feeds