Intoduzione Alle Metodologie Agili

1,386 views
1,310 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,386
On SlideShare
0
From Embeds
0
Number of Embeds
121
Actions
Shares
0
Downloads
27
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Intoduzione Alle Metodologie Agili

  1. 1. XPUG Marche – 2° Meeting Introduzione alle Metodologie Agili Stefano Leli
  2. 2. Qual'è il problema?
  3. 3. Lo sviluppo Software necessita di troppo tempo, troppi soldi e troppe persone
  4. 4. L'adozione di piani concreti sono spesso un'utopia e questo lo si paga in...
  5. 5. Tempi Impredicibili sappiamo quando si inizia... e la fine? Un mistero
  6. 6. Ripetizione degli errori si lavora sempre in “emergenza” e gli errori abbondano
  7. 7. Obiettivi poco chiari spendiamo le nostre vite a produrre cose inutili
  8. 8. Obiettivi poco chiari spendiamo le nostre vite a produrre cose inutili
  9. 9. In questa ottica...
  10. 10. I clienti sono insoddisfatti per i continui ritardi, i costi che crescono e la scarsa qualità
  11. 11. Gli sviluppatori sono sfiduciati per la scarsa qualità prodotta a fronte delle molte ore lavorate
  12. 12. Verso i processi strutturati
  13. 13. “Software Engineering is the application of a systematic, disciplined, quantifiable approach to development, operation and maintenance of software: that is, the application of engineering to software.” IEEE Guide to the SWEBOK
  14. 14. Metodologie Software Per far fronte ai problemi descritti vengono definiti processi formali di produzione software • Pesanti (Waterfall, etc.) • Iterativi (spirale, RUP, etc.) • Agili (XP, SCRUM, etc)
  15. 15. Waterfall Ispirato all'ingegneria industriale Si prefigge lo scopo di rendere lo sviluppo software più predicibile e misurabile
  16. 16. Limiti dei Waterfall I controlli sono rimandate a quando è ormai troppo tardi Non prevede il cambiamento
  17. 17. Metodologie Iterative Prevedono gli stessi step delle metodologie pesanti ma le suddividono in iterazioni Ad ogni iterazione viene spesso prodotto un documento
  18. 18. Limiti Metodologie Iterative Alti costi dovuti all'effort richiesto Introducono molta burocrazie e specializzazione Producono ottimi risultati solo in ambienti poco dinamici
  19. 19. Le Metodologie Agili
  20. 20. Decidere il più tardi possibile, Consegnare il prima possibile, Eliminare gli sprechi. Lean Thinking Taiichi Ohno - Toyota Production System: Beyond Large Scale Production
  21. 21. Lean applicato al Software Processi Tradizionali Balachander Swaminathan - Thoughtworks
  22. 22. Lean applicato al Software Un modo migliore di fare le cose
  23. 23. Lean applicato al Software
  24. 24. Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more." http://agilemanifesto.org/
  25. 25. Metodologie Agili • Scrum • Extreme Programming (XP) • Feature-Driven Development (FDD) • Crystal family of methodologies • Adaptive Software Development (ASD) • Dynamic System Development Model (DSDM) • Agile Unified Process (AUP)
  26. 26. Extreme Programming La più diffusa metodologia di sviluppo agile 1st ed. Oct 1999 2nd ed. Nov 2004 Kent Beck
  27. 27. Filosofia: Valori • Semplicità – I problemi possono essere causati da qualcuno che non ha riferito qualcosa • Semplici – Bisogna fare la cosa più facile che possa funzionare – Il codice sorgente deve rilevare le intezioni di chi lo ha scritto
  28. 28. Filosofia: Valori • Feedback • Serve a comunicare meglio • I clienti sono al corrente dello stato attuale del sistema • Coraggio • Si può buttare via il codice • Si può ridurre la complessità
  29. 29. Filosofia: Valori • Semplicità • Comunicazione • Feedback • Coraggio • Rispetto
  30. 30. Le 12 Pratiche • Planning Game • Small Releases • Metaphor • Simple Design • Test-Driven Development • Refactoring • Pair Programming • Collective Ownership • Continuous Integration • 40-Hour Workweek • On-site Customer • Coding Standards
  31. 31. Planning Game • Requisiti via User Stories – I clienti scrivono le storie – Gli sviluppatori le stimano – I clienti scelgono le priorità di implementazione • Planning – Release Planning (2-3 mesi) – Interation Plannig (1-2 settimane) Ci si diverte…..
  32. 32. User Stories
  33. 33. User Stories Dashboard Lavagna del Team Orione - Sourcesense
  34. 34. Brevi Cicli di Rilascio • Ogni ciclo di rilascio non dovrebbe essere superiore a 1-2 settimane. • Ogni ciclo deve produrre una release funzionante e testabile. • Riduce I rischi attraverso feedback continui • Aumenta la fiducia del cliente.
  35. 35. Metafora • Guida l'intero progetto con una semplice storia di come il sistema funziona – Favorisce la comprensione del sistema – Facilita il dialogo con i clienti – Aiuta a capire gli elementi e le relazioni
  36. 36. Simple Design • Non sviluppare un grande design Up-Front (NBDUF) • Implementare solo quello che serve e al momento giusto • I requisiti cambieranno quindi il design deve essere semplice • Fare la cosa più semplice possibile con il minor sforzo
  37. 37. Testing • Test-Driven Development (TDD) – Scrivere test prima del codice – Unit Test automatici (di solito xUnit) – I test devono passare al 100% • Acceptance Tests – Scritte dai clienti – Fungono da “contratto” – Misurano i progressi
  38. 38. Test-driven Development 1. Think 2. Red 3. Green 4. Refactor 5. Repeat http://jamesshore.com/Blog/Red-Green-Refactor.ht
  39. 39. Refactoring • Si può semplificare il sistema? • Ci sono delle duplicazioni di logica? • Posso migliorare qualcosa? La correttezza viene garantita dai test automatici
  40. 40. Pair Programming Jason Yip - Thoughtworks
  41. 41. Collective Code Ownership Svetlin Nakov - NASD
  42. 42. Continuous Integration Jason Yip - Thoughtworks
  43. 43. 40 ore di lavoro NO COMMENT
  44. 44. Cliente in loco • Il cliente produce valore scrivendo I test di accettazione • Stabilisce le priorità • Risponde alle domande • La comunicazione faccia a faccia riduce i malintesi
  45. 45. Coding Standard • Usare naming e code conventions • Indispensabile per la Code Ownership • Facilita la comunicazione e il refactoring
  46. 46. Standup Meeting • Cosa ho fatto ieri? • Cosa farò oggi? • Quali ostacoli mi impediscono di progredire? http://martinfowler.com/articles/itsNotJustStandingUp.html
  47. 47. Retrospettiva • Cosa abbiamo fatto bene e dobbiamo ricordare per il futuro? • Cosa abbiamo imparato? • Cosa dovrebbe essere diverso la prossima volta? http://www.retrospectives.com/
  48. 48. Sopratutto: Whole Team http://www.think-box.co.uk/blog/2007/11/theres-hole-in-your-side-of-boat.html
  49. 49. Per ulteriori informazioni… • http://www.agilemanifesto.org/ • http://www.extremeprogramming.org • http://www.poppendieck.com/ • http://www.martinfowler.com/
  50. 50. Domande?
  51. 51. Dilbert – Scott Adams

×