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
20. Decidere il più tardi possibile,
Consegnare il prima possibile,
Eliminare gli sprechi.
Lean Thinking
Taiichi Ohno - Toyota Production System: Beyond Large Scale Production
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à
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…..
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
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/
