SlideShare a Scribd company logo
Parte 5
eXtreme Programming

05/04/07

59
eXtreme Programming

eXtreme Programming

Descritta nel secondo libro bianco
Beck, K and Andres,
Extreme Programming Explained:
Embrace Change (2nd Edition),
Addison-Wesley,
2005
05/04/07

60
eXtreme Programming
La metodologia XP
descritta nel primo libro bianco
Ken Beck,
Extreme Programming Explained,
Addison-Wesley,
1999
Verrà specificata come la 'prima XP'
05/04/07

61
eXtreme Programming
Per questa presentazione abbiamo preso
spunto, oltre che dalla 'letteratura ufficiale',
dall'articolo di presentazione del secondo libro
bianco scritto dal Prof. Michele Marchesi

www.agilexp.org/downloads/NuovoXP.pdf
Otto pagine consigliate
05/04/07

62
eXtreme Programming

Valori
Sono la base
filosofica della
metodologia.
I valori XP sono
mappabili nei
valori dell'Agile
Manifesto.
05/04/07

●

Comunicazione

●

Semplicità

●

Feedback

●

Coraggio

●

Rispetto

63
eXtreme Programming

Le pratiche
come sviluppare il software.

05/04/07

64
eXtreme Programming

Le pratiche XP
13 pratiche primarie
11 pratiche corollarie
Primarie:
possono essere applicate singolarmente.
Corollarie:
richiedono l'applicazione di una o più pratiche primarie
05/04/07

65
Pratiche Primarie XP 1/3
Analisi e pianificazione

Storie
(stories)

Ciclo settimanale
(weekly cycle)

Ciclo trimestrale
(quarterly cycle)

Margine di sicurezza
(slack)

05/04/07

sono brevi descrizioni di una funzionalità del sistema, la
cui implementazione ne guida lo sviluppo.

lo sviluppo avviene per cicli di una settimana, con una
riunione di inizio in cui si decide quali storie
implementare.

ogni tre mesi si pianifica lo sviluppo su scala più larga,
riflettendo anche sul processo usato, sul team,
sull’allineamento con gli obiettivi aziendali.

evitate di promettere cose che non si possono mantenere,
ed anzi abbiate sempre ad ogni iterazione delle storie che
si possono differire alla successiva, per mantenere un
margine di sicurezza in casi di problemi imprevisti.

66
Pratiche Primarie XP 2/3
Gruppo di sviluppo e fattori umani
il team di sviluppo deve lavorare in un ambiente aperto
Sedere insieme
capace di ospitarlo tutto, per massimizzare la comunicazione.
(sit together)

Team completo
(whole team)

il team deve essere composto di membri con competenze
diversificate e complementari, che abbiamo forte senso di
appartenenza e si aiutino a vicenda.

Ambiente di lavoro informativo
(informative workspace)

Energia sul lavoro
(energized work)

gli sviluppatori devono essere freschi e riposati, per poter
concentrarsi sul lavoro e rendere al massimo; quindi, occorre
limitare gli straordinari e ciascuno deve avere il tempo per
una vita privata.

Programmazione a coppie
(pair programming)

05/04/07

l’ambiente di lavoro deve essere fornito
di cartelli indicanti lo stato del progetto
ed il lavoro da svolgere.

il codice deve essere sempre scritto da
una coppia di programmatori, seduti ad
un unico terminale.

67
Pratiche Primarie XP 3/3
Progettazione
l'XP rifugge dal “big design upfront”, e cerca di scrivere il
Progetto
prima
possibile
del
codice
per
ottenere
feedback,
incrementale
migliorandone poi la struttura in continuazione. L'XP
(incremental design)
suggerisce di progettare incrementalmente durante tutto lo
sviluppo.

Programmazione
guidata dai test
(test-first programming)

Build di dieci
(ten-minute build)

prima di modificare o aggiungere del codice, scrivete dei test
per verificare lo stesso codice. Ciò risolve quattro problemi:
cowboy coding; basso accoppiamento ed alta coesione del
codice; fiducia dei propri compagni; buon ritmo di lavoro.

Codifica e rilascio del software
il “build” del sistema, inclusa l’esecuzione dei test
minuti
automatici, deve durare non più di dieci minuti, per
poter essere eseguito spesso ed ottenere il necessario
feedback.

Integrazione continua
(continuous integration)

05/04/07

i cambiamenti e le aggiunte al codice vanno integrati
nel sistema ogni due ore, per avere un feedback
immediato sui possibili problemi di integrazione

