Le 12 pratiche

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

Andrea [email protected]