1. XPUG Marche 2 Meeting Introduzione alle Metodologie Agili Stefano Leli

2. Qual' il problema?

3. Lo sviluppo Software necessita di troppo tempo, troppi soldi e troppe persone

4. L'adozione di piani concreti sono spesso un'utopia e questo lo si paga in...

5. Tempi Impredicibili sappiamo quando si inizia... e la fine? Un mistero

6. Ripetizione degli errori si lavora sempre in emergenza e gli errori abbondano

7. Obiettivi poco chiari spendiamo le nostre vite a produrre cose inutili

8. Obiettivi poco chiari spendiamo le nostre vite a produrre cose inutili

9. In questa ottica...

10. I clienti sono insoddisfatti per i continui ritardi, i costi che crescono e la scarsa qualit

11. Gli sviluppatori sono sfiduciati per la scarsa qualit prodotta a fronte delle molte ore lavorate

12. Verso i processi strutturati

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. 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. Waterfall Ispirato all'ingegneria industriale Si prefigge lo scopo di rendere lo sviluppo software pi predicibile e misurabile

16. Limiti dei Waterfall I controlli sono rimandate a quando ormai troppo tardi Non prevede il cambiamento

17. Metodologie Iterative Prevedono gli stessi step delle metodologie pesanti ma le suddividono in iterazioni Ad ogni iterazione viene spesso prodotto un documento

18. Limiti Metodologie Iterative Alti costi dovuti all'effort richiesto Introducono molta burocrazie e specializzazione Producono ottimi risultati solo in ambienti poco dinamici

19. Le Metodologie Agili

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. Lean applicato al Software Processi Tradizionali Balachander Swaminathan - Thoughtworks

22. Lean applicato al Software Un modo migliore di fare le cose

23. Lean applicato al Software

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. 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. Extreme Programming La pi diffusa metodologia di sviluppo agile 1st ed. Oct 1999 2nd ed. Nov 2004 Kent Beck

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. 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. Filosofia: Valori Semplicit Comunicazione Feedback Coraggio Rispetto

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. 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. User Stories

33. User Stories Dashboard Lavagna del Team Orione - Sourcesense

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. 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. 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. 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. Test-driven Development 1. Think 2. Red 3. Green 4. Refactor 5. Repeat http://jamesshore.com/Blog/Red-Green-Refactor.ht

39. Refactoring Si pu semplificare il sistema? Ci sono delle duplicazioni di logica? Posso migliorare qualcosa? La correttezza viene garantita dai test automatici

40. Pair Programming Jason Yip - Thoughtworks

41. Collective Code Ownership Svetlin Nakov - NASD

42. Continuous Integration Jason Yip - Thoughtworks

43. 40 ore di lavoro NO COMMENT

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. Coding Standard Usare naming e code conventions Indispensabile per la Code Ownership Facilita la comunicazione e il refactoring

46. Standup Meeting Cosa ho fatto ieri? Cosa far oggi? Quali ostacoli mi impediscono di progredire? http://martinfowler.com/articles/itsNotJustStandingUp.html

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. Sopratutto: Whole Team http://www.think-box.co.uk/blog/2007/11/theres-hole-in-your-side-of-boat.html

49. Per ulteriori informazioni http://www.agilemanifesto.org/ http://www.extremeprogramming.org http://www.poppendieck.com/ http://www.martinfowler.com/

50. Domande?

51. Dilbert Scott Adams