68
Pratiche Corollarie XP 1/3
Analisi e pianificazione:
le persone la cui vita sarà influenzata dal vostro sistema
Coinvolgimento
devono diventare parte del team, contribuendo alla
reale del cliente
pianificazione trimestrale e settimanale.
(real customer involvement)

Rilasci
incrementali
(incremental deployment)

nel caso di rimpiazzo di un sistema “legacy”, iniziate da subito
a sostituirne delle funzionalità, e procedete gradualmente a
rimpiazzarlo tutto. Evitate un approcccio “tutto o niente”.

Contratti con
funzionalità negoziate
(negotiated scope contract)

Pay-per-use
(pay-per-use)

05/04/07

i contratti dovrebbero avere tempo, costi e livello di
qualità fissi, ma le funzionalità da realizzare
dovrebbero essere negoziate durante la realizzazione
stessa. É meglio una serie di brevi contratti in
successione, per ridurre il rischio.

se possibile stipulate contratti in cui il cliente paga chi
produce il software proporzionalmente all'uso dello stesso da
parte degli utenti: collegare il flusso di denaro allo sviluppo
del sistema fornisce informazioni tempestive ed accurate.

69
Pratiche Corollarie XP 2/3
Continuità del
(team continuity)

Gruppo di sviluppo e fattori umani
i gruppi di sviluppo devono rimanere per quanto
team
possibile gli stessi, anche attraverso progetti diversi.
Le relazioni che si formano in un gruppo efficace
sono preziose: è sbagliato trattare le risorse umane
come “caselle” da riempire, senza tenere conto delle
persone e delle relazioni esistenti tra di esse.

Team che si restringono
(shrinking teams)

man mano che il team diventa più capace e
produttivo, mantenete il suo carico di lavoro costante,
ma
riducetene
gradualmente
la
dimensione,
mandando i membri in più a formare altri team.
Questo principio contraddice in parte la “Continuità
del team”.

Progettazione
tutte le volte che trovate un errore, eliminatelo ed
Analisi delle cause
eliminatene anche le cause. In tal modo non solo
prime
correggerete l'errore, ma impedirete anche il
(root-cause analysis)
ripetersi di errori simili.

05/04/07

70
Pratiche Corollarie XP 3/3
Codifica e rilascio del software

Codice e test
(code and tests)

Codice condiviso
(shared code)

Una singola base di
codice
(single code base)

Rilasci giornalieri
(daily deployment)

05/04/07

solo il codice e i test sono i manufatti permanenti da
mantenere nel tempo. Gli altri documenti necessari si
possono generare a partire dal codice e dai test.
ogni membro del gruppo di sviluppo deve poter
intervenire in ogni momento su qualsiasi parte del
sistema.
ci deve essere una sola versione “ufficiale” del
sistema. Si può crearne un ramo temporaneo, ma non
deve durare più di poche ore. Le diverse versioni
commerciali del prodotto (branch commerciali) non
rientrano in questo caso.
ogni notte, bisogna rilasciare in produzione il
software. Avere sul PC del software diverso dalla
versione ufficiale rilasciata è rischioso e costoso.

71
Confronto con le pratiche del primo XP
Eliminata:
- Metafora
Ridotta:
- Cliente sul posto
Date per acquisite:
- Standard di
codifica
- Refactoring
Fonte dell'immagine (poi evidenziata):
www.agilexp.org/downloads/NuovoXP.pdf

05/04/07

72
eXtreme Programming

I principi
Sono il ponte tra i valori, sintetici ed astratti,
e le pratiche, che dicono come
effettivamente sviluppare il software.
Fonte: www.agilexp.org/downloads/NuovoXP.pdf

05/04/07

73
eXtreme Programming
Principi XP
●

●

●

●

●

●

●

05/04/07

Umanità
Economia
Mutuo beneficio
Auto-similarità
Miglioramento
Diversità
Riflessione

●

●

●

●

●

●

●

Flusso
Opportunità
Ridondanza
Fallimento
Qualità
Piccoli Passi
Accettare la responsabilità

74
eXtreme Programming

Domande ?

05/04/07

75
Saluti e Riferimenti

05/04/07

76
Riferimenti
Libri:
●

Extreme Programming Explained [2nded] – Kent Beck

●

Refactoring – Martin Fowler

●

Test Driven Development – Kent Beck

●

Lean Software Development – M.&T. Poppendieck

●

Agile Software Development with SCRUM – K.
Schwaber, M. Beedle

●

Agile Software Development – A. Cockburn

●

Pair Programming Illuminated – L. Williams, R. Kessler

05/04/07

Agile @ ERLUG

77
Riferimenti
Su internet:
●

http://www.extremeprogramming.org/

●

http://www.testdriven.com/

●

