Lean Agile Development - a war story (Better Software 2010)
8 likes2,233 views
Il documento descrive l'esperienza dell'autore nel guidare la transizione da metodologie waterfall a pratiche agili all'interno di un'azienda, evidenziando l'importanza dell'agilità a livello enterprise. Si affrontano le sfide culturali, organizzative e operative nel promuovere una mentalità agile e si evidenzia l'importanza della collaborazione e del cambiamento per ottenere risultati positivi. Inoltre, vengono presentate le fasi e i metodi utilizzati per realizzare la migrazione e il rollout delle metodologie agili in vari progetti aziendali.
Lean Agile Development - a war story (Better Software 2010)
- 2. a war story 2
- 3. Fabio Armani • CTO di Sequenza SpA • CEO di OpenWare • Direttore artistico dell‟etichetta Different Lands • Certified Scrum Pratictioner 3
- 4. Preludio → esposizione dei temi I Movimento → allegretto in forma di sonata II Movimento → adagio quasi un blues III Movimento → scherzo IV Movimento → allegro con fuoco Postludio → conclusione 4
- 6. Motivazione Enterprise Agility Roadmap o Il percorso verso l‟azienda Agile 6
- 7. Il processo di migrazione da un approccio di tipo waterfall alle metodologie agili in azienda rappresenta una tematica complessa che richiede coraggio, dedizione e capacità di affrontare difficoltà ed errori. Questo talk vuole essere il racconto reale (da qui il sotto titolo: “a war story”) della mia esperienza pluriennale in qualità di CTO e di Senior Manager impegnato nel diffondere nel contesto italiano le metodologie agili a livello Enterprise (in particolare Agile Modeling, XP, Scrum e Lean Development), coinvolgendo quindi tutti i livelli della azienda, a partire dall‟organizzazione strutturale e strategica fino ai dettagli operativi (tool open source di project management e full life-cycle). 7
- 8. Certamente molti sono riusciti ad introdurre le metodologie agili a livello di team. Questo, che è certamente il punto più facile da cui partire, ma non è la sfida maggiore che un organizzazione di sviluppo deve affrontare. E … certamente non rappresenta il traguardo in cui terminare il processo d‟innovazione e trasformazione. Il vero obiettivo dovrebbe essere quello di creare … 8
- 9. 9
- 10. Un fatto certo è che l‟azienda ha la necessita di essere agile! Deve essere in grado di: • rispondere a forze competitive esterne, • avere una migliore comprensione del mercato, • dei propri errori, affrontare i cambiamenti della tecnologia o • qualunque altro elemento possa influire in modo positivo o negativo sull‟azienda stessa. L‟agilità a livello dei team è necessaria ma non sufficiente; L‟Agilità Aziendale richiede quella dei team, ma questa è solo un mezzo verso il fine che è appunto: l‟Enterprise Agility ! Quest‟ultima consente ad una azienda di realizzare prodotti di qualità e servizi ai propri clienti in modo più veloce rispetto ai propri concorrenti. 10
- 11. Come raggiungere il grande obiettivo di portare l‟Agilità a livello aziendale e vincere quetsa sfida estremamente complessa? Cosa e chi è coinvolto? Cosa è richiesto per creare del vero valore per l‟organizzazione? Ogni cosa deve concorrere a realizzare valore per l‟intera organizzazione! Qual è il percorso da compiere? 11
- 12. Azienda non Agile Azienda Agile Cambiamenti Scontro Rollout Cambiamenti Progetti pilota Accettazione organizzativi Formalizzazione culturale aziendale globali locali 12
- 13. Allegretto » in forma di sonata
- 14. Azienda non-Agile Progetti pilota o Metodologia adottata Scrum & AUP Accettazione 14
- 15. Azienda non Agile Struttura organizzativa basata su silos Scarsa cultura aziendale Cowboy programming Assenza di una vera metodologia Processo di sviluppo non ben definito e comunque basato sul Waterfall 15
- 16. Azienda non Agile Una tipica struttura organizzativa basata su silos. • In cui si aveva una separazione di mansioni, ruoli e responsabilità. Questo ha portato a: • una scarsa condivisione degli obiettivi; • una netta separazione di ruoli e professionalità; • gravi difficoltà di comunicazione • incapacità a gestire i cambiamenti • mancanza di vera cooperazione 16
- 17. Azienda non Agile Scarsa cultura aziendale Mancanza di condivisione di informazioni e nozioni La struttura organizzativa a silos ha favorito la poca socializzazione e l‟individualismo Altri importanti aspetti da considerare: • Mancanza di dati storici (metriche, stime …) • Ripetizione di errori precedenti • Assenza di un Knowledge Management System o di una Intranet aziendale reale 17
- 18. Azienda non Agile Cowboy programming è una forma di sviluppo software priva di un effettivo metodo definito. I membri del team procedono in modo caotico con nessuna o pochissima guida e senza alcuna metodologia ne processo di sviluppo. Wikipedia 18
- 19. Azienda non Agile Non esisteva in azienda una vera metodologia. Lo sviluppo dei progetti era quindi demandato ad una serie di Project Manager (di cui peraltro era poco definito ruolo e profilo) e ad un „pool‟ di risorse condivise tra più progetti per le quali valeva un processo basato sull‟allocazione „time sharing‟ • Con evidenti problemi di context switching • Mancanza di vero commitment ed ownership nei progetti • Poca se non nulla attenzione alla qualità sia intrinseca che estrinseca 19
- 20. Azienda non Agile Né il processo di sviluppo, né le diverse fasi erano ben definite, anche se esistevano dei documenti redatti essenzialmente per la qualità ISO 9000. • Più formali che di sostanza; • non ben conosciuti e mal percepiti praticamente da tutti; • sicuramente lontani dalla quotidianità e dall‟operatività. Il processo si rifaceva grossolanamente a RUP, pesante e gravato da una scarsa comprensione di una reale metodologia iterativa ed incrementale → Waterfall 20
- 21. Progetti pilota Si decide di procedere con un 1° progetto pilota per verificare l‟efficacia e la percezione della metodologia Agile • Effort: ~220 story points • Elapsed: 4 months • Team: 5 people 21
- 22. Progetti pilota Scrum → come metodologia di sviluppo, in termini di: • Ceremonies (Sprint Planning, Daily Scrum, Sprint Demo, Retrospective) • Roles (pigs: SM, PO & Team + chickens) • Artifacts (Product Backlog, Sprint Backlog, Burn Down Charts) AgileUP → come wrapper utilizzato per gestire le diverse fasi del progetto: • Inception (1) • Elaboration (2) • Construction (4) • Transition (1) 22
- 23. Progetti Accettazione pilota 23
- 24. Progetti Accettazione pilota Se il costo del cambiamento cresce lentamente nel tempo si può agire in modo totalmente differente rispetto a quanto si fa sotto l‟assunzione che tale costo cresca esponenzialmente. Scrum ed alcune pratiche XP vengono provate con successo da parte del team nel pilot. Soddisfazione e partecipazione attiva del cliente. 24
- 25. Accettazione Notevole accettazione della metodologia da parte del team coinvolto. Vengono condivisi: • Obiettivi e Vision • Valori (comunicazione, semplicità, rispetto …) • Principi • Pratiche (planning game, test driven development …) Riscontro estremamente positivo dei risultati ottenuti. Desiderio di diffondere l‟esperienza … 25
- 26. Andante » quasi blues
- 27. Il problema • Scontro culturale Altri ostacoli 27
- 28. Scontro culturale 28
- 29. Scontro Accettazione culturale Assenza di reale condivisione a livello aziendale di: • Obiettivi comuni • Valori » ritenuti inutili • Principi » praticamente antitetici ai precedenti • Pratiche » poiché poco ortodosse Netta contrapposizione da parte del Management più conservatore 29
- 30. Scontro culturale Difficoltà di condividere ed accettare l‟Agile … a causa di molti fattori: • differenza culturale • diffidenza reciproca • sospetto verso l‟innovazione (cinismo) • inadeguatezza a cambiare • … lascio a voi altre possibili motivazioni 30
- 31. Impedimenti al processo 31
- 32. Scontro culturale Ostacoli pricipali: Management Businessmen Contesto italiano Resistenza al cambiamento 32
- 33. Scontro culturale Presenza in azienda di un Management • Con mentalità arretrata • Legato a vecchi valori e principi • Amante delle gerarchie • Spesso autoritario 33
- 34. Scontro culturale Struttura commerciale • Troppo interessata ad un guadagno immediato • Poco attenta alla qualità • Sovrapposizione di progetti in contrapposizione reciproca 34
- 35. Scontro culturale 35
- 36. Scontro culturale Mancanza di volontà e desiderio di parte dell‟azienda di accettare la nuova metodologia. Resistenza al cambiamento R=V/I 36
- 38. Cambiamenti organizzativi locali Formalizzazione del processo Impegno aziendale » adozione dell‟ Agile in tutti i progetti Lancio di un progetto di Rollout Aziendale Cambiamenti aziendali su larga scala • Nascita del Modello Organizzativo Agile 38
- 39. Cambiamenti Scontro organizzativi culturale locali Cambiamenti organizzativi locali • Adozione di un processo di sviluppo iterativo ed incrementale • Certificazione di alcuni Scrum Master e Product Owner • Utilizzo di Scrum e di alcune pratiche XP • Test Driven Development • Continuous Integration • 40 hours • Pair programming, side by side programming • Information radiators 39
- 40. Cambiamenti organizzativi locali Allo scopo di avere una transizione verso una azienda Agile che abbia realmente successo, ogni rischio (sia reale che percepito) associato con l‟introduzione dello sviluppo Agile necessità di essere risolto rapidamente dal senior management. 40
- 41. Cambiamenti organizzativi locali 41
- 42. Dalle premesse si evincono le strategie 42
- 43. Cambiamenti Formalizzazione organizzativi locali A seguito del definirsi dei cambiamenti organizzativi locali Si procede ad una prima formalizzazione del processo Agile 43
- 44. Formalizzazione 44
- 45. Formalizzazione Value System • People • Collaboration • Honesty • Trust Agile Adaptive Attitude Ecosystem • Thinking guided • Thightly couples by principles and self-organizing reflected in Team to a Product behaviour Owner Simple framework • Self organisation • Visibility • Inspection • Adaptation 45
- 46. Formalizzazione Sistemi di valori • Persone • Collaborazione • Onestà • Fiducia Attitudine Un framework per gestire il cambiamento Ecosistema adattativo 46
- 47. Formalizzazione Comunicazione Feedback Semplicità Coraggio Rispetto 47
- 48. Formalizzazione Si avrà successo nel momento in cui si adotterà uno stile che celebrerà un set consistente di valori che serviranno sia le necessità umane che quelle di tipo commerciale: • Comunicazione • Semplicità • Feedback • Coraggio • Rispetto 48
- 49. Formalizzazione Favour Over Individual and interactions Processes and tools Comprehensive Working software documentaition Customer collaboration Contract negotiation Responding to change Following a plan 50
- 50. Formalizzazione La nostra massima priorità è soddisfare il cliente, •per mezzo di tempestivi e continui rilasci di software di valore Siano benvenuti i cambiamenti nelle specifiche, •anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento •a favore del vantaggio competitivo del cliente. Rilascia software funzionante frequentemente, •da un paio di settimane a un paio di mesi, •con preferenza per i periodi brevi. Manager e sviluppatori devono lavorare insieme •quotidianamente lungo il progetto. Basa i progetti su individui motivati. 52
- 51. Formalizzazione Il software funzionante • è la misura primaria di progresso I processi agili promuovono uno sviluppo sostenibile. • Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante indefinitamente. L'attenzione continua per l'eccellenza tecnica e il buon design • esaltano l'agilità. La semplicità • l'arte di massimizzare l'ammontare di lavoro non svolto • è essenziale. Le migliori architetture, specifiche e design • emergono da team auto-organizzati. A intervalli regolari il team riflette su come diventare più efficace, • dopodiché mette a punto e aggiusta il suo comportamento di conseguenza. 53
- 52. Formalizzazione Motivati dal manifesto agile: • Un disegno semplice e snello • Test automatici • Molta pratica nel modificare il disegno (design emergente) • Refactoring • Clean Code 54
- 53. Agilità vuol dire … 55
- 54. Formalizzazione Le quattro variabili fondamentali da considerare nello sviluppo di un progetto aziendale sono: • Costo • Tempo Qualità • Ambito (scope) Ambito • Qualità → variabile 56
- 55. Formalizzazione Waterfall Ambito Qualità variabile Tempo Costo 57
- 56. Formalizzazione Agile Qualità Ambito variabile Tempo Costo 58
- 57. Formalizzazione Le principali forze positive che hanno guidato il cambiamento sono state: • le persone (dalla base) • il supporto della dirigenza tecnica • la volontà di cambiamento condivisa • L‟impegno e l‟operato sia del comitato ETC che del Rollout Team • La capacità di imparare dai nostri errori 59
- 58. Rollout Formalizzazione aziendale Si decide di procedere con l‟adozione delle metodologie agili e di Scrum su larga scala per tutti i progetti. Si fa dunque partire il processo di Rollout Aziendale che avverrà con le stesse modalità di un progetto agile. 60
- 59. Rollout aziendale Si utilizza un processo iterativo ed incrementale per la gestione del cambiamento Utilizzo di Scrum e di S2 (Scrum of Scrums) per gestire il progetto di Rollout aziendale e il coordinamento tra i diversi team Creazione di un Enterprise Transition Committee (ETC) Creazione di un Rollout Team (RT) 61
- 60. Rollout aziendale Si procede a pianificare la transizione utilizzando le seguenti regole: • Definizione dello scopo • della strategia • dei pezzi (story card) • dei giocatori (Sviluppo e Commerciale) • delle mosse 62
- 61. Cambiamenti Rollout Organizzativi aziendale globali Il risultato del Rollout aziendale è l‟attuazione di una serie di cambiamenti Organizzativi globali Il modello organizzativo Agile si distingue dal precedente per una serie di importanti fattori: • Generalizing Specialist • Holistic Team (cross functional) • Condivisione a tutti i livelli di obiettivi, valori e principi • Responsabilità e Leadership globali • Sinergia tra i diversi team 67
- 62. Cambiamenti Organizzativi globali Separare le responsabilità commerciali da quelle tecniche. Chiave fondamentale della strategia è quella di tenere i tecnici focalizzati su problemi tecnici e i commerciali su quelli commerciali. Nessuna delle due parti dovrebbe essere in grado di decidere unilateralmente. 68
- 63. Cambiamenti Organizzativi globali I commerciali (POs) decidono: • scopi e tempi di realizzazione delle release • priorità relative delle funzionalità proposte • scopo esatto delle funzionalità Rispetto a queste scelte i tecnici (SMs & Teams) contribuiscono: • stimando i tempi di realizzazione • valutando le conseguenze tecnologiche • adottando un processo di sviluppo che ben si adatti alle proprie personalità • scegliendo pratiche e sequenza di sviluppo 69
- 64. Quality Assurance Quality Mercury Team Jupiter Team Halley Romanian Team 1 Program 1 Project 1 Project 3 Task 1 Task N Project 2 Project N Proxy Proxy Life-Cycle Management CRM Test Systems - DBA 70
- 65. Azienda Agile Cambiamenti Organizzativi globali Il sistema solare I team prendono il nome dei pianeti • Mercury • Venus • Earth • Mars • Jupiter • Saturn • Uranus • Neptune 71
- 66. Azienda Agile Modello organizzativo » Team Modello di conoscenza » Pratiche Modello di competenza » Aree 72
- 67. 73
- 68. Azienda Agile Mercury Neptune Focus sulle seguenti aree: • Quality Assurance, • DBA, • Lifecycle, • Learning Sincronizzano i propri Sprint con quelli degli altri team Partecipano a S2 74
- 69. 75
- 70. Azienda Agile Venus Earth Mars Jupiter Saturn 76
- 71. 77
- 72. 78
- 73. Azienda Agile Ceres Pluto Halley Vengono gestiti mediante i Proxy PO 79
- 74. Team Jupiter @ Scrummorra 80
- 75. I team lavorano collettivamente nel proprio open space suddiviso nelle seguenti aree: Il Laboratorio (set di tavoli affiancati per favorire le pratiche XP di pair programming, osmotic communication …) Il Pensatoio (vicino alle lavagne) Integrazione e Test (es: Venera 7, Vygr) Comunicazione (attrezzata con Skipe, video camera …) Realizzano nuove funzionalità in modalità Test Driven Development e Agile Modeling Sono cross-functional e si auto organizzano 81
- 76. 82
- 77. 83
- 78. 84
- 79. Alcuni giorni della settimana all‟ora di pranzo effettuiamo delle round table per confrontarci e discutere assieme su differenti tematiche … • Retrospettive sulle metodologie adottate » Scrum, Lean • Meccanismi di interscambio e cooperazione tra i team • Principi metodologici • Domain Driven Design (DDD) • Agile Modeling • UML • Design Patterns … Inoltre una volta la settimana si effettuano gli incontri dell‟Enterprise Rollout Team che ha il compito di gestire la transizione operativa dell‟azienda verso Scrum e di rimuovere gli impediments emersi duranti gli Scrum of Scrums 85
- 80. Allegro con fuoco » electronic
- 81. Parziale crisi e soluzioni adottate Cambiamenti aziendali su larga scala • Nascita del Modello Organizzativo Agile Oltre l‟ Agile 87
- 82. Azienda Agile Improvviso cambiamento dall‟esterno: • Nuovo assetto societario • Cambio della classe dirigente • Interruzione del processo di rollout aziendale Necessità della condivisione di filosofia, valori, principi e pratiche con nuovi attori 88
- 83. Azienda Agile Come il blues delle origini evolve in una carica evolutiva e progressive così si trasforma l‟Azienda Agile. La metodologia si evolve a partire da Scrum verso Scrum# Integrazione tra Agile ed istanze di processo: • Qualità • Processi aziendali distribuiti • Altri ruoli 89
- 84. 90
- 85. 91
- 86. 92
- 87. Il diagramma rappresenta il flusso dalla concettualizzazione verso il cliente, tramite la gestione del product portfolio (inclusa la definizione dei progetti su cui lavorare), i team di sviluppo e nuovamente verso i clienti per l‟utilizzo finale del software sviluppato. Necessari per il successo: • Allineamento con la visione di business • Un management altamente focalizzato • Pratiche tecniche di alta qualità 93
- 88. Un unica taglia non soddisfa tutti. Un‟opportuna miscela di „best pratice‟ e di processi direttivi è richiesta per affrontare le diverse problematiche che le diverse aree aziendali devono affrontare . L‟azienda è composta da: • Product Management • Product Portfolio • Customer Base • Teams L‟attenzione a soltanto una, o ad una porzione di queste componenti porta a sub-ottimizzazione e risultati non-ottimali. Lean-Thinking ha dimostrato di essere il veicolo necessario per migliorare la qualità, diminuire il „time to market‟ contemporaneamente abbassando i costi. Lean assume una visione Aziendale ed ha largamente dimostrato di poter fornire un contesto per il pensiero Agile che ha certamente migliorato la produttività dei team. 94
- 89. Kanban Lean Emergent Scrum Design Agile XP 95
- 90. Ritengo che quando cerchiamo di capire come realizzare la transizione allo scopo di essere più efficaci, abbiamo bisogno di comprendere dove siamo, dove vogliamo andare e quali abilità abbiamo che ci consentono di compiere il percorso da dove siamo verso dove vogliamo andare. Questo significa che dobbiamo guardare a: Quali sono le forze presenti al momento attuale nella nostra organizzazione? Queste includono: • Dominio(i) applicativi • Impedimenti della nostra organizzazione • I livello corrente delle nostre abilità In quali attitudini crede la nostra organizzazione? 96
- 91. Forze presenti nell‟Organizzazione attuale • Application domain(s) • Impedimenti dell‟Organizzazione attuale Come i team lavorano assieme Come è gestito il product portfolio aziendale • Il livello attuale degli skill Attitudini portate dalla metodologia Software • Ambito del processo (team, enterprise wide) • Attitudine verso il management • Focalizzarsi sui sistemi o sulle persone In sostanza le organizzazioni dovrebbero accertare divario Conoscere » Fare e come questo si relazioni con il lavoro dei team e con i processi che portano valore per il cliente 97
- 92. Principi di Lean Management 98
- 93. L‟utilizzazione ottimale porta ad una produttività sub- ottimale “There is no free lunch” Il ritardo ha sempre un costo ! 99
- 94. Avete un “inventario” di progetti Grandi giacenze sono negative: • Costano molto • Nascondono molti problemi • Sono intrinsecamente lente 100
- 95. Ruolo e responsabilità 101
- 96. Azienda Agile Nascita del ruolo di Project Management Office (Lean-Agile PMO) Integrazione del processo Agile con CMMI: • Definizione di standard aziendali • Modifica dei processi e delle procedure di qualità ISO 9000 • Identificazione di metriche • Estrazione e disamina dei risultati (feedback) 102
- 97. Azienda Agile Il Product Management Office (PMO) è in rapida evoluzione in molte realtà project-based. Tale evoluzione si sostanzia in: • una estensione dell'area di intervento del PMO, vale a dire un allargamento del suo raggio d'azione all'interno dell'organizzazione dell'azienda; • una crescita dell'influenza esercitata dal PMO sui risultati aziendali (fatturato, margine di contribuzione, fidelizzazione dei clienti, sviluppo di nuovi prodotti, posizionamento competitivo). 103
- 98. Tracciare il flusso dei progetti Gestire l‟inserimento (On-Ramp) Terminare i progetti malati Spezzare grandi progetti in altri più piccoli 104
- 99. Evitare troppi progetti simultanei Esercitare la leadership: dando priorità ai progetti e focalizzando i propri team Ritardare gli impegni, ritardare i consumi Effettuare consegne continuamente in piccoli gruppi rispetto ad effettuare rilasci infrequenti con „infornate‟ enormi 105
- 100. Team multipli ognuno dei quali focalizzato su un singolo progetto Dedicati a piattaforme o linee di business Il Platform owner guida la priorità dei prossimi progetti Risultati: • Supportare linee multiple di business simultaneamente • Sforzo focalizzato sui risultati » veloci consegne per progetti individuali • Una chiara responsabilità 106
- 101. Silos tradizionali Product PM BA Designer Developer Tester Owner 107
- 102. Core Project Team BA Designer SM/PM Developer Core Project DBA Team Developer Tester Product Owner 108
- 103. Core Project Team » cross functional • Business Analyst (BA) • Scrum Master (o Project Manager) • DBA • Tester • Developer • Product Owner • Designer (Front End ) Olistico 109
- 104. Extended Project Team Release Manager Capacity Architect Planner BA Designer SM/PM Peripheral Project Teams Risk Assessor Developer Core Team DBA Prod Developer Tester Product Owner Tech Ops Security Integrated Platform-based Team Business Sponsor 110
- 105. Core Project Team Peripheral Project Teams • Realease Manager • Capacity Planner • Security • Production • Business Sponsor • Technical Operationals • Risk Assessor • Architect 111
- 106. “… una grande organizzazione per poter essere efficace deve agire come se fosse un gruppo di piccole organizzazioni collegate.” Divide et impera costruendo una federazione di team agili: Realizzare l‟ “intero” nelle “parti” Porre un limite alla grandezza ( es. 7 +/- 2 persone) Per consentire la crescita, spezzare nuovi Agile team integrati (Olistici) una volta che il loro limite di grandezza è stato raggiunto Coordinare ad alto livello mediante il Lean-Agile PMO 112
- 107. 113
- 108. Incoraggiare il dialogo faccia-a-faccia attraverso i diversi livelli Sovrapposizione del management mediante “linking pins” PMO agisce come un Agile project team 114
- 109. Azienda Agile Utilizzare Agile project delivery • Integrated platform-based teams • Effettuale piccoli rilasci il più frequentemente possibile Applicare il Lean Thinking per ottimizzare l’intero portfolio di progetto • Ottimizzare per la produttività (throughput) • Ridurre l‟inventario di progetto/WIP • Gestire i vincoli (constraints) I Lean-Agile PMO possono avere un grande impatto sulle performance del portfolio di progetti • PMO gestisce il delivery del portfolio di progetti • PMO agisce come un agile project team 115
- 110. L‟obiettivo : Veloce flusso di produzione di Obiettivi Chiave che abbiano Valore ed Alta Qualità. KEY CHALLENGES THE AGILE GAME’S SOLUTIONS Shared vision in large teams Individuals cannot win, only Teams Objective definition and validation of value Customers/Product Owners define “Value” End users validate “Value” Team energy & accountability Teams are measured together 116
- 111. Azienda Agile Molti team Agili si focalizzano sul proprio lavoro e si coordinano solo successivamente. L‟organizzazione di Enterprise Teams deve essere creata considerando il piano generale » incluso come essi lavoreranno assieme. 117
- 112. Azienda Agile Utilizzo di Atlassian JIRA e di vari plugin come GreenHopper ed altri, per gestire in modo integrato: • Progetti di sviluppo • Progetti cross funzionali • Progetti aziendali • CRM • Gestione economica • Anagrafica dei clienti 118
- 113. Azienda Agile Integrazione del sistema Atlassian JIRA con: • IDE → Eclipse, IntelliJ Idea • CASE di modellazione UML → Sparxsystem Enterprise Architect • Continuous Integratiuon → Atlassian Bamboo • Enterprise Wiki → Atlassian Confluence • Agile UI Modeling → Balsamic Mockups 119
- 114. Guardando oltre l‟Agile 120
- 116. Toyota Production System (TPS) » primo grande esempio di Lean Practices Lean. Alle basi del TPS vi è l‟assoluta eliminazione dello spreco (Muda), supportata dai seguenti due pilastri: • Just-in-Time TPS • Autonomation, o automazione con un tocco umano Continuous Quality Learning and Management Improvement 122
- 117. Il Lean thinking va visto non tanto come una collezione di pratiche ma piuttosto come la combinazione di tre fondamentali body of knowledge: • Science • Management • Knowledge stewardship 123
- 118. Flow, Cadence, Pull Option Theory Theory of Constraints Lean Science A3s, Kaizens Leaderhip Continuous Education Improvement Visual Controls 5 Whys Lean Lean Knowledge Management Stewardship 124
- 119. Flow, Cadence, Pull Option Theory Theory of Constraints Lean Science 125
- 120. Just-in-Time Teoria dell‟utilizzazione • Piccole code e batch size • Limitare il WIP • Little‟s law • Cause di scarto Pull Management Opzioni reali 126
- 121. Leaderhip Education Visual Controls Lean Management 127
- 122. Il Lean Management enfatizza la responsabilità che i Manager devono avere per le performance dei loro team. Non devono effettuare il micro-management I manager devono piuttosto divenire: • leader • allenatori • educatori Più che “servant leader” dovrebbero essere percepiti come parte del team, responsabili per fornire una guida 128
- 123. A3s, Kaizens Continuous Improvement 5 Whys Lean Knowledge Stewardship 129
- 124. L‟amministrazione della conoscenza Lean include l‟utilizzo appropriato di: • A3s • Kaizens • After Action Reviews (AARs) e retrospettive • Pratica dei Five Whys, la ricerca delle cause radice • Il Value Stream mapping Deve essere inoltre chiaro che ottenere, mantenere e diffondere la conoscenza è un fattore critico. Insegnare alle persone come imparare è anche questo un fattore molto sostanziale. 130
- 125. Agile Software Development with Scrum - Ken Schwaber, Mike Beedle (Prentice Hall, 2001) Agile Project Management with Scrum - Ken Schwaber (Microsoft Press, 2004) Agile Retrospectives (Pragmatic, 2006) 131
- 126. Agile Project Management: Creating Innovative Products » Jim Highsmith Agile Software Development » Alistair Cockburn (Addison-Wesley, 2003) Agile Estimating and Planning » Mike Cohn (Addison-Wesley, 2003) 133
- 127. eXtreme Programming Explained » Kent Beck Planning eXtreme Programming » Kent Beck, Martin Fowler eXtreme Programming Installed » Ron Jeffries, Ann Anderson, Chet Hendrickson 134
- 128. Lean Software Development » Mary & Tom Poppendieck (Addison-Wesley, 2003) Implementing Lean Software Development » Mary & Tom Poppendieck (Addison-Wesley, 2005) Leading Lean Software Development » Mary & Tom Poppendieck (Addison-Wesley, 2008) 135
- 129. User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series) Test Driven Development (The Addison-Wesley Signature Series) Refactoring to Patterns (Addison-Wesley Signature Series) 136
- 130. Metodologie agili 137
- 131. Altri amici … 138
- 132. AgileDevelopment AgileManifesto AgileAlliance AgileinAction ImplementingScrum ControlChaos AgileUP DSDM eXtremeProgramming 139
- 133. 42 140