Presentazione eXtreme Programming
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Presentazione eXtreme Programming

on

  • 149 views

2006 Talk di sera ERLUG (Emilia Romagna Linux User Group) ...

2006 Talk di sera ERLUG (Emilia Romagna Linux User Group)
Realizzati insieme ad Ilias Bartolini . 5a e ultima parte
Presentazione di XP vers. 2.0 come descritta dal secondo libro bianco [nota: all'epoca era stato appena pubblicato ... riferimenti non precisi :-) ]

Statistics

Views

Total Views
149
Views on SlideShare
148
Embed Views
1

Actions

Likes
1
Downloads
1
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Presentazione eXtreme Programming Presentation Transcript

  • 1. Parte 5 eXtreme Programming 05/04/07 59
  • 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
  • 17. eXtreme Programming Domande ? 05/04/07 75
  • 18. Saluti e Riferimenti 05/04/07 76
  • 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