http://martinfowler.com/articles.html
– New

Metodology – M. Fowler

– ...
●

http://alistair.cockburn.us/index.php -> Articles

●

The Cathederal And The Bazaar – E. Raymond

●

...

05/04/07

Agile @ ERLUG

78

More Related Content

PDF
Delphi & Dintorni Webinar - Padroneggiare i principi SOLID con Delphi
PDF
Extreme Programming
PPTX
Personalised Terms Derivative- Semantic Stemming
PDF
Apache Spark 2.0: A Deep Dive Into Structured Streaming - by Tathagata Das
PDF
Le 12 pratiche
PPT
Agile software lifecycle
PDF
I processi di sviluppo software: l'evoluzione agile ed il DevOps
PDF
Intoduzione Alle Metodologie Agili
Delphi & Dintorni Webinar - Padroneggiare i principi SOLID con Delphi
Extreme Programming
Personalised Terms Derivative- Semantic Stemming
Apache Spark 2.0: A Deep Dive Into Structured Streaming - by Tathagata Das
Le 12 pratiche
Agile software lifecycle
I processi di sviluppo software: l'evoluzione agile ed il DevOps
Intoduzione Alle Metodologie Agili

Similar to Presentazione eXtreme Programming (20)

PDF
Lezione 3: Sviluppo in Extreme Programming
PDF
Stop Meeting, Start Coding!
PDF
Manifesto per lo Sviluppo Agile di Software
PDF
Il modello collaborativo dell'open source per lo sviluppo software
PDF
Lezione 1: I metodi agili
PPTX
Alm pills - Sessione community tour Dot Net Umbria 2011
PDF
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...
PPTX
Agile Engineering
ODP
Slide Wallabiez Agile Day 2007
PDF
Il programmatore
PDF
La governance de iprogetti agili
PDF
Manuale Agile Stelnet
PPT
Agile project management 1 giornata - board game - v2
PDF
Back to Agile - Codemotion 2013
PPTX
Semplicemente Agile
PPT
Agile e l’arte di semplificare progetti complessi
PDF
Agile e Lean in sintesi
PDF
Management per l'innovazione: la metodologia Agile (principi e applicazione)
PDF
Le pratiche ingegneristiche di eXtreme Programming
PDF
Festivalmente: Getting Things done
Lezione 3: Sviluppo in Extreme Programming
Stop Meeting, Start Coding!
Manifesto per lo Sviluppo Agile di Software
Il modello collaborativo dell'open source per lo sviluppo software
Lezione 1: I metodi agili
Alm pills - Sessione community tour Dot Net Umbria 2011
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...
Agile Engineering
Slide Wallabiez Agile Day 2007
Il programmatore
La governance de iprogetti agili
Manuale Agile Stelnet
Agile project management 1 giornata - board game - v2
Back to Agile - Codemotion 2013
Semplicemente Agile
Agile e l’arte di semplificare progetti complessi
Agile e Lean in sintesi
Management per l'innovazione: la metodologia Agile (principi e applicazione)
Le pratiche ingegneristiche di eXtreme Programming
Festivalmente: Getting Things done
Ad

More from Roberto Bettazzoni (18)

PDF
Trasformare il debito tecnico in un vantaggio competitivo
PDF
The mythical technical debt. (Brooks, please, forgive me)
PDF
Giornat Mondiale della Retrospettiva 2020 - Riassunto Meetup Remoto
PDF
Complexity indicators: estimation precision and test types
PDF
Why you need to change your way of working
PDF
TDD Dojo - Test Driven Development Coding Dojo
PDF
Presentation of agile engineering practices
PDF
Unit test in a nutshell
PDF
Presentation TDD in Python
PDF
Cynefin Lego Game Agenda (versione 2.0 in Italiano)
PDF
Pair programming and pair training
PDF
Agile e Open Source
PDF
Esempio di code kata
PDF
Una fugace occhiata al Test Driven Development (2006)
PDF
Scrum in a nutshell
PDF
The BDD live show (ITA)
PDF
Programmazione android per esseri umani
PDF
Useful Lean Tools: Value Stream Mapping and Kanban
Trasformare il debito tecnico in un vantaggio competitivo
The mythical technical debt. (Brooks, please, forgive me)
Giornat Mondiale della Retrospettiva 2020 - Riassunto Meetup Remoto
Complexity indicators: estimation precision and test types
Why you need to change your way of working
TDD Dojo - Test Driven Development Coding Dojo
Presentation of agile engineering practices
Unit test in a nutshell
Presentation TDD in Python
Cynefin Lego Game Agenda (versione 2.0 in Italiano)
Pair programming and pair training
Agile e Open Source
Esempio di code kata
Una fugace occhiata al Test Driven Development (2006)
Scrum in a nutshell
The BDD live show (ITA)
Programmazione android per esseri umani
Useful Lean Tools: Value Stream Mapping and Kanban
Ad

