Your SlideShare is downloading. ×
Agile Project Management  - the Board Game workshop
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Project Management - the Board Game workshop

2,542
views

Published on

Agile workshop based on the board game "Agile: the Board Game" - …

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.

Published in: Business

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,542
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
86
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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à?
  • 4. Software! Software funzionante? Si/No/Forse/A volte si/Solo in questo caso no!
  • 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. 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
  • 11. Scrum Roles
  • 12. 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
  • 13. 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!
  • 14. 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
  • 15. Stakeholders (chickens) • Sono tutti gli appartenenti all’organizzazione che possono essere impattati dal progetto. • Possono partecipare ai meetings ma senza diritto di parola
  • 16. 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.
  • 17. 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!
  • 18. 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
  • 19. 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!
  • 20. Scrum Artifacts
  • 21. 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
  • 22. Esempio – Product backlog
  • 23. Cosa include • Funzionalità/requisiti cliente • Miglioramenti tecnici/tecnologici • Esplorazioni su nuovi aspetti del prodotto/del software • Bugs conosciuti
  • 24. 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
  • 25. User Story "As a <role>, I want <goal/desire> so that <benefit>"
  • 26. 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
  • 27. 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
  • 28. 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.
  • 29. 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!
  • 30. 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
  • 31. 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
  • 32. Scrum Planning
  • 33. 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
  • 34. 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
  • 35. Poker game con Fibonacci
  • 36. 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
  • 37. Definizione di Successo
  • 38. 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
  • 39. Priorita’! 3 variabili CCoosstoto VVaalolorree RRisiscchhioio PPrrioiorritiata’’ Product Owner Priorita’ massima: minor costo, maggior valore (rischio minimo)
  • 40. Esercizio www.agilemanifesto.org I…and i… over p…and t.. W… s… over d… C… c… over c… R.. To c… over p…
  • 41. Esercizio Creare il product backlog con Agile: The Board Game
  • 42. Timeboxing e non solo Lo SPRINT
  • 43. Il tempo non basta mai sett 1 sett 2 sett 3 sett 4 sett 5 DDoonnee DDoonnee DDoonnee
  • 44. 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
  • 45. … e se fossimo monotasking? sett 1 sett 2 sett 3 sett 4 sett 5 DDoonnee DDoonnee DDoonnee
  • 46. 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
  • 47. 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
  • 48. 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
  • 49. 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
  • 50. 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
  • 51. 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
  • 52. Sprint Review • Durata: 2-4 ore • Partecipanti: Product Owner, Scrum Master, Team • Strumenti: PSPI • Obiettivo: validare con il Product Owner la chiusura dello Sprint
  • 53. Scrum Reporting
  • 54. Report in Scrum • Product Burndown Chart • Sprint Burndown Chart • Test reports • Architecture diagram status
  • 55. 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!
  • 56. Velocity = 43 points in 10 days
  • 57. Velocity
  • 58. Esercizio Rilasciare con Scrum il primo PSPI Agile: The Board Game
  • 59. Miglioramento continuo KAIZEN
  • 60. 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
  • 61. Lean Flow Spostare l’attenzione dalla creazione del prodotto al processo produttivo: “the production flow” http://www.lean.org/WhatsLean/Principles.cfm
  • 62. 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.
  • 63. Fresare Saldare Verniciare Assemblare Value Stream Mapping
  • 64. 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
  • 65. 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 
  • 66. 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!
  • 67. 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?
  • 68. A3
  • 69. 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?
  • 70. Esercizio
  • 71. 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
  • 72. 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
  • 73. 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)
  • 74. Esercizio Fare il meeting retrospective Agile: The Board Game
  • 75. non solo SCRUM XP, LEAN E KANBAN
  • 76. 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.
  • 77. XP - eXtreme programming
  • 78. 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
  • 79. 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
  • 80. Kanban Board
  • 81. 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
  • 82. Altro esempio di Kanban board
  • 83. Scrum Scaling
  • 84. 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
  • 85. 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
  • 86. 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’!
  • 87. Introdurre Agile in Azienda
  • 88. Introdurre una metodologia Agile in Azienda
  • 89. Fasi dell’introduzione
  • 90. 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.
  • 91. 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”
  • 92. Conclusioni
  • 93. 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/
  • 94. Le certificazioni Agile • SCRUM - www.scrumalliance.org • Master • Practitioner • Coach • Trainer • PMI-ACP - www.pmi.org • Atern DSDM - www.dsdm.org
  • 95. Links e tools utili casi d'uso: www.scrumalliance.org/resources?tag=experience+report libri consigliati: www.scrumalliance.org/pages/scrum_student_resources presentazioni: www.scrumalliance.org/resources?tag=Presentations docs: www.scrumalliance.org/resources?tag=2010+Shanghai+Gathering fumetti: www.implementingscrum.com/section/blog/cartoons/ contratti: agile rfp - www.methodsandtools.com/archive/archive.php?id=84 agile manifesto: agilemanifesto.org/iso/it/principles.html pmi: pmi.org lean: www.lean.org scrum alliance: www.scrumalliance.org pecha-kucha: www.pecha-kucha.org/
  • 96. Letture consigliate
  • 97. 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?
  • 98. Riferimenti Giulio Roggero roggero@intre.it www.intre.it http://it.linkedin.com/in/giuli oroggero
  • 99. 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

×