Agile Project Management - the Board Game workshop

Agile Project ManagementUn giornata di workshop con il gioco A gile: T he B oard Game Giulio Roggero - Scrum Master,PMI-ACP, PMP, Prince2

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

Documentazione?• La documentazione è importante, molto importante• E ’ im p o r t a n t e s e è v e r a• 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à?

Software!Software funzionante?Si/No/Forse/A volte si/Solo in questo caso no!

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 Firma e • Diritti di recesso approvazione • Penali 16/06/2011

… e dopo un mese? • Oggetto del contratto: O K • Elenco Specifiche: A, B, C, D , E • Dettaglio Specifiche: i n r e a l t à C è D +E e ora chi paga? • Assunzioni e Limiti • Tempi: 4 m o • Costi: 12 0 . 0 0 0 $ • Modalita’ di approvazione del prodotto/servizio • Pagamento Firma e approvazione • Diritti di recesso 16/06/2011 • Penali

Esercizio • L’azienda My Oil S.p.A. deve aggiornare il sistema di monitoraggio delle trivellazioni petrolifere secondo la norma che entrera’ i n v ig o r e f r a u n m e s e d a o g g i • 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 • N o n c i s o n o lim it i d i b u d g e tCome procedete?• 10’ per discussione• 5’ per gruppo di incontro con il signor White

Collaborazione con il cliente • Che bisogni ha il cliente? • Come lavora il cliente? • Cosa vede il cliente? • Come comunicare con lui? • Quali aspettative ha? Domande di difficile risposta1. Lavorare a stretto contatto con il cliente2. Respirare la stessa “aria”3. Avere le stesse aspettative Fa superare più facilmente la conflittualità intrinseca dei contratti

Esempi di contratti “Agili” • A f o r c h e t t a minima e massima (PERT aiuta) • A c o n d iv is io n e d e l r is c h io : 50%-50% sul budget risparmiato • A b a n d e : si concorda il budget, si fissa di volta in volta lo step a prezzo fisso • Tim e a n d m a t e r ia l classico

Storia eff Sutherland introdusse nel 1995 l’idea che i team si muovessero sull’orlo del caos e si auto- controllassero come succede in natura. jeffsutherland.com en presento’ con Jeff al OOPSLA95 il primo paper su SCRUM. ’ultima edizione e’ del gennaio 2011 http://jeffsutherland.com/ScrumPapers.pdfkenschwaber.wordpress.com li autori affermano che: “ S c rum non e ’ u n a m e t o d o lo g ia o u n

Scrum Roles

Product Owner Cosa fa Cosa non dovrebbe fare  Massimizza il valore di  Il project manager ogni Sprint  Sviluppare  Decide quali sono gli item  Decidere tecnologie e piu’ importanti di ogni processi Sprint  Puo’ cambiare le priorita’ di volta in volta  Raffina i backlog  Prende le decisioni che impattano sul prodotto

Team (pigs) 7 p e rs one ± 2 C r o s s - f u n z i o n a l e : non solo sviluppatori ma anche tester, interaction design, content managers e tutte le figure professionali necessarie per sviluppare un prodotto di valore P r e f e r i b i l m e n t e c o - l o c a t e d : riduce i tempi di comunicazione e migliora i rapporti del team F u l l - t i m e s u l p r o g e t t o : 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!

Team (pigs) Cosa fa Cosa non dovrebbe fare  Sviluppa il prodotto  Implementare item che non indicato dal product owner sono nell sprint backlog  Da idee al Product Owner  Aggiungere item allo sprint su come migliorare il backlog prodotto  Cambia spesso i suoi  Si auto-organizza membri all’interno dello sprint  Tiene traccia degli item di backlog completati  Stima gg per gg il backlog rimanente

Stakeholders (chickens) • Sono tutti gli appartenenti all’organizzazione che possono essere impattati dal progetto. • Possono partecipare ai meetings ma senza diritto di parola

Le persone del team belbin.com • “ P l a n t ” : creativa e brava a risolvere i problemi in modi non convenzionali. Uno per team. • M o n i t o r E v a l u a t o r : il logico, prende decisioni imparziali e pesa in modo razionale le opzioni del team. • C o -o r d i n a t o r s : aiuta a mantenere il focus del team, fa emerge i membri del team e delega in modo appropriato. • R e s o u r c e I n v e s t i g a t o r s : migliora i processi e porta la voce del team fuori. • I m p l e m e n t e r s : il motore che pianifica strategie efficaci e le porta a compimento. • C o m p l e t e r F i n i s h e r s : intervengo alla fine per completare il task rimuovendo errori e ottimizzando la qualita’. • Te a m w o r k e r s : sono il collante del team, si identificano con il team e aiutano nel lavoro di squadra. • S h a p e r s : il leader, fa in modo che il team non perda focus e spinta. • “ S p e c i a l i s t ” : ha una conoscenza molto specifica nella key area del

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!

Scrum Master Cosa fa Cosa non dovrebbe fare  Tutor del team  Il project manager  Aiuta Team e PO ad avere  Il team leader successo nel progetto  Il product owner  Protegge il Team dai fattori  Assegna Task esteri  Dice alle persone cosa fare  Facilita le relazioni  Toglie gli impedimenti  E’ al servizio del Team  Aiuta a capire il flow-value dello Scrum

Scrum roles – note importanti • Scrum Master e Productr Owner N O N possono essere lo stesso individuo • E il Project Manager? N O N E S I S T E ! • 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  A iu t a r e , s u p p o r t a r e , f a r e c o a c h in g e m e n t o r in g , r im u o v e r e g li im p e d im e n t i  E s s e r e a l s e r v iz io d e l t e a m !

Scrum Artifacts

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 N O N E S I S T E ! • Il product backlog evolve nel tempo: • Priorita’ • Descrizione e dettagli (raffinamento del Product Backlog) • Stime • N E E S IS T E U N O S O L O

Esempio – Product backlog

Cosa include • Funzionalità/requisiti cliente • Miglioramenti tecnici/tecnologici • Esplorazioni su nuovi aspetti del prodotto/del software • Bugs conosciuti

Come viene descritto• Scrum non definisce un metodo• Le u s e r s t o r i e s sono uno dei metodi piu’ usati• Si possono usare anche Work Breakdown Structure (WBS)• A volte viene creato un R e l e a s e B a c k l o g come sottoinsieme del BP per definire l’ambito della release del prodotto

User Story "As a <role>, I want <goal/desire> so that <benefit>"

Una user story su excel User Story ID Front Back Busin Priorit Estim ess y ated Value Story Point alarm.search "As a User I want to filters are TBD VH 5 search alarms by automatically added name, type, looking at column application, date, names and can be range of dates and combined in OR and free text search so AND (like workflow in that I can analyze console) problems on the system"

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

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 L a d e f in it io n o f d o n e N O N d e v e v a r ia r e d i v o lt a in v o lt a , e ’ f is s a ! U n a v o lt a c h e e ’ d e c is a s i s e g u e s e m p r e q u e lla .

PSPI P otentially S hippable P roduct I ncrement • Ogni Sprint idealmente finisce con un prodotto potenzialmente rilasciabile • M A I 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!

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

Previsioni e Stime1.Una previsione metereologica e’ valida 1-2 giorni2.Al terzo giorno e’ gia’ molto incerta• Oltre il terzo e’ una speculazione

Scrum Planning

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

Stime • Il Product Owner e’ responsabile per assegnare il b u s i n e s s v a l u e di ogni item del BP • Il Team e’ responsabile per stimare l ’ e f f o r t di sviluppo di ogni item del PB • Il Team e il Product Owner fanno un’analisi di r is c h io • Lo Scrum Master aiuta in questa fase • Scrum non definisce tecniche di stima • Story Points e Ideal Time • Range Estimation • PERT

Poker game con Fibonacci

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 t e a m c o n c o r d a c h e q u e lla v a le 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

Definizione di S u c c e s s o

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

Priorita’! 3 variabili Costo Valore Rischio Product Owner Priorita’ Priorita’ massima: minor costo, maggior valore (rischio minimo)

Eserciziow w w . a g ile m a n if e s t o . o r gI …a n d i … over p…and t..W … s … over d…C … c … over c…R . . To c … over p…

Esercizio Creare il product backlog con Agile: The Board Game

Tim e b o x in g e n o n s o loL O S P R IN T

Il tempo non basta mai sett 1 sett 2 sett 3 sett 4 sett 5 Done Done Done

Funziona? Pro Contro  Si pensa di essere piu’  Sotto stress produttivi  Ore piccole  Diversificare aiuta a non  Tempo perso nel cambio di annoiarsi contesto  Si puo’ star dietro a piu’ clienti  Si possono sfruttare i “tempi morti”

… e se fossimo monotasking? sett 1 sett 2 sett 3 sett 4 sett 5 Done Done Done

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

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

Scrum Workflow

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

Sprint Planning – Part 2 • D u r a t a : 2-4 ore • P a r t e c i p a n t i : Scrum Master, Team • S t r u m e n t i : Sprint Backlog a muro • O b i e t t i v o : definizione e stima dei task per lo Sprint Backlog

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

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

Sprint Review • Durata: 2-4 ore • Partecipanti: Product Owner, Scrum Master, Team • Strumenti: PSPI • Obiettivo: validare con il Product Owner la chiusura dello Sprint

Scrum Reporting

Report in Scrum • Product Burndown Chart • Sprint Burndown Chart • Test reports • Architecture diagram status

Trasparenza a diversi livelli • I Chicken N O N dovrebbero vedere lo Sprint Burndowchart • La trasparenza è sulle features completate • N O N su come il team si auto organizza • Lo sprint backlog è per il team, meglio su carta!

Velocity = 43 points in 10 days

Velocity

Esercizio Rilasciare con Scrum il primo PSPI Agile: The Board Game

Miglioramento continuoK A IZ E N

Lean • Ha origini dal TPS (To y o t a P r o d u c t i o n S y s t e m ) sviluppato tra il 1948-1975 • TP S s i b a s a s u • 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 • H a d u e p ila s t r i • Just-in-time • Automation • Due s c opi • Ridurre gli sprechi • Dare valore subito al cliente

Lean Flow Spostare l’attenzione dalla creazione del prodotto al processo produttivo: “ t h e p r o d u c t io n f lo w ” http://www.lean.org/WhatsLean/Principles.cfm

5 principi di Lean • Definire il valore, per ogni famiglia di prodotto, d a l p u n t o d i v is t a d e l c lie n t e f in a le . • Identificare i passi del value stream, per ogni famiglia di prodotto, e lim in a n d o p o s s ib ilm e n t e t u t t i g li s t e p c h e n o n c r e a n o v a lo r e . • Assicurarsi che i vari passi del value siano vicini e possano creare un flusso veloce verso il cliente finale. • Una volta che il value stream e’ attivato f a v o r i r e l ’ i n t e r v e n t o d e l c l i e n t e per atto ad aumentare il valore degli step. • Una volta che il valore e’ definito, il value stream identificato, gli sprechi rimossi e il flusso introdotto r i c o m i n c i a r e d i n u o v o il p r o c e s s o f in o a q u a n d o il v a lo r e e ’ p r o d o t t o s e n z a s p r e c h i.

Fresare Saldare Verniciare AssemblareValue Stream Mapping

10 maggiori cause di sprecoQualsiasi cosa che non aggiunge valore al clientefinale 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

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 

Bugs• Una lista molto lunga di bugs “vecchi” n o n a i u t a 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 n o n a i u t a a d a r e le g iu s t e p r io r it à Meglio mettere nel cassetto i bugs e riaprire il cassetto quando si avra’ il tempo Meglio non avere bugs!

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?

What you are talking about.Title:Background RecommendationsWhy are you talking about it? What is your proposed countermeasure(s)?Current Situation Where do we stand? PlanWhat’s the problem?Goal Where we need to be? What activities will be required for implementation and who will be What is the specific change you want to responsible for what and when? accomplish now?Analysis-What is the root cause(s) of the problem? Follow - up- How we will know if the actions have the impact needed? What remaining issues can be anticipated? A 3 - V e r b l e /S h o o k

Esercizio

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

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

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)

Esercizio Fare il meeting retrospective Agile: The Board Game

non solo SCRUMXP, L E A N E K A N B A N

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 proj sono molto utopici. ect

XP - e Xtre mep r o g r a m m in g

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

WIPRidurre 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

Kanban Board

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

Altro esempio di Kanban board

Scrum Scaling

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

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

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’!

Introdurre Agile in Azienda

Introdurre una metodologia Agile in Azienda

Fasi dell’introduzione

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.

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”

Conclusioni

La chiusura di un progettoRaccogliere le lesson learnedCelebrare il successo e imparare degli erroriNon disperdere il know-how http://www.svgopen.org/2008/papers/47- Real_time_monitor_in_SVG_a_use_case_in_Machining_Technology_HMI/

Le certificazioni Agile• S C RUM - w w w . s c r u m a llia n c e . o r g • Master • Practitioner • Coach • Trainer• P M I-A C P - w w w . p m i. o r g• A te rn D S D M - w w w .d s d m .o rg

Links e tools utili c a s i d u s o : www.scrumalliance.org/resources?tag=experience+report lib r i c o n s i g l i a t i : www.scrumalliance.org/pages/scrum_student_resource s p r e s e n t a z i o n i : www.scrumalliance.org/resources?tag=Presentations d o c s : www.scrumalliance.org/resources?tag=2010+Shanghai+Gathering f u m e t t i : www.implementingscrum.com/section/blog/cartoons/ c o n t r a t t i : agile rfp - www.methodsandtools.com/archive/archive.php? id=84 a g i l e m a n i f e s t o : agilemanifesto.org/iso/it/principles.html p m i : pmi.org l e a n : www.lean.org s c r u m a l l i a n c e : www.scrumalliance.org p e c h a - k u c h a : www.pecha-kucha.org/

Letture consigliate

Agile quando?ProgettiComplessi Persone Mercato e Requisiti A dinamici G I Prodotti/Servizi di L Motivare il Qualita’ e Valore EControllare ilProgetto Team !

Riferimenti Giulio Roggero roggero@intre.it www.intre.it http://it.linkedin.com/in/giulioroggero

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

http://isolasoftware.it	422
https://si0.twimg.com	1
http://www.lmodules.com	1
http://www.linkedin.com	1

Agile Project Management - the Board Game workshop

by Giulio Roggero on Jun 22, 2012

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 425

Statistics

Agile Project Management - the Board Game workshop Presentation Transcript