How to be Agile - ABC of team working
1 like•203 views
Il documento discute l'approccio Agile nello sviluppo software, evidenziando i limiti del modello tradizionale Waterfall, come i costi elevati e la rigidità nei cambiamenti. Presenta il Manifesto Agile, che enfatizza l'importanza delle persone e delle interazioni, del software funzionante, della collaborazione con i clienti, e della capacità di rispondere ai cambiamenti. Vengono inoltre citati esempi di adozione e risultati positivi di metodologie Agile in diverse aziende.
How to be Agile - ABC of team working
- 1. How to be Agile Paolo Sammicheli [email protected] - @xdatap1 ABC of Team Working
- 4. ● Presentata nel 1970 da Winston W. Royce a una conferenza ingegneristica: IEEE WestCom. ● Processo sequenziale in cui ogni fase è completata prima che la successiva sia iniziata. WATERFALL
- 5. ● Rigidità: il committente del progetto, anche a fronte di cambiamenti dello scenario del mercato, ha difficoltà ad influire su quanto richiesto, perché la fase di progettazione è tutta all’inizio LIMITI DEL WATERFALL ● Time to Market: il committente del progetto non riceve nulla se non in fondo al progetto, che spesso dura mesi se non anni. ● Costi elevati e non predicibili: quello che appare come un processo lineare ed efficiente diventa spesso una serie di cicli turbolenti che fanno perdere tanto tempo e tanti soldi.
- 6. The CHAOS Report (1994) Source: http://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Type 1: Progetti completati rispettando tempi e budget prefissati Type 2: Progetti completati ma senza rispettare tempi e budget Type 3: Progetti abortiti prima del loro completamento. 16,2% 52,7% 31,1% 31,1% 52,7% 16,2%
- 7. The CHAOS Report (2001) Source: http://www.cin.ufpe.br/~gmp/docs/papers/extreme_chaos2001.pdf Type 1: Progetti completati rispettando tempi e budget prefissati Type 2: Progetti completati ma senza rispettare tempi e budget Type 3: Progetti abortiti prima del loro completamento. 28% 49% 23% 23% 49% 28%
- 8. "The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labour to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labour to perform the same task." - Tom Clancy (The Sum of All Fears) Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf
- 9. Nel 2001 diciassette professionisti di spicco si radunarono in una località sciistica dello Utah per discutere assieme del futuro del mondo software, stanchi di assistere ad una percentuale sempre crescente di progetti software che si frantumavano sulle rocce al termine della cascata.
- 10. Manifesto per lo Sviluppo Agile di Software Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti Gli individui e le interazioni più che i processi e gli strumenti Il software funzionante più che la documentazione esaustiva La collaborazione col cliente più che la negoziazione dei contratti Rispondere al cambiamento più che seguire un piano Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.
- 11. PLAN ANALYSIS DESIGN CODE TEST DEPLOY ANALYSIS DESIGN CODE TEST PLAN DEPLOY ANALYSIS DESIGN CODE TEST PLAN DEPLOY ANALYSIS DESIGN CODE TEST PLAN DEPLOY Modello di sviluppo AGILE Modello di sviluppo WATERFALL
- 12. Fatti, non...
- 13. 3 year transition: 2005 – 2008 Results in 2008: 200 scrum teams world wide, total approx. 1500+ employees Average Team Velocity increase estimated at +35% / year Development cost reduction of over USD 1 million / year ROI on transition and trainings about 100% in first year http://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption
- 14. Down to 1 release/yr Scrum adoption: 3 months Salesforce.com - 2007 Results: 60+ Critical features delivered in < 9 months “Idea to Release” avg. rate: 2.2 quarters 70% of “Top 10 Ideas” are on track for delivery in 2007
- 15. All bugs are fixed for the release All high level bugs are fixed for the release. Medium and low level bugs are not fixed Product quality index Client feedback Burndown ChartNoneVisibility tools Progress tracking 4070 Average working hours/week 6040Defects fixed 53New features Increase in productivity Release with ScrumRelease before ScrumMetricCategory HCL EAI Services Inc. Enterprise application integration services: healthcare, retail, telecommunication, wireless.
- 16. 2010 Videocitofono Touch Metodologia Waterfall · 15 anni uomo di effort · 3 anni di sviluppo · Scarso impatto sul mercato · Time to market inaccettabile – 2014 Videocitofono Serie 300 Metodologia Agile · 3 anni uomo di effort · 1 anno di sviluppo · Prodotto innovativo · Time to market competitivo · Visibilità di processo Fonte: Agile for Innovation, Milan 3 March 2015
- 17. http://www.cio.com/article/368313/100_Most_Agile_Companies_Honored 100 Most Agile Companies Honored (2004) Aerospace Automotive Manufacturing Banking/Investment Business/Consumer Services Communications Computer Manufacturing Education Financial services Government Health Care/Health Insurance Insurance Legal Services Manufacturing/Process Industries Pharmaceuticals Retail/Wholesale Technology Services Transportation/Distribution
- 18. COME OTTENERE QUESTI RISULTATI?
- 19. COESIONE
- 20. COMUNICAZIONE
- 21. CADENZA
- 22. PRODUTTIVITÀ
- 23. QUALITÀ
- 24. TRASPARENZA
- 25. SPRECHI
- 26. VALORE
- 28. ITERATIVO
- 29. INCREMENTALE
- 30. RISCHIO
- 31. AGILE OVERVIEW © Paolo Sammicheli 2015
- 33. PRACTICES Planning Game Test Driven Development Behaviour Driven Development Continuous Integration Continuous Refactoring Pair Programming Small Releases Collective code ownership Management 3.0 #Workout Coding standard System metaphor User Stories Personas Product Canvas Jobs Stories Popcorn Flow Retrospectives StandUp Meetings U.S. Mapping Lean Change Canvas … © Paolo Sammicheli 2015
- 34. METODOLOGIES eXtreme Programming KanbanSCRUM DSDM ATERN FDD SAFe DAD LeSS © Paolo Sammicheli 2015 Lean Software Development AgileUP
- 35. PRINCIPLES Lean Change AGILELEAN Lean Startup © Paolo Sammicheli 2015 Radical Management Kaizen Cynefin
- 36. VALUES AGILELEAN © Paolo Sammicheli 2015
- 37. MAGIC BALLS
- 38. MAGIC BALLS · Le palle all'inizio non hanno energia. · Per diventare magiche devono essere toccate da tutti i membri del team. · Due membri non possono toccare la stessa palla. contemporaneamente (la palla deve essere scambiata al volo, “air time”). · Le palle che cadono a terra o toccano altri oggetti perdono energia. · Non si possono passare le palle lateralmente, solo frontalmente.
- 39. MAGIC BALLS · Pianificazione 2 Minuti · Stima 1 Minuto · Esecuzione 3 Minuti · Retrospettiva 3 Minuti 5 ITERAZIONI
- 40. RISULTATI
- 41. Cosa vi portate a casa Iterazioni Rilasci frequenti Team auto-organizzato Ispezione ed adattamento
- 42. Paolo Sammicheli [email protected] - @xdatap1 Grazie