3. Royce,Winston (1970), "Managing the Development of Large Software
Systems" (PDF), Proceedings of IEEE WESCON, 26 (August): 1–9
4.
5.
6.
7. Valori alla base XP
• Communication: Dare alle giuste persone le
giuste informazioni per poterle usarle al meglio.
• Simplicity: Tralasciare quello che vorremmo
rispetto e concentrarci solo su quello che
effettivamente serve.
• Feedback: Apprendere ad ogni occasione
possibile.
• Courage: Fare la cosa giusta, anche quando è
difficile, e.g. saper dire agli stakeholder come
stanno effettivamente le cose.
• Respect: Rispettare se stessi e gli altri.
8. Cosa sono le pratiche?
• Portano all’estremo le buone pratiche
dell’ingegneria del software
• Esprimono i valori di XP.
• Ha senso cominciare a sperimentare XP partendo
dalle pratiche.
• Si rinforzano a vicenda, ha senso usarle assieme.
10. All’inizio ne avevamo solo 12
• The Planning Game, Small Releases, Metaphor,
Simple Design, Testing, Refactoring, Pair
Programming, Collective Ownership, Continuous
Integration, 40-hour week, On-site customer,
Coding standards
Kent Beck, 1999, Kent Beck. 1999. Extreme Programming Explained: Embrace Change
http://ronjeffries.com/xprog/what-is-extreme-programming/
11. Poi nel 2004 …
• Dopo 5 anni dalla prima pubblicazione nel 2004 è
uscita la seconda edizione del libro di Kent Beck
• Una riscrittura completa, completamente un altro
libro.
• Le pratiche ora sono 24.
• Non c’è una corrispondenza banale tra nuove e
vecchie pratiche.
Kent Beck and Cynthia Andres. 2004. Extreme Programming Explained: Embrace Change
(2nd Edition)
12. Le pratiche della 2ed
• Primary Practices (13):
• Sit Together, Whole Team, Informative Workspace,
Energized Work, Pair Programming, Stories, Weekly Cycle,
Quarterly Cycle, Slack, Ten-Minute Build, Continuous
Integration, Test First Programming, Incremental Design
• Corollary Practices (11):
• Real Customer Involvement, Incremental Deployment,
Team Continuity, Shrinking Teams, Root-Cause Analysis,
Shared Code, Code and Tests, Single Code Base, Daily
Deployment, Negotiated Scope Contract, Pay-Per-Use
Kent Beck and Cynthia Andres. 2004. Extreme Programming Explained:
Embrace Change (2nd Edition)
13. Pratiche aggiuntive
• Ad esempio:
• Pratiche che derivano da altre discipline (come il
Daily Standup preso in Scrum)
• Pratiche che si trovano comunemente nei team
XP o Agili (e.g. Tecnica del Pomodoro)
• Pratiche implicite (come la Retrospettiva)
15. Da dove cominciamo?
• Le 12 pratiche classiche sono il passo più
semplice.
• Scorrerle velocemente ci permette di farci un idea
di come sia lo sviluppo in un team XP
• Ve le presento una ad una brevemente
• Approfondiremo i dubbi man mano che saltano
fuori.
17. Customer On-site
• “A real customer must sit with the team, available
to answer questions, resolve disputes, and set
small-scale priorities”.
• Chi è un “real customer”?
• E se ti dicono … “Ma non posso bloccare una
persona per dedicarla agli sviluppatori!!!!”
18. Planning Game
• “Software development is always an evolving
dialog between the possible and the desirable”
• Business people
• Scope
• Priority
• Composition of releases
• Dates of releases
• Technical people
• Estimates
• Consequences
• Process
• Detailed scheduling
19. Small Releases
• “Every release should be as small as possible,
containing the most valuable business
requirements.”
• Qual’è il vantaggio di avere i rilasci brevi?
20. Metaphor
• Si sceglie una metafora per descrivere il sistema e
la si usa come fonte per trovare i termini di cui
discutere il sistema.
• In pratica si definisce un linguaggio comune da
usare in modo estensivo durante tutto il progetto.
21. Simple Design
Ad un dato momento il giusto design per un
software è quello che:
1.Fa passare tutti i test.
2.Non contiene logica duplicata
3.Rende chiaro il motivo per è stato scritto
4.Contiene il numero minimo di elementi
22. Testing
• Nel programma non esiste nessuna feature che
non abbia un test automatico che la verifica.
• Unit Testing -vs- Customer Tests
• Ma siamo sicuri che testare proprio tutto tutto?
• “TDD”, “Test-First” o “Test Driven Development”
23. Refactoring
• Quando si fa refactoring? Prima, dopo o durante
l’implementazione di una feature?
• Refactor fatto prima di aggiungere feature.
• Refactor fatto dopo aver aggiunto la feature.
• Refactor solo del codice di produzione?
• Fare refactor quando il sistema te lo chiede? Te lo sta
chiedendo quando sei obbligato a fare duplicazione.
24. Pair Programming
• Tutto il codice di produzione è scritto da due
persone in coppia. Una macchina, una tastiera e
un mouse.
25. Collective Code Ownership
• Tutto il codice codice appartiene al progetto, non al
singolo programmatore.
• Se una coppia incontra un pezzo di codice che
può essere migliorato lo migliora.
• Se una coppia ha bisogno di modificare un pezzo
di codice per implementare una feature lo modifica.
26. Continous Integration
• Il codice è integrato è testato almeno ogni poche
ore, mal che vada almeno una volta nella giornata.
