Embed Size (px)
Citation preview
Le pratiche di XP
Perché XP?
Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), Proceedings of IEEE WESCON, 26 (August): 1–9
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.
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.
Quante e quali sono le pratiche XP?
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/
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)
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)
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)
Da dove cominciamo?
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.
Le 12 pratiche
http://ronjeffries.com/xprog/what-is-extreme-programming/
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!!!!”
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
Small Releases
• “Every release should be as small as possible, containing the most valuable business requirements.”
• Qual’è il vantaggio di avere i rilasci brevi?
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.
Simple DesignAd 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
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”
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.
Pair Programming
• Tutto il codice di produzione è scritto da due persone in coppia. Una macchina, una tastiera e un mouse.
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.
Continous Integration
• Il codice è integrato è testato almeno ogni poche ore, mal che vada almeno una volta nella giornata.
Sustainable Pace
• Niente straordinari
• È necessario essere freschi per scrivere codice.
Coding Standards
• I programmatori si accordano su uno standard di sviluppo condiviso e accettato volontariamente.
Domande?
Per approfondire XP