Presentazione eXtreme Programming

  • 2. eXtreme Programming eXtreme Programming Descritta nel secondo libro bianco Beck, K and Andres, Extreme Programming Explained: Embrace Change (2nd Edition), Addison-Wesley, 2005 05/04/07 60
  • 3. eXtreme Programming La metodologia XP descritta nel primo libro bianco Ken Beck, Extreme Programming Explained, Addison-Wesley, 1999 Verrà specificata come la 'prima XP' 05/04/07 61
  • 4. eXtreme Programming Per questa presentazione abbiamo preso spunto, oltre che dalla 'letteratura ufficiale', dall'articolo di presentazione del secondo libro bianco scritto dal Prof. Michele Marchesi www.agilexp.org/downloads/NuovoXP.pdf Otto pagine consigliate 05/04/07 62
  • 5. eXtreme Programming Valori Sono la base filosofica della metodologia. I valori XP sono mappabili nei valori dell'Agile Manifesto. 05/04/07 ● Comunicazione ● Semplicità ● Feedback ● Coraggio ● Rispetto 63
  • 6. eXtreme Programming Le pratiche come sviluppare il software. 05/04/07 64
  • 7. eXtreme Programming Le pratiche XP 13 pratiche primarie 11 pratiche corollarie Primarie: possono essere applicate singolarmente. Corollarie: richiedono l'applicazione di una o più pratiche primarie 05/04/07 65
  • 8. Pratiche Primarie XP 1/3 Analisi e pianificazione Storie (stories) Ciclo settimanale (weekly cycle) Ciclo trimestrale (quarterly cycle) Margine di sicurezza (slack) 05/04/07 sono brevi descrizioni di una funzionalità del sistema, la cui implementazione ne guida lo sviluppo. lo sviluppo avviene per cicli di una settimana, con una riunione di inizio in cui si decide quali storie implementare. ogni tre mesi si pianifica lo sviluppo su scala più larga, riflettendo anche sul processo usato, sul team, sull’allineamento con gli obiettivi aziendali. evitate di promettere cose che non si possono mantenere, ed anzi abbiate sempre ad ogni iterazione delle storie che si possono differire alla successiva, per mantenere un margine di sicurezza in casi di problemi imprevisti. 66
  • 9. Pratiche Primarie XP 2/3 Gruppo di sviluppo e fattori umani il team di sviluppo deve lavorare in un ambiente aperto Sedere insieme capace di ospitarlo tutto, per massimizzare la comunicazione. (sit together) Team completo (whole team) il team deve essere composto di membri con competenze diversificate e complementari, che abbiamo forte senso di appartenenza e si aiutino a vicenda. Ambiente di lavoro informativo (informative workspace) Energia sul lavoro (energized work) gli sviluppatori devono essere freschi e riposati, per poter concentrarsi sul lavoro e rendere al massimo; quindi, occorre limitare gli straordinari e ciascuno deve avere il tempo per una vita privata. Programmazione a coppie (pair programming) 05/04/07 l’ambiente di lavoro deve essere fornito di cartelli indicanti lo stato del progetto ed il lavoro da svolgere. il codice deve essere sempre scritto da una coppia di programmatori, seduti ad un unico terminale. 67
  • 10. Pratiche Primarie XP 3/3 Progettazione l'XP rifugge dal “big design upfront”, e cerca di scrivere il Progetto prima possibile del codice per ottenere feedback, incrementale migliorandone poi la struttura in continuazione. L'XP (incremental design) suggerisce di progettare incrementalmente durante tutto lo sviluppo. Programmazione guidata dai test (test-first programming) Build di dieci (ten-minute build) prima di modificare o aggiungere del codice, scrivete dei test per verificare lo stesso codice. Ciò risolve quattro problemi: cowboy coding; basso accoppiamento ed alta coesione del codice; fiducia dei propri compagni; buon ritmo di lavoro. Codifica e rilascio del software il “build” del sistema, inclusa l’esecuzione dei test minuti automatici, deve durare non più di dieci minuti, per poter essere eseguito spesso ed ottenere il necessario feedback. Integrazione continua (continuous integration) 05/04/07 i cambiamenti e le aggiunte al codice vanno integrati nel sistema ogni due ore, per avere un feedback immediato sui possibili problemi di integrazione 68
  • 11. Pratiche Corollarie XP 1/3 Analisi e pianificazione: le persone la cui vita sarà influenzata dal vostro sistema Coinvolgimento devono diventare parte del team, contribuendo alla reale del cliente pianificazione trimestrale e settimanale. (real customer involvement) Rilasci incrementali (incremental deployment) nel caso di rimpiazzo di un sistema “legacy”, iniziate da subito a sostituirne delle funzionalità, e procedete gradualmente a rimpiazzarlo tutto. Evitate un approcccio “tutto o niente”. Contratti con funzionalità negoziate (negotiated scope contract) Pay-per-use (pay-per-use) 05/04/07 i contratti dovrebbero avere tempo, costi e livello di qualità fissi, ma le funzionalità da realizzare dovrebbero essere negoziate durante la realizzazione stessa. É meglio una serie di brevi contratti in successione, per ridurre il rischio. se possibile stipulate contratti in cui il cliente paga chi produce il software proporzionalmente all'uso dello stesso da parte degli utenti: collegare il flusso di denaro allo sviluppo del sistema fornisce informazioni tempestive ed accurate. 69
  • 12. Pratiche Corollarie XP 2/3 Continuità del (team continuity) Gruppo di sviluppo e fattori umani i gruppi di sviluppo devono rimanere per quanto team possibile gli stessi, anche attraverso progetti diversi. Le relazioni che si formano in un gruppo efficace sono preziose: è sbagliato trattare le risorse umane come “caselle” da riempire, senza tenere conto delle persone e delle relazioni esistenti tra di esse. Team che si restringono (shrinking teams) man mano che il team diventa più capace e produttivo, mantenete il suo carico di lavoro costante, ma riducetene gradualmente la dimensione, mandando i membri in più a formare altri team. Questo principio contraddice in parte la “Continuità del team”. Progettazione tutte le volte che trovate un errore, eliminatelo ed Analisi delle cause eliminatene anche le cause. In tal modo non solo prime correggerete l'errore, ma impedirete anche il (root-cause analysis) ripetersi di errori simili. 05/04/07 70
  • 13. Pratiche Corollarie XP 3/3 Codifica e rilascio del software Codice e test (code and tests) Codice condiviso (shared code) Una singola base di codice (single code base) Rilasci giornalieri (daily deployment) 05/04/07 solo il codice e i test sono i manufatti permanenti da mantenere nel tempo. Gli altri documenti necessari si possono generare a partire dal codice e dai test. ogni membro del gruppo di sviluppo deve poter intervenire in ogni momento su qualsiasi parte del sistema. ci deve essere una sola versione “ufficiale” del sistema. Si può crearne un ramo temporaneo, ma non deve durare più di poche ore. Le diverse versioni commerciali del prodotto (branch commerciali) non rientrano in questo caso. ogni notte, bisogna rilasciare in produzione il software. Avere sul PC del software diverso dalla versione ufficiale rilasciata è rischioso e costoso. 71
  • 14. Confronto con le pratiche del primo XP Eliminata: - Metafora Ridotta: - Cliente sul posto Date per acquisite: - Standard di codifica - Refactoring Fonte dell'immagine (poi evidenziata): www.agilexp.org/downloads/NuovoXP.pdf 05/04/07 72
  • 15. eXtreme Programming I principi Sono il ponte tra i valori, sintetici ed astratti, e le pratiche, che dicono come effettivamente sviluppare il software. Fonte: www.agilexp.org/downloads/NuovoXP.pdf 05/04/07 73
  • 16. eXtreme Programming Principi XP ● ● ● ● ● ● ● 05/04/07 Umanità Economia Mutuo beneficio Auto-similarità Miglioramento Diversità Riflessione ● ● ● ● ● ● ● Flusso Opportunità Ridondanza Fallimento Qualità Piccoli Passi Accettare la responsabilità 74
  • 19. Riferimenti Libri: ● Extreme Programming Explained [2nded] – Kent Beck ● Refactoring – Martin Fowler ● Test Driven Development – Kent Beck ● Lean Software Development – M.&T. Poppendieck ● Agile Software Development with SCRUM – K. Schwaber, M. Beedle ● Agile Software Development – A. Cockburn ● Pair Programming Illuminated – L. Williams, R. Kessler 05/04/07 Agile @ ERLUG 77
  • 20. Riferimenti Su internet: ● http://www.extremeprogramming.org/ ● http://www.testdriven.com/ ● http://martinfowler.com/articles.html – New Metodology – M. Fowler – ... ● http://alistair.cockburn.us/index.php -> Articles ● The Cathederal And The Bazaar – E. Raymond ● ... 05/04/07 Agile @ ERLUG 78