Post on 23-Jan-2015
description
transcript
02/04/07 1
Introduzione alle metodologieIntroduzione alle metodologiee pratiche agilie pratiche agili
...ma Agile c'entra qualcosa con l'Open Source?...ma Agile c'entra qualcosa con l'Open Source?
RelatoriRelatori
Ilias Bartoliniilias.bartolini@gmail.com
Roberto Bettazzoniroberto@bettazzoni.it
http://creativecommons.org/licenses/by-sa/3.0/
02/04/07 2
ProgrammaProgramma
Stima
Presentazione 3 min.
Presentazione delle Metodologie Agili 20 min.
Q&A sulle metodologie 5 min.
Presentazione delle Pratiche Agili 20 min.
Q&A sulle pratiche 5 min.
Scelta tra alcune presentazioni / discussioni inScelta tra alcune presentazioni / discussioni inbase al vostro interesse ed al tempo restante base al vostro interesse ed al tempo restante
Saluti e riferimenti 3 min.
Q&A di argomenti specifici Fuori
02/04/07 3
Parte a richiestaParte a richiesta
Stima
Esempio d'applicazione di tecniche Agili 15 min.
Metodologie agili e l'Open Source 10 min.
Agile e OSS distribuito
Come sopra con un approfondimento sullepratiche agili distribuite
15 min.
Approfondimento sull'eXtreme Programming 15 min.
Argomento proposto da voi
A ruota libera
Se vi interessa scambiare informazioni aruota libera o fare altre domande
02/04/07 4
Parte 1Parte 1Metodologie AgiliMetodologie Agili
02/04/07 5
Pratiche agili ... cosa sono?Pratiche agili ... cosa sono?
Pratiche agili ... cosa sono?
Sono le pratiche utilizzate nelle metodologie agili.
02/04/07 6
Metodologie agili ... cosa sono?Metodologie agili ... cosa sono?
Metodologie agili ... cosa sono?
Sono le metodologie basate sui valori dell'Agile Manifesto
02/04/07 Agile @ ERLUG 7
Il Manifesto dell'Alleanza AgileIl Manifesto dell'Alleanza Agile
Stiamo portando alla luce metodi migliori di sviluppare softwarefacendolo in prima persona e aiutando altri a farlo. Attraverso questo
tipo di lavoro siamo giunti ai seguenti valori:
Persone e interazioni più che processi e tools
Software che funziona più che una documentazione esaustiva
Collaborazione con il cliente più che negoziazione contrattuale
Rispondere al cambiamento più che seguire un piano prestabilito
Cioè, mentre c'è un valore nelle voci sulla destra, attribuiamo un valore maggiore a quelle sulla sinistra.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
© 2001, gli autori sopra citati. Questa dichiarazione può essere copiata in ogni forma, ma solo nella sua interezza, compresa la presente nota.
02/04/07 Agile @ ERLUG 8
Metodologie e praticheMetodologie e pratiche
● Metodologia
Insieme di pratiche legate tra loro da una visione filosofica d'insieme.
Es: Scrum
● Pratica
Modalità per il conseguimento di uno scopo. Spesso è formulata in sequenze di passi.
Es: Standup meeting
Queste definizioni, nella loro accezione generica, sono fonte di numerose discussioni.Devono essere considerate come semplificazione per i nostri scopi.
02/04/07 Agile @ ERLUG 9
Metodologie AgiliMetodologie Agili
Rispondere al cambiamento
più che seguire un piano prestabilito
02/04/07 Agile @ ERLUG 10
Metodologie AgiliMetodologie Agili
Rispondere al cambiamento
più che seguire un piano prestabilito
Cambia il metodo di approccio al problema.
02/04/07 Agile @ ERLUG 11
Metodologie AgiliMetodologie Agili
Le metodologie 'storiche' hanno un approccio
PREDITTIVO(elaborare un piano e seguirlo)
Le metodologie agili hanno un approccio ADATTATIVO
(rispondere al cambiamento)
02/04/07 Agile @ ERLUG 12
Approccio PredittivoApproccio Predittivo
● Specifiche fissate● Condizioni al contorno
note● Metodo
● Progetto la soluzione● La applico
02/04/07 Agile @ ERLUG 13
Approccio AdattativoApproccio Adattativo
● Specifiche instabili● Condizioni al contorno
variabili● Metodo.
● Micro decisioni continue. Sviluppo quello che in quel momento genera maggiore valore per il cliente.
● verifico il valore prodotto.
02/04/07 Agile @ ERLUG 14
La differenza c'èLa differenza c'è
Cosa comporta questa diversa filosofia?
02/04/07 Agile @ ERLUG 15
Cosa comporta questa differenza?Cosa comporta questa differenza?
Pratiche e strumenti ad
hoc
02/04/07 Agile @ ERLUG 16
Cosa comporta questa differenza?Cosa comporta questa differenza?
Con una base in comune
02/04/07 17
Un passo indietro ... cosa c'era prima?Un passo indietro ... cosa c'era prima?
Le metodologie a cui l'agile si contrapponeva● Nesuna metodologia (Cowboy coding)● Modello a Cascata (Waterfall)
● La metodologia di costruzione 'storica', basato sull'esperienza manifatturiera.
● Modello iterativo (Iterative)● Basato sul waterfall, permette di avere rilasci più
frequenti, fornendo incrementalmente « parti » del prodotto finale (o prototipi)
02/04/07 18
Modello a cascataModello a cascata
L'applicazione del modello a cascata nello sviluppo software.
02/04/07 19
Modello a cascataModello a cascata
I caposaldi● Il processo di sviluppo è diviso in fasi sequenziali● Ogni fase produce un output che è usato come input per
la fase successiva● Ogni fase del processo viene documentata
Fonte: http://it.wikipedia.org/wiki/Modello_a_cascata
02/04/07 20
Modello a cascataModello a cascata
Fasi del modello a cascatastudio di fattibilità
analisi dei requisiti
progetto
sviluppo
collaudo
integrazione
manutenzione
Fonte: http://it.wikipedia.org/wiki/Modello_a_cascata
02/04/07 21
Modello a cascataModello a cascata
Altri capisaldi nelle applicazioni reali● Comunicazione formale
● Lo scambio di informazioni viene considerato un output della fase.
● Ruoli● Identifica un certo insieme di responsabilità attribuite a un
certo insieme di persone.
● Gerarchia● La verifica dell'output prodotto da ogni fase viene mappato
su una gerarchia (solitamente quella aziendale).
02/04/07 22
Modello a cascataModello a cascata
02/04/07 23
Funziona ?Funziona ?
Fine dei progetti
● Pieno successo. Competati in tempo e con tutte le funzionalità
● Sottostimati o parziali. Sottostimato il tempo e/o il costo oppure implementati con minori funzionalità di quelle richieste
● Falliti. Il progetto è stato abbandonato durante lo sviluppo.
Fonte: http://www.standishgroup.com/sample_research/chaos_1994_1.php
02/04/07 24
The CHAOS Report 1994The CHAOS Report 1994
Fonte: http://www.standishgroup.com/sample_research/chaos_1994_1.php
Analisi delle cause
02/04/07 25
L'origine dei fallimenti era già notaL'origine dei fallimenti era già nota
Frederick P. Brooks, “No Silver Bullet", IFIP, 1986
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.
If this is true, building software will always be hard. There is inherently no silver bullet.
Tom DeMarco & Timothy Lister, “Peopleware” , pag. 5, 1987
For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure.
02/04/07 26
Modelli a iterazioniModelli a iterazioni
● Maggiore cura nell'analisi dei requisiti
● Pratiche ad hoc per l'analisi ed il design
● Fornire una parte del prodotto (o un prototipo) il prima possibile
● Validare o modificare i requisiti sulla base del rilascio precedente
● Convergere verso l'applicazione richiesta
02/04/07 27
Modelli a iterazioniModelli a iterazioni
● Specializzazione dell'analisi e del design● Vengono effettuati rilasci parziali che
incrementalmente portano al prodotto richiesto
● Ogni rilascio segue un 'piccolo' modello a cascata
Come ?
02/04/07 28
Modelli a iterazioniModelli a iterazioni
02/04/07 29
Modelli a iterazioniModelli a iterazioni
Fonte: http://en.wikipedia.org/wiki/RUP
02/04/07 30
The CHAOS Report 2003The CHAOS Report 2003
Fonte:http://www.standishgroup.com/press/article.php?id=2
Fine dei progetti
● Pieno successo. Competati in tempo e con tutte le funzionalità
● Sottostimati o parziali. Sottostimato il tempo e/o il costo oppure implementati con minori funzionalità di quelle richieste
● Falliti. Il progetto è stato abbandonato durante lo sviluppo.
02/04/07 31
Confronto The CHAOS Report '94 - '03Confronto The CHAOS Report '94 - '03
02/04/07 32
Modelli a iterazioniModelli a iterazioni
● Migliore probabilità di produrre ciò che è richiesto nei requisiti
● Reazione agli errori più veloce
● Forte dipendenza dalla stabilità dei requisiti
● Comunicazioni formali e lente
PROPRO
CONTRO
02/04/07 33
Chi lo ha detto ?Chi lo ha detto ?
Distribuisci presto. Distribuisci spesso. E presta ascolto agli utenti.
La cosa migliore, dopo l'avere buone idee, è riconoscere quelle che arrivano dagli utenti. Qualche volta sono le migliori.
02/04/07 34
Eric S. RaymondEric S. Raymond
7. Distribuisci presto. Distribuisci spesso. E presta ascolto agli utenti.
11. La cosa migliore, dopo l'avere buone idee, è riconoscere quelle che arrivano dagli utenti. Qualche volta sono le migliori.
Eric S. Raymond, La Cattedrale ed il Bazaar, 1998
02/04/07 35
Lezione imparataLezione imparata
● Il lavoro è svolto dalle persone.● Una persona coinvolta e motivata lavora meglio.
● Un gruppo di persone affiatate lavora meglio.
● Una persona con una visione più ampia del problema ha più possibilità di risolverlo.
● Più persone conoscono il problema più è facile trovare la soluzione.
● I clienti e gli utenti sono persone
02/04/07 36
Lezione imparataLezione imparata
Feedback● Trarre insegnamento dalla verifica del lavoro
compiuto (proprio ed altrui) ● Analizzare quello che si è fatto per migliorarsi● Condividere l'esperienza con gli altri● Insegnare mediante l'esempio
● La storia insegna
02/04/07 37
Lezione imparataLezione imparata
La conoscenza si trasmette con la comunicazione.
● La comunicazione diretta è più efficace di quella formale.
● La conoscenza deve essere il più possibile condivisa ed espressa nel linguaggio appropriato.
02/04/07 38
Lezione imparataLezione imparata
Dare all'utente ciò che vuole il prima possibile
● Lavorare in base alle esigenze dell'utente
● Rilasciare il prima possibile
02/04/07 39
Lezione imparataLezione imparata
La stabilità dei requisiti è vitale,
ma nel mondo reale è rara
... cambiamo il mondo reale
o ci adattiamo?
02/04/07 Agile @ ERLUG 40
Il Manifesto dell'Alleanza AgileIl Manifesto dell'Alleanza Agile
Stiamo portando alla luce metodi migliori di sviluppare softwarefacendolo in prima persona e aiutando altri a farlo. Attraverso questo
tipo di lavoro siamo giunti ai seguenti valori:
Persone e interazioni più che processi e tools
Software che funziona più che una documentazione esaustiva
Collaborazione con il cliente più che negoziazione contrattuale
Rispondere al cambiamento più che seguire un piano prestabilito
Cioè, mentre c'è un valore nelle voci sulla destra, attribuiamo un valore maggiore a quelle sulla sinistra.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
© 2001, gli autori sopra citati. Questa dichiarazione può essere copiata in ogni forma, ma solo nella sua interezza, compresa la presente nota.
02/04/07 Agile @ ERLUG 41
Alcune metodologie agili di sviluppo swAlcune metodologie agili di sviluppo sw
● Adaptive Software Development (ASD)
● Agile Unified Process (AUP)
● Crystal Clear
● Extreme Programming (XP)
● Feature Driven Development (FDD)
● Lean software development
● Scrum
● ...........
02/04/07 Agile @ ERLUG 42
Alcune pratiche agiliAlcune pratiche agili
● Agile Modeling [and Data Methods]
● Agile Software Configuration Management
● Database refactoring
● Pair programming
● Planning Game
● Value Stream Mapping
● Test-Driven Development (TDD)
● ...
02/04/07 Agile @ ERLUG 43
Metodologie AgiliMetodologie Agili
Domande?
02/04/07 Agile @ ERLUG 44
Riassunto Metodologie PredittiveRiassunto Metodologie Predittive
02/04/07 Agile @ ERLUG 45
Riassunto Metodologie adattativeRiassunto Metodologie adattative
02/04/07 Agile @ ERLUG 46
Riassunto metodologie adattativeRiassunto metodologie adattative
02/04/07 Agile @ ERLUG 47
Extreme ProgrammingExtreme Programming
Extreme Programming Explained [2nded] – Kent Beck
Valori
Principi
Pratiche
(approfondimento a dopo)
02/04/07 Agile @ ERLUG 48
Lean Software DevelopmentLean Software Development
Taiici Hono – 1988The Toyota Production System
"Only after American carmakers had exhausted every other explanation for Toyota's success—an undervalued yen, a docile workforce, Japanese culture, superior automation—were they finally able to admit that Toyota's real advantage was its ability to harness the intellect of 'ordinary' employees."
Gary Hamel, Harvard Business Review, 02/2006
02/04/07 Agile @ ERLUG 49
Lean Software DevelopmentLean Software Development
Applicazione dei principi del metodo Toyota allo sviluppo software:
Lean Software Development – M.&T. Poppendieck
1. Elimina gli sprechi! (MUDA)
● Extra-feature, difetti, lavoro inconcluso, re-learning, attese, logistica (distribuzione)
2. Creare qualità dall'interno (codice)
● Testing, Continuous integration, Rafactoring
3. Creare conoscenza
02/04/07 Agile @ ERLUG 50
Lean Software DevelopmentLean Software Development
1. Eliminare gli sprechi! (MUDA)
● Extra-feature, difetti, lavoro inconcluso, re-learning, attese, logistica (distribuzione)
2. Creare qualità dall'interno (codice)
● Testing, Continuous integration, Rafactoring
3. Creare conoscenza
02/04/07 Agile @ ERLUG 51
Lean Software DevelopmentLean Software Development
4. Decidere all'ultimo momento
● Non troppo presto: potresti non avere abbastanza informazioni
● Non troppo tardi: potresti non essere in grado di attuare la decisione
5. Rilasciare in fretta
● Value Stream Map
6. Ottimizzare tutto l'insieme
● Rimuovi i circoli-viziosi
02/04/07 Agile @ ERLUG 52
Lean Software DevelopmentLean Software Development
7. Rispettare le persone
● Coinvolgimento allargato nel processo decisionale● Best practice continuamente sottoposte a critica● Dare ai gruppi di lavoro spazio per sperimentare
le proprie idee
02/04/07 Agile @ ERLUG 53
CrystalCrystal
Sviluppo Software: un gioco cooperativo di invenzione e comunicazione tra persone
● Ogni metodologia deve essere più leggera possibile ma «sufficiente» al raggiungimento dell'obiettivo
● Non esiste «UNA» metodologia. Ogni processo si adatta a diverse situazioni: numero di persone, obiettivi primari da raggiungere, criticalità.
02/04/07 Agile @ ERLUG 54
CrystalCrystal
7 principi per il disegno delle metodologie:● Più formalismi => più costi iniziali e meno adattabilità● Più comunicazione face-to-face● Più fiducia nelle persone permette meno formalismi● Progetti grandi richiedono maggiori formalismi● Più meccanismi di feedback interno riducono la necessità
di prodotti intermedi● Rimozione dei «colli di bottiglia» del processo: migliori
persone; migliori strumenti; maggiore completezza dei passi precedenti; più persone
● Skill, disciplina, conoscenza vs formalismi, processi, documentazione
02/04/07 Agile @ ERLUG 55
ScrumScrum
Agile Software Development with SCRUM – K. Schwaber, M. Beedle
Product Backlog
SprintBacklog
Product
Sprint
Daily Scrum
SprintReview
02/04/07 56
Parte 2Parte 2PratichePratiche
02/04/07 Agile @ ERLUG 57
Alcune pratiche AgiliAlcune pratiche Agili
● Implementazione● Test Driven Development● Refactoring● Pair Programming● ...
● Organizzazione● Stand-Up Meeting / Daily Scrum● Shared Code / Collective Code Ownership● ...
02/04/07 Agile @ ERLUG 58
Alcune pratiche AgiliAlcune pratiche Agili
● Gestione e pianiifcazione● Continuous Integration● Release frequenti● Customer On Site / Coinvolgimento Reale● User Stories e Planning game● ...
02/04/07 Agile @ ERLUG 59
Stand-Up Meeting / Daily ScrumStand-Up Meeting / Daily Scrum
Non più di 10-20 minuti
Ogni giorno: ● Stessa ora ● Stesso posto
3 domande:● Cosa è stato fatto?● Che difficoltà si sono incontrate?● Cosa si è pianificato prima del prossimo incontro?
Eventualmente guidati da un moderatore/facilitatore
02/04/07 Agile @ ERLUG 60
Stand-Up Meeting / Daily ScrumStand-Up Meeting / Daily Scrum
Condivisione degli obiettivi a breve termine
Comunicazione degli stati di avanzamento
Permette alle criticità di emergere!
Stimola la auto organizzazione
Stimola il «rispetto reciproco»
Trasforma un «insieme di persone» in un «gruppo»
http://www.martinfowler.com/articles/itsNotJustStandingUp.html
02/04/07 Agile @ ERLUG 61
Pair ProgrammingPair Programming
Due persone, un unico task, una sola tastiera● Il «pilota» scrive il codice● Il «navigatore» verifica e pensa al prossimo
passo
02/04/07 Agile @ ERLUG 62
Pair ProgrammingPair Programming
Per un buon pair-programming:● Il navigatore non deve dormire :)● Invertire i ruoli ogni tanto: strappare la tastiera
dalle mani!● Ruotare le coppie ogni tanto● Le coppie devono essere eterogenee ed
affiatate ...ma tutti devono imparare a lavorare con tutti (limitazione dell'ego!)
● Ricordarsi di fare delle pause ogni tanto :)
02/04/07 Agile @ ERLUG 63
Pair ProgrammingPair Programming
Perchè pagare due per fare il lavoro di uno?● Due persone in pair generalmente sono meno produttive
...ma meno di quanto ci si aspetti!http://www.comp.polyu.edu.hk/people/doc/cskcchan/pairpaper.pdf
Dipende molto dal contesto, dalle persone e dal tipo di attività
02/04/07 Agile @ ERLUG 64
Pair ProgrammingPair Programming
Però....● Scambio di conoscenze e formazione on-job
● Migliore qualità: meno bachi da risolvere in futuro
● Migliore design: meno costi nell'integrare le future features
● Conoscenza comune del codice
● Affiatamento, aumento della comunicazione e coesione
● Meno distrazioni e più disciplina
02/04/07 Agile @ ERLUG 65
Shared Code / Collective Code OwnershipShared Code / Collective Code Ownership
Chiunque è libero di modificare qualsiasi porzione di codice un qualsiasi parte del
sistema in qualsiasi momento.
Extreme Programming Explained - Kent Beck
Anche questo... non vi suona familiare?
02/04/07 Agile @ ERLUG 66
Shared Code / Collective Code OwnershipShared Code / Collective Code Ownership
● Conoscenza condivisa:
● Ogni membro del team ha una sommaria conoscenza di tutto il codice
● Strumenti condivisi:
● Diventa essenziale l'utilizzo di strumenti di versioning!
● Sicurezza e Integrazione...ringraziamo patch/diff, CVS, SVN, etc.
02/04/07 Agile @ ERLUG 67
Shared Code / Collective Code OwnershipShared Code / Collective Code Ownership
● Responsabilità condivisa:
● non c'è più un unico responsabile di certi moduli software!
● La responsabilità si sposta dal semplice funzionamento verso la qualità del codice
● Se tutti devono poterci mettere le mani e «capire» ...è meglio scrivere buon codice (coding convention?)
02/04/07 Agile @ ERLUG 68
Continuous IntegrationContinuous Integration
Il codice sviluppato deve essere subito a disposizione di tutti
1. Lo sviluppo deve il più possibile avvenire sull'ultima versione del repository/mainline
2. Ogni sviluppatore deve eseguire il commit delle parti sviluppate appena un task/storia viene terminato
● Automatizzare le build
● Automatizzare l'esecuzione dei test
● Automatizzare il deploy
02/04/07 Agile @ ERLUG 69
RefactoringRefactoring
● BDUF: È facile "azzeccare" come progettare la soluzione giusta al primo tentativo?
...poi arrivano nuovi requisiti
...poi ci si accorge di nuove soluzioni
...l'ultima modifica manda in crash il sistema!
...il design è talmente decaduto che non si sa da dove ricominciare :(
● È più facile aggiungere o cancellare codice?● Quanto costa buttarlo via?
02/04/07 Agile @ ERLUG 70
RefactoringRefactoring
Qualcuno aveva già sentito puzza di bruciato:
«Plan to throw one away; you will, anyhow.»
The Mythical Man-Month - Fred Brooks
02/04/07 Agile @ ERLUG 71
RefactoringRefactoring
Processo di modifica evolutiva di un sistema software in modo da non
modificarne il comportamento esterno migliorandone la sua struttura
02/04/07 Agile @ ERLUG 72
RefactoringRefactoring
● modifica il codice in piccoli passi● migliora continuamente il design ● il codice diventa «parlante»● richiede disciplina [il pair programming aiuta]
● la pratica rende perfetti ● richiede un buon «fiuto»
02/04/07 Agile @ ERLUG 73
RefactoringRefactoring
Alcune «puzze» comuni1. codice duplicato
2. metodi/classi lunghe
3. lunghe liste di parametri
4. cambiamenti divergenti
5. shotgun surgery
6. codice «invidioso»
7. liste di switch/if
8. generalizzazione speculativa: «astronauti»
9. commenti!
...ed alcune soluzioni1. estrai la parte duplicata
2. separa le competenze
3. introduci/estrai oggetti
4. separa le competenze
5. riunire la responsabilità
6. muovi/estrai metodo
7. polimorfismo
8. canc, canc, canc, canc, canc, canc, canc, canc
9. nascosto dal deodorante!
02/04/07 Agile @ ERLUG 74
Test Driven Development (TDD)Test Driven Development (TDD)
Nei processi di sviluppo software tradizionali il collaudo si fa alla fine... Nella realtà il collaudo non viene mai fatto :(
Perchè?
+ stress => - test - test => + stress
02/04/07 Agile @ ERLUG 75
Test Driven Development (TDD)Test Driven Development (TDD)
In TDD i test guidano lo sviluppo!
Scrivi i test per una nuova funzionalità
Implementa Rifattorizzail codice
Commit
02/04/07 Agile @ ERLUG 76
Test Driven Development (TDD)Test Driven Development (TDD)
Per un buon TDD:● Pensa ai test prima di pensare l'implementazione
● Una «barra rossa» è meglio di uno schermo bianco
● I test devono essere semplici e leggibili
● I test devono essere isolati
● I test devono essere veloci e lanciati spesso
● Verifica prima il risultato atteso, verifica i casi limite, verifica le eccezioni
● Rifattorizza sia l'implementazione che i test
02/04/07 Agile @ ERLUG 77
Test Driven Development (TDD)Test Driven Development (TDD)
TDD significa anche «Test Driven Design»● Permette di definire l'interfaccia degli oggetti prima
di buttarsi sull'implementazione
● Permette di concentrarsi sul comportamento dell'oggetto
● Permette di rifattorizzare il codice con maggiore confidenza
● Porta alla realizzazione di architetture con basso accoppiamento
02/04/07 Agile @ ERLUG 78
Test Driven Development (TDD)Test Driven Development (TDD)
Con TDD posso anche...● Documentare l'utilizzo dei miei componenti
attraverso i test
● Evitare la regressione dei bug
● Isolare codice legacy
● Dormire un po' più tranquillo la sera dopo il rilascio
02/04/07 Agile @ ERLUG 79
Test Driven Development (TDD)Test Driven Development (TDD)
TDD non è Unit Testing● ...ma sono ottimi amici :)
Come testare le interfacce utente?● Utilizzando tool ad-hoc● Rimuovendo la logica dalle interfacce
Come testare liberandosi da risorse esterne?● Mock
TDD può creare dipendenza! :)
02/04/07 Agile @ ERLUG 80
Test Driven Development (TDD)Test Driven Development (TDD)
Strumenti:● *Unit: JUnit, PyUnit, NUnit, CPPUnit, PHPUnit, ...
● DBUnit, SQLUnit, PL/SQL Unit, ...
● EasyMock, Moquer, MockEJB, ...
● Selenium, HttpUnit, Jmeter, ...
● Fit, Fitnesse, ...
...forse pure troppi
02/04/07 Agile @ ERLUG 81
Tante pratiche... ma da dove comincio?Tante pratiche... ma da dove comincio?
Dipende dal contesto
comincia dai problemi più urgenti
...un passo alla volta...
02/04/07 Agile @ ERLUG 82
Pratiche AgiliPratiche Agili
DOMANDE?