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
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
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/