• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Project Management
 

Agile Project Management

on

  • 5,167 views

Slide del mio corso di Project Management. Le slide sono continuamente in evoluzione. Questo e' l'aggiornamento al 4 Febbraio 2012.

Slide del mio corso di Project Management. Le slide sono continuamente in evoluzione. Questo e' l'aggiornamento al 4 Febbraio 2012.

Statistics

Views

Total Views
5,167
Views on SlideShare
4,363
Embed Views
804

Actions

Likes
11
Downloads
212
Comments
1

7 Embeds 804

http://www.associazioneinmedia.it 545
http://isolasoftware.it 250
http://www.yatedo.fr 4
http://www.docshut.com 2
http://207.46.192.232 1
http://www.yatedo.com 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Grazie per la ricca presentazione. Sto vivendo un progetto software complesso con metodologia Agile (AUP), cercando di far tutti del proprio meglio. Trovo difficoltà nel fare PM in particolare nel comprendere, se non per esperienza e sensazione, quanto manca al completare il progetto. Gli avanzamenti che di fatto vengono fatti rilevandoli dal team a fine iterazione, mal si sposano con la rappresentazione classica di progetto tramite Gantt...
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile Project Management Agile Project Management Presentation Transcript

    • Agile Project Management Metodologie nuove per gestire progetti complessiSunday, February 5, 12
    • Wallenstein VS GiantsSunday, February 5, 12
    • WallensteinCi troviamo nel 1618, alla vigiliadella Guerra dei Trent’Anni, icinque più potenti mercenaridell’epoca si sfidano nella conquistadell’europa centrale.Vince chi totalizza piu’ punti•1 punto viene assegnato per ogni territorio in proprio possesso.•1 punto viene assegnato per ogni edificio costruito sui territori posseduti.•1 punto viene assegnato al giocatore con più Mercati in ognuna delle cinque regioni.•2 punti vengono assegnati al giocatore con più Cattedrali in ognuna delle cinque regioni.•3 punti vengono assegnati al giocatore con più Castelli in ognuna delle cinque regioniSunday, February 5, 12
    • Wallenstein – durante il giocoSunday, February 5, 12
    • Wallenstein - meccanica Tutti i giocatori hanno, nel turno (tranne in inverno), queste dieci azioni da compiere, una sola per ogni territorio posseduto: 1. Costruire un Mercato 2. Costruire una Cattedrale 3. Costruire un Castello 4. Primo Movimento (spostamento o attacco) 5. Secondo Movimento (spostamento o attacco) 6. Raccogliere le tasse* 7. Raccogliere il grano * 8. Assoldare cinque armate 9. Assoldare tre armate 10. Assoldare un armata e fare uno spostamento *Il raccogliere tasse e grano causa lo scontento della popolazione che potrebbe rivoltarsi Tutti i giocatori sceglieranno, contemporaneamente dove e quali azioni esercitare. Successivamente verrà stabilito l’ordine di gioco, verrà deciso mischiando e posando sul tavolo di gioco le carte giocato.Sunday, February 5, 12
    • GiantsCi troviamo sull’Isola di Pasqua tra ulV e il XVII secolo. La civita’RapaNui costruisce degli incredibilimonumenti funerari, gli Ahus (ahoo).Questi monoliti sono scolpiti da unasola pietravulcanica ed eretti sulle spondedell’isola.Il gioco consiste nel costruire imonumenti funerari in modocollaborativo. Chi mette adisposizione piu’ risorse e/omanodopera e/o erige piu’ Ahus vince.Sunday, February 5, 12
    • Giants - meccanica Ogni giocatore puo’ compiere piu’ azioni per turno: • Piazzare un lavoratore, uno stregone o un capo • Fare una stregoneria • Erigere un Ahus I giocatori possono usare i lavoratori e i pali di legno piazzati dali altri giocatori per trasportare gli Ahus vicino alla sponda dell’Isola. Ogni volta che viene usato il lavoratore di un altro giocatore questo guadagna dei puntiSunday, February 5, 12
    • E’ un processo Agile? Requisito 1 Requisito 2 Analisi Design Sviluppo Test Rilascio Requisito 3 Requisito 4Sunday, February 5, 12
    • E’ un processo Agile? Requisito 1 Requisito 2 Analisi Design Sviluppo Test Rilascio Requisito 3 Iterazione 2 Sviluppo Test Requisito 4 Iterazione n Sviluppo TestSunday, February 5, 12
    • E’ un processo Agile? Requisito 1 Requisito 2 Analisi Design Sviluppo Test Rilascio Requisito 3 Iterazione 2 Design Sviluppo Test Requisito 4 Iterazione n Design Sviluppo TestSunday, February 5, 12
    • E’ un processo Agile? Requisito 1 Analisi Design Test Sviluppo Refactoring Rilascio Requisito 2 Analisi Design Test Sviluppo Refactoring Rilascio Requisito 3 Analisi Design Test Sviluppo Refactoring Rilascio Requisito 4 Analisi Design Test Sviluppo Refactoring RilascioSunday, February 5, 12
    • Benvenuti al CORSO SU AGILE!Sunday, February 5, 12
    • Chi sei? Cosa fai? Cosa farai dopo il corso? Cosa ti piacerebbe fare tra cinque anni? Cosa ti aspetti dal corso?Sunday, February 5, 12
    • Temi I Introduzione generale: framework e processi per il Project Management. Lean e Agile: valori e principi. Gemba. Definition of Done. Time Boxing. Kaizen. Kanban. Scrum: Lean, Agile applicati. Le tre gambe di Scrum. Overview, Ruoli e Workflow. XP: Ruoli, Attivita’ e Pratiche. Stimare Costi e Tempi: User Stories, Story Point e Poker Game. Risk Management e Communication Management Da PMP ad Agile: un modo pratico per introdurre Agile nel team.Sunday, February 5, 12
    • ApprofondimentiAgile and Scrum Anti-Patterns: cosa si pensa comunemente di Agile e Scrum che in realta’ non e’ veroSelf organizing teams: esempi reali di aziende auto organizzatePomodoro: tecnica di gestione del tempo e dei task day by dayGemba, Kaizen e Kanban: alcuni metodi introdotto in Toyota e riadattato a diverse realta’ industriali e di serviziForme contrattuali agili: se vogliamo essere agili dobbiamo esserlo anche nei contrattiMindmapsSunday, February 5, 12
    • Una sorpresa...Sunday, February 5, 12
    • Obiettivi1. Diventare Agile Project Manager2. Conoscere i 4 Valori e i 12 Principi di Agile3. Definire e riconoscere le 10 ragioni di spreco secondo Lean4. Conoscere e fare coaching di Uno Scrum Workflow Degli Scrum Roles Delle fasi di stima e pianificazione Agile5. Creare e mantenere un Product Backlog6. Spiegare le ragioni di perche’ adottare Agile7. Analizzare e spiegare perche’ un’azienda non riesce ad applicare AgileSunday, February 5, 12
    • Altri temi? Vostre proposte....................Sunday, February 5, 12
    • IntroduzioneSunday, February 5, 12
    • Approcci di PM - Predittivo Alcuni esempi Waterfall Spirale Unified Process (RUP) PMBoKSunday, February 5, 12
    • Predittivo – Si’/No Pro Contro • Logico e sensato • Sono coinvolte le • Pianifica prima di fare persone! • Mantiene una – Cambiano idea documentazione scritta – Difficile esprimere e comunicare l’intangibile e i • Segue un piano bisogni • Mantiene le attivita’ – Empatia organizzate • Prodotto solo alla fineSunday, February 5, 12
    • Approcci di PM - AdattivoAlcuni esempi XP Scrum FDD TDD Lean PredittiviSunday, February 5, 12
    • Adattivo – Si’/No Pro Contro • Segue le persone • Difficile da introdurre • Apporta valore • Senza uno sponsor non • Aiuta la collaborazione decolla • Riduce le barriere • Difficile coinvolgere il clienteSunday, February 5, 12
    • Wallenstein VS Giants Predittivo AdattivoSunday, February 5, 12
    • Quale scegliere? Negli ultimi 30 XP anni si sono alternati approcci Agile differenti Waterfall RUP Kanban Tutti hanno avuto successi e insuccessiSunday, February 5, 12
    • Osservare Assimilare Riealaborare Migliorare ContinuamenteSunday, February 5, 12
    • 3 lavori predittivi 3 lavori adattiviSunday, February 5, 12
    • Problemi nei progetti • Mancanza della gestione del cambiamento dei requisiti • Cattiva comunicazione • Inadeguatezza del Team • Requisiti non ben definiti • Stime non accurate • Mancanza di un piano di gestione dei Rischi • Cattiva definizione di cosa significa “Finito” • Non dedicare il giusto tempo alla gestione del progetto • Mancanza della conoscenza di come si gestisce un progetto • Essere sempre troppo ottimisti!Sunday, February 5, 12
    • Ottimismo!Sunday, February 5, 12
    • COCOMO II Fattori che influenzano la produttivita’ nel software su prj da 100 KSLOC. Migliorare i sw tools tipicamente migliora del 50% la produttivita’. Migliorare il team il 353%! SOFTWARE SEPTEMBER/OCTOBER 2000 (Vol. 17, No. 5) pp. 14-17 0740-7459/00/$26.00 © 2000 IEEE Published by the IEEE Computer Society Safe and Simple Software Cost AnalysisSunday, February 5, 12
    • Principali fattori di Successo Team + Sponsorship + ClienteSunday, February 5, 12
    • Definizione di SuccessoSunday, February 5, 12
    • Successo Il successo in Agile e’ misurato sul valore generato dal progettoIl valore dipende dal contesto del progetto ed e’ definito con il ClienteSunday, February 5, 12
    • Cercate produttuvita’? Agile non fa per voi! Agile e’ per: •Apportare facilmente cambiamenti •Creare velocemente valore •Aumentare la transparenzaSunday, February 5, 12
    • Agile non e’• Poca o nessuna documentazione• Requisiti di massima• Nessuna pianificazione• Nessun controllo di progetto• Fare e poi pensare• Un waterfall interattivoSunday, February 5, 12
    • Agile e’• Uno specchio della realta’• Un processo guidato dal valore• Un continuo adattamento agli input esterni (requisiti, aspettative, ambito) con lo scopo di massimizzare il valore globale dell’output (prodotto/servizio/ qualita’/soddisfazione)Sunday, February 5, 12
    • Lean e AgileSunday, February 5, 12
    • 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 planSunday, February 5, 12
    • Tools e ProcessiQuale tool usiamo per tracciare lo stato del progetto?Che processo adottiamo per rilasciare una versione?Come tracciamo i bugs?Come tracciamo le ore su un progetto?Come misuriamo le performance delle persone sul progetto?Come formalizziamo con il cliente la chiusura del progetto?Tutte domande che vi siete fatti almeno una volta…… che soluzioni avete trovato e adottato?Sunday, February 5, 12
    • Teoria della comunicazione Feedback CC Einar Faanes funzione referenziale (contesto) funzione emotiva (mittente) funzione conativa (destinatario) funzione fàtica (contatto) funzione poetica (messaggio) funzione metalinguistica (codice)Sunday, February 5, 12
    • Teoria dell’ottimizzazioneOttimizzazione molti-obiettivi conflittualiDiverse alternative, diversi decisori, diversi criteriNon esiste l’ottimo assoluto ma un compromessoL’ottimizzazione locale dei singoli criteri non portaSunday, February 5, 12
    • Esempio di analisi multi-criteri alternatives criteriaSunday, February 5, 12
    • Sunday, February 5, 12
    • Individui e Interazioni Comunicare, comunicare, comunicare! Tanti documenti, anche ben scritti e formalizzati non servono se non sono letti e compresi Presentazioni senza coinvolgere i partecipanti non sono efficaci se non si ha la sicurezza che il messaggio sia compreso Team building Pensare “al proprio orticello” non aiuta il progetto Molto spesso lavori complessi hanno bisogno di piu’ occhi Lavorare in un ambiente armonioso aiuta il progetto Ottimizzare il globale e non il singolo Misurare il singolo spinge a non collaborare Non e’ detto che se tutti sono ottimali il progetto e’ ottimaleSunday, February 5, 12
    • Interazioni VS Tools? NO! VS I tool sono importanti se rispecchiano il modo di lavorare del team Devono ridurre quasi a zero il tempo e il costo delle operazioni ripetitive Agevolare la comunicazione remota Rendere trasparente il progettoCONSIGLIO:prima capire le persone e come lavorano poi scegliere i tools di supporto.Sunday, February 5, 12
    • esercizio camminiamoSunday, February 5, 12
    • 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 planSunday, February 5, 12
    • Documentazione? La documentazione e’ importante, molto importante E’ importante se e’ vera Il progetto evolve la documentazione non sempre! E’ un costo molto alto tenere aggiornata la documentazioneIn un progetto software qual’e’ il documento cherispecchia meglio la realta’?Sunday, February 5, 12
    • Software! Software funzionante? Si/No/Forse/A volte si/Solo in questo caso no!Sunday, February 5, 12
    • Metodi di TestingUnit TestingIntegration TestingUser TestingInteraction Testing TDD  Test driver developmentSunday, February 5, 12
    • ContrattoOggetto del contrattoElenco Specifiche: A, B, CDettaglio SpecificheAssunzioni e LimitiTempi: 3 moCosti: 100.000$Modalita’ di approvazione del prodotto/servizioPagamentoDiritti di recessoPenali Firma e approvazione 16/06/2011Sunday, February 5, 12
    • … e dopo un mese? Oggetto del contratto: OK Elenco Specifiche: A, B, C, D, E Dettaglio Specifiche: in realta’ C e’ D+E Assunzioni e Limiti Tempi: 4 mo e ora chi paga? Costi: 120.000$ Modalita’ di approvazione del prodotto/servizio Pagamento Diritti di recesso Penali Firma e approvazione 16/06/2011Sunday, February 5, 12
    • esercizioL’azienda Trivellazioni Felici S.p.A. deve aggiornare il sistema di monitoraggio delle trivellazioni petrolifere secondo la norma che entrera’ in vigore fra un mese da oggiIl signor White e’ l’incaricato di Trivellazioni Felici per fornirvi tutte le informazioni necessarie, l’importante e’ che il nuovo sistema sia operativo in tutte le 100 sedi entro un meseNon ci sono limiti di budget Come procedete? • 10’ per discussione • 5’ per gruppo di incontro con il signor WhiteSunday, February 5, 12
    • 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 aspettativeFa superare piu’ facilmente la conflittualita’ intrinseca dei contrattiSunday, February 5, 12
    • Esempi di contratti “Agili” •A forchetta minima e massima (PERT aiuta) •A bande: si concorda il budget, si fissa di volta in volta lo step a prezzo fisso •Time and material classicoSunday, February 5, 12
    • PianoGantt?PERT?Milestones?Project Management Plan?Analisi dei Requisiti? Quante volte questi piani sono stravolti il giorno dopo che sono stati scritti?Sunday, February 5, 12
    • Valore?Cos’e’ per il Cliente il valore? Un servizio/un prodotto che apporta valore al proprio business Aumenta la competitivita’ Riduce i costi Aumenta i ricavi Aumenta la penetrazione di mercato Alza le barriere di ingresso ai competitor Crea nuovi mercati Ecc… Questi valori sono scolpiti nella pietra o variano nel tempo?Sunday, February 5, 12
    • Progetti falliti* ma di valoreProgetto falliti (fuori budget, scope o time) hanno portato valore in azienda. Ecco alcuni esempi: Post-it Facebook GMail * nella accezzione di Scope-Cost-ScheduleSunday, February 5, 12
    • Teoria del controllo Misurare l’output per calibrare gli input  Verificare il software funzionante per validare i requisiti implementati e pianificatiSunday, February 5, 12
    • Quindi? Piano o Valore? VS•Una pianificazione e’ fondamentale•Ma la pianificazione deve poter variare senza impattare sul progetto•Rispondere ai cambiamenti permette di tenere sotto controllo il vero progetto: •Quello che apporta valore •Soddisfa le aspettativeAgile e’ pianificazione con un controllore retroattivoSunday, February 5, 12
    • Esercizio www.agilemanifesto.orgI…and i…  over p…and t..W… s… over d…C… c… over c…R.. To c… over p…Sunday, February 5, 12
    • ScrumSunday, February 5, 12
    • Cosa non e’ scrum Scrum != Ad HocScrum non e’ una scusa per far meno e costare meno: - “Non abbiamo bisogno di analisi dei requisiti” - “Non abbiamo bisogno di stime” - “Siamo agili!” O! L S FASunday, February 5, 12
    • Una formula per Scrum?Scrum = timeboxed iteration + backlogs + meeting giornalieri NON BASTA SOLO QUESTO! Implemetare Agile?  NO Implementare Scrum ed essere Agili  SI’Sunday, February 5, 12
    • Ambito Aspettative Necessita e Bisogni Lean • 5 Principici • 10 Cause di Spreco Cliente Team Agile • 4 Valori • 12 Principi ValoreSunday, February 5, 12
    • 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 jeffsutherland.com 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 unkenschwaber.wordpress.com 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”Sunday, February 5, 12
    • Sunday, February 5, 12
    • Most common methodologies Dic 2008Sunday, February 5, 12
    • 2008Sunday, February 5, 12
    • Obiettivi di Scrum1. Energia2. Concentrazione sugli obiettivi3. Chiarezza4. Transparenza Auto organizzarsi! INSIEME!Sunday, February 5, 12
    • Aiuta a•Aumentare la velocita’ di sviluppo•Allineare il progetto con le esigenze del business•Creare valore in azienda•Comunicare in modo costante e trasparente a tutti i livelli aziendali•Migliorare l’ambiente di lavoro delle personeSunday, February 5, 12
    • Le tre gambe di ScrumTrasparenzaIspezioneAdattamentoSunday, February 5, 12
    • Dove si inserisce ScrumSunday, February 5, 12
    • Sunday, February 5, 12
    • Scrum RolesSunday, February 5, 12
    • 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 prodottoSunday, February 5, 12
    • 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!Sunday, February 5, 12
    • Team (pigs) Cosa fa Cosa non dovrebbe fare  Sviluppa il prodotto  Implementare item che indicato dal product owner non sono nell sprint  Da idee al Product Owner backlog su come migliorare il  Aggiungere item allo sprint prodotto backlog  Si auto-organizza  Cambia spesso i suoi all’interno dello sprint membri  Tiene traccia degli item di backlog completati  Stima gg per gg il backlogSunday, February 5, 12
    • Stakeholders (chickens) Sono tutti gli appartenenti all’organizzazione cheSunday, February 5, 12
    • 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.Sunday, February 5, 12
    • 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 puo’ essere un membro del Team•ATTENZIONE PM o Team Leaders che diventate Scrum Master: dovete cambiare molto il vostro approccio, e’ un lavoro completamente diverso! Favorire l’auto-organizzazione!Sunday, February 5, 12
    • 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  Assegna Task fattori esteri  Dice alle persone cosa  Facilita le relazioni fare  Toglie gli impedimenti  E’ al servizio del Team  Aiuta a capire il flow-valueSunday, February 5, 12
    • Scrum roles – note importantiScrum Master e Productr Owner NON possono essere lo stesso individuoE il Project Manager? NON ESISTE!I ruoli di PM sono divisi tra i tre ruoli di Scrum: Scrum Master Product Owner TeamUn cambio di approccio e’ fondamentale!Da assegnare attivita’, verificare lo stato a Aiutare, supportare, fare coaching e mentoring, rimuovere gli impedimenti Essere al servizio del team!Sunday, February 5, 12
    • Scrum ArtifactsSunday, February 5, 12
    • Sunday, February 5, 12
    • Product BacklogLista di features con priorita’Roadmap del prodottoResponsabilita’ del Product OwnerTutto quello che e’ nel Product backlog e’ il prodottoQuello fuori NON ESISTE!Il product backlog evolve nel tempo: Priorita’ Descrizione e dettagli (raffinamento del Product Backlog) StimeNE ESISTE UNO SOLOSunday, February 5, 12
    • Esempio – Product backlogSunday, February 5, 12
    • Cosa include Funzionalita’/requisiti cliente Miglioramenti tecnici/tecnologici Esplorazioni su nuovi aspetti del prodotto/del software Bugs conosciutiSunday, February 5, 12
    • Come viene descrittoScrum non definisce un metodoLe user stories sono uno dei metodi piu’ usatiSi 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 prodottoSunday, February 5, 12
    • User Story "As a <role>, I want <goal/desire> so that <benefit>"Sunday, February 5, 12
    • Sunday, February 5, 12
    • User Story ID Front Back Busin Priori Estim ess ty ated Value Story Point alarm.searc "As a User I want to filters are TBD VH 5 h search alarms by automatically name, type, added looking at application, date, column names and range of dates and can be combined in free text search so OR and AND (like that I can analyze workflow in problems on the console) system"Sunday, February 5, 12
    • 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 volontarioSunday, February 5, 12
    • Product Backlog a muroSunday, February 5, 12
    • Sunday, February 5, 12
    • 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 utenteSunday, February 5, 12
    • PSPIPotentially Shippable Product IncrementOgni Sprint idealmente finisce con un prodotto potenzialmente rilasciabileMAI lasciare le cose a meta’: meglio chiudere una cosa in meno e spostarla nel prossimo sprint che lasciare le cose aperte a fine sprintChiudere sempre secondo la Definition of Done concordata!Sunday, February 5, 12
    • 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’apprendimentoSunday, February 5, 12
    • Un momento di analisi del ProductSunday, February 5, 12
    • Architettura emergenteSunday, February 5, 12
    • Esercizio Creare il product backlog per la presentazione di un’idea di applicazione iPad che favorisca la diffusione di Agile e di ScrumSunday, February 5, 12
    • Scrum WorkflowSunday, February 5, 12
    • OverviewSunday, February 5, 12
    • 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 sprintSunday, February 5, 12
    • Sprint Planning – Part 2Durata: 2-4 orePartecipanti: Scrum Master, TeamStrumenti: Sprint Backlog a muroObiettivo: definizione e stima dei task per lo Sprint BacklogSunday, February 5, 12
    • Sunday, February 5, 12
    • Running the Sprint  Durata: 1-6 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 dettaglioSunday, February 5, 12
    • 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 riunioniSunday, February 5, 12
    • Sprint Review  Durata: 2-4 ore  Partecipanti: Product Owner, Scrum Master, Team  Strumenti: PSPI  Obiettivo: validare con il Product Owner la chiusura dello SprintSunday, February 5, 12
    • 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 processoSunday, February 5, 12
    • Previsioni e Stime 1.Una previsione metereologica e’ valida 1-2 giorni 2.Al terzo giorno e’ gia’ molto incerta 3.Oltre il terzo e’ una speculazioneSunday, February 5, 12
    • Scrum PlanningSunday, February 5, 12
    • 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 fondamentaliRiflettere sulle sitme a posteriori aiuta a stimare meglio la volta dopoSunday, February 5, 12
    • Poker game con FibonacciSunday, February 5, 12
    • 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 • PERTSunday, February 5, 12
    • 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 selezionateSunday, February 5, 12
    • Stime - PERT ID     Days --> optim likely worst pert var Global um 1             1.1 Analysis Analysi 1,00 1,00 1,00 1,00 0,00 1.2 s Design 2,00 2,00 2,00 2,00 0,00 2 Codin               2.1 g Desktop       2.1.1container Window Manager 1,00 2,00 2,00 1,83 0,17 2.1.2 Background 0,20 0,50 1,00 0,53 0,13 2.1.3 Screen resize 0,20 0,20 0,50 0,25 0,05 2.1.4 HTML Integration 0,10 0,20 0,50 0,23 0,07 2.1.5 Unit Testing 0,50 1,00 1,00 0,92 0,08Sunday, February 5, 12
    • Re-stimareSunday, February 5, 12
    • Risk analysis Tenere un registro dei rischi del progetto Stimare un peso dell’impatto Stimare una probabilita’ che il rischio possa manifestarsi Definire dei piani di contigency Attribuire dei responsabili ad ogni rischio Si possono usare analisi di Montecarlo (vedi Riskology - http://www.systemsguild.com/riskology)  Tutte le attivita’ di risk vanno nello Sprint BacklogSunday, February 5, 12
    • Esempio di Risk register Risk Risk Probability Impact Risk Name Risk Score Mitigation Contingency Action By Action When Category Number (1-3) (1-3) Invite crazy The guests friends, Bring out Guests find the 1.1. 2 2 4 provide Mack within 2hrs the karaoke party boring sufficient liquor Don’t invite crazy Drunken Bring in the Guests 1.2. 1 3 3 friends, Jerry Now brawl dont provide guards too much liquor *da wikipediaSunday, February 5, 12
    • Priorita’! 3 variabili Costo Valore Rischio Product Owner Priorita’ Priorita’ massima: minor costo, maggior valore (rischio minimo)Sunday, February 5, 12
    • Esercizio Fare la stima del vostro product backlogSunday, February 5, 12
    • Scrum ReportingSunday, February 5, 12
    • Report in ScrumProduct Burndown ChartSprint Burndown ChartTest reportsArchitecture diagram statusSunday, February 5, 12
    • Trasparenza a diversi livelliI Chicken NON devono vedere lo Sprint Burndowchart La trasparenza e’ sulle features completate NON su come il team si auto organizzaLo sprint backlog e’ per il team, meglio su carta!Sunday, February 5, 12
    • Velocity = 43 points in 10 daysSunday, February 5, 12
    • VelocitySunday, February 5, 12
    • Alcuni scrum anti-patterns•Ottimizzazione prematura del processo Scrum•Accumulare lavoro non fatto e continuare a farne di nuovo•Lavorare come singoli paladini e non in Team•Piu’ di un Product Owner•Nessun Stakeholder•“Copiate e migliorate quello che c’era prima”•Nuove storie sono aggiunte allo Sprint backlog durante lo sprint (con la scusaSunday, February 5, 12
    • 12 Principi di Agile http://agilemanifesto.org/iso/it/principles.htmlSunday, February 5, 12
    • “La nostra massima priorità è soddisfare il cliente Unit Tesing + rilasciando software Continuos Integration di valore, fin da subito e in maniera continua.” Jenkins-CISunday, February 5, 12
    • EsercizioSunday, February 5, 12
    • “Accogliamo i cambiamenti nei requisiti, Prendere le decisioni anche a stadi avanzati architetturali il piu’ tardi possibile per dello sviluppo. poterle cambiare I processi agili sfruttano quando serve. Prendere le decisioni il cambiamento di valore. a favore del vantaggio Semplicita’!!!! competitivo del cliente.”Sunday, February 5, 12
    • “Consegnamo Ritmo e buone abitudini frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.”Sunday, February 5, 12
    • “Committenti e sviluppatori devono lavorare insieme Stesso ufficio quotidianamente per openspace tutta la durata del oppure progetto.” Video conferenzeSunday, February 5, 12
    • “Fondiamo i progetti su No incentivi singoli individui motivati. Incentivi sul team Trasparenza Diamo loro lambiente e Comunicazione il supporto di cui hanno Autonomia Fiducia bisogno e confidiamo nella loro capacità di portare il lavoro a termine.”Sunday, February 5, 12
    • “Una conversazione Non dire le cose per faccia a faccia email quando si è il modo più possono dire di persona efficiente e più efficace per comunicare con il team ed allinterno del team.”Sunday, February 5, 12
    • “Il software funzionante I feedback del cliente è il principale metro di sono la piu’ grande misura di progresso.” misura del successo del progettoSunday, February 5, 12
    • “I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.” Ritmo sostenibileSunday, February 5, 12
    • “La continua attenzione alleccellenza tecnica e alla buona progettazione Eccellenza e esaltano lagilità.” progettazione portano alla semplicita’Sunday, February 5, 12
    • “La semplicità - larte di massimizzare la quantità Imports System.Console Class HelloWorld di lavoro non svolto Public Shared Sub Main() WriteLine("Hello, world!") - è essenziale.” End Sub End Class print "Hello World"Sunday, February 5, 12
    • ANTI-IF CAMPAGN esercizioSunday, February 5, 12
    • “Le architetture, i requisiti e la progettazione migliori emergono da team che si No micro gestione Si’ ritmo e abitudini auto-organizzano.” No best practices Si’ preferred practicesSunday, February 5, 12
    • “A intervalli regolari il Essere leali e obiettivi team riflette su come Saper gioire per i successi diventare più efficace, Saper riconoscere gli dopodiché regola e sbagli adatta Non vivere con il proprio l’incubo dell’errore ma con la consapevolezza comportamento di di saper riconoscere e conseguenza.” correggere gli erroriSunday, February 5, 12
    • 5 WHYs esercizioSunday, February 5, 12
    • Esercizio A coppie scrivere su un foglio a muro • 4 valori di Agile • 12 principi sottostanti ad AgileSunday, February 5, 12
    • Simuliamo un progetto Agile Agile: The Board GameSunday, February 5, 12
    • 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.Sunday, February 5, 12
    • XP - eXtreme programmingSunday, February 5, 12
    • 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 sempliceSunday, February 5, 12
    • 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•Uno scopo •Ridurre gli sprechi •Dare valore subito al clienteSunday, February 5, 12
    • Lean Flow Spostare l’attenzione dalla creazione del prodotto al processo produttivo: “the production flow” http://www.lean.org/WhatsLean/Principles.cfmSunday, February 5, 12
    • 5 principi di Lean1.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.Sunday, February 5, 12
    • Fresare Saldare Verniciare Assemblare Value Stream MappingSunday, February 5, 12
    • EsercizioSunday, February 5, 12
    • 10 maggiori cause di sprecoQualsiasi 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’ razionaliSunday, February 5, 12
    • InboxLa 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 Sunday, February 5, 12
    • BugsUna 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 priorita’ Meglio mettere nel cassetto i bugs e riaprire il cassetto quando si avra’ il tempo Meglio non avere bugs!Sunday, February 5, 12
    • GembaIn Toyota e’ la pratica di andare a vedere la linea di produzioneI manager non guardano email, grafici, report, ma direttamente la linea di produzioneI problemi sono vissuti sul campo, ci si rende conto della complessita’ e delle persone. Nei progetti software cos’e’ il Gemba?Sunday, February 5, 12
    • A3Sunday, February 5, 12
    • What you are talking about. Title: Background Recommendations Why 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 responsible for what and when? to accomplish now? Analysis -What is the root cause(s) of the Follow - up problem? - How we will know if the actions have the impact needed? What remaining issues can be anticipated? A3 -Verble/ShookSunday, February 5, 12
    • EsercizioSunday, February 5, 12
    • Title: Background Recommendations Current Situation Plan  Goal Analysis Follow - up A3 -Verble/ShookSunday, February 5, 12
    • Il tempo non basta mai sett 1 sett 2 sett 3 sett 4 sett 5 Done Done DoneSunday, February 5, 12
    • Funziona? Pro Contro  Si pensa di essere piu’  Sotto stress produttivi  Ore piccole  Diversificare aiuta a non  Tempo perso nel cambio annoiarsi di contesto  Si puo’ star dietro a piu’ clienti  Si possono sfruttare i “tempi morti”Sunday, February 5, 12
    • … e se fossimo monotasking? sett 1 sett 2 sett 3 sett 4 sett 5 Done Done DoneSunday, February 5, 12
    • Pomodoro Technique1. Scegli il task da completare2. Imposta il Pomodoro a 25 minuti (Il Pomodoro è il timer)3. Lavora sul task senza distrazioni o interruzioni fino a che il Pomodoro non suona, dopo metti una spunta nel tuo foglio della To Do List4. Prenditi un piccolo break (5 minuti vanno bene)5. Ogni 4 pomodori prenditi una pausa un po più lunga www.pomodorotechnique.comSunday, February 5, 12
    • 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 costoSunday, February 5, 12
    • 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 aziendaSunday, February 5, 12
    • Kanban BoardSunday, February 5, 12
    • 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 naturaSunday, February 5, 12
    • Altro esempio di Kanban boardSunday, February 5, 12
    • Sunday, February 5, 12
    • Agile anti-patternsNever meeting iteration commitmentsTesting latePoor estimatingNot trying to improveNot assigning action items http://www.agileforall.com/2009/06/03/agile-antipattern- insanity-5-insanity-antipatterns/ http://agileantipatterns.com/Sunday, February 5, 12
    • Scrum# E’ una evoluzione di Scrum ponendo Scrum all’interno del Lean Thinking Rilassa certi aspetti a seconda dei progetti. Es: Iterazioni: time boxed oppure flow-based. Prodotto: il team e’ responsabile del prodotto. Management: i manager guida e fa coach al team. Si lavora insieme. Imparare: dal modello del flow con la big picture sempre presente. Priorita’: non solo valore per il cliente ma anche sulla riduzione degli sprechi. Continuos Integration: build che funzionano in automatico Acceptance Test: definiti prima di codificare. Limitare il WIP: non iniziare nuove storie se non sono concluse quelle precendenti.Sunday, February 5, 12
    • Scrum ScalingSunday, February 5, 12
    • Scrum di ScrumOgni team lavora con un suo ScrumOgni settimana un membro del team si incontra con gli altri membri degli altri team per fare un Daily meetingPuo’ essere scalato in modo indefinitoI rappresentanti possono cambiare di volta in voltaSunday, February 5, 12
    • Team VirtualiE’ possibile applicare Scrum da remoto su team dislocati geograficamentiE’ difficile farlo funzionareI tools di comunicazione sono fondamentali, devono permettere un editing live degli oggetti (es: Google Docs)Chat, Call e Video Call devono essere sempre accessibiliIl repository del codice sempre condivisoI 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-locatedSunday, February 5, 12
    • Cosa evitareFare Scrum Team per componentiIl codice e’ di tutti, non del Team singolo, NO CODICE PRIVATONon esistono gruppi speciali: il gruppo degli architect, il gruppo dei designer ecc  I gruppi sono Cross Funzionali Feature Teams! SI’!Sunday, February 5, 12
    • Introdurre Agile in AziendaSunday, February 5, 12
    • Introdurre una metodologia Agile in AziendaSunday, February 5, 12
    • Sunday, February 5, 12
    • Come aiutareFare un A3 della situazione con Value Stream MappingAffrontare un problema alla voltaNon cercare di ottimizzare tutto subitoAvere una spinta molto forte dai top-managerCercare consenso dal bassoIntrodurre un Changing AgentChiedere la consulenza di un Coach. Il Coach e’ una persona che riduce di molto la fase di caos e poi se ne va.Sunday, February 5, 12
    • Una ricetta per Kanban1. Concentrarsi a rilasciare sempre software di Qualita: TDD, Code Inspection, Arcihtecture and Design Patterns e Software Factories 2.Ridurre il Work-in-Progress (WIP) 3.Rilasciare spesso 4.Bilanciare la domanda di nuove funzionalita con il lavoro che si riesce a smaltire (Throughput) 5.Dare priorita alle cose 6.Ridurre le cause di variabilita migliorando la predicibilita da “Kanban: Successful Evolutionary Change for Your Technology Business”Sunday, February 5, 12
    • ConclusioniSunday, February 5, 12
    • 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/Sunday, February 5, 12
    • Le certificazioni AgileSCRUM - www.scrumalliance.org Master Practitioner Coach TrainerPMI-ACP - www.pmi.orgAtern DSDM - www.dsdm.orgSunday, February 5, 12
    • Studiare come Scrum MasterSeguire il corso di Scrum Master di due giorni insegnato da un Scrum Trainer CertificatoApplicare Scrum su un progetto e/o partecipare ad un progetto ScrumStudiare il libro di Ken Schware “Agile Project Management with Scrum”Sostenere un esame online con 40 domande in 60 minuti.Sunday, February 5, 12
    • Studiare per PMI-ACP Pre-requisiti: 2000h di PM + 1500h di Agile PM + 21h di Training su Agile (16 ore questo corso) Studiare i libri: Agile Project Management with Scrum The Art of Agile development User Stories Applied Agile Estimation and Plannig Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum The Software Project Managers Bridge to Agility Lean-Agile Software Development: Achieving Enterprise Agility Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Manager... Agile Project Management: Creating Innovative Products (2nd Edition) Agile Retrospectives: Making Good Teams Great Kanban: Successful Evolutionary Change for Your Technology Business Inoltre questo link ti da una panoramica di tutte le aree da studiare - http://agiletraining.com/ 2011/09/24/pmi-acp-agile-certification-exam-study-tips Qui l’handbook PMI - http://www.pmi.org/Certification/~/media/PDF/Certifications/PMI- ACP_Handbook.ashxSunday, February 5, 12
    • Links e tools utili casi duso: 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/Sunday, February 5, 12
    • Letture consigliateSunday, February 5, 12
    • Agile quando? Progetti Complessi Persone Mercato e Requisiti A dinamici G I Prodotti/Servizi di L Motivare il Qualita’ e Valore E Controllare il Progetto Team !Sunday, February 5, 12
    • Riferimenti Giulio Roggero roggero@intre.it www.intre.it http://it.linkedin.com/in/giulioroggeroSunday, February 5, 12
    • Ringraziamenti Si ringraziano tutti i partecipanti ai corsi 2011 per i preziosi feedback e la grande partecipazione al corso. Si ringrazia Michael Vizdos che con i suoi fumetti mi ha ispirato e divertito - www.implementingscrum.com. Ringrazio tutti i colleghi di Intré che fanno da cavia per tutte le mie sperimentazioni. Ringrazio Elena, Arturo e Edoardo per la pazienza che hanno avuto durante le mie sere di studio e ricerca.Sunday, February 5, 12
    • DirittiQueste slide sono il frutto di un anno di lavoro e dieci anni di esperienza.Non posso dire che siano complete e perfette ma possono essere unabuona base di partenza.Ho deciso di pubblicarle Open Source per favorire la diffusione di Agile edel Project Management in generale. In questo periodo di difficilecambiamento sono convinto che applicare questi concetti permetterà amolte aziende di diventare più competitive nel mercato e più vivibili alloro interno.Potete usare questo materiale come meglio ritenete opportuno secondo lalicenza Creative Common Attribution-ShareAlike 3.0http://creativecommons.org/licenses/by-sa/3.0/Sunday, February 5, 12