2006 Prima serata di una serie di Talk serali all' ERLUG (Emilia Romagna Linux User Group) Presentazione delle Metodologie Agili (confronto con la situazione esistente) Presentazione delle Pratiche Agili Esempio d'applicazione di tecniche Agili Agile e OSS distribuito eXtreme Programming

1. Introduzione alle metodologie
e pratiche agili
...ma Agile c'entra qualcosa con l'Open Source?
Relatori
Ilias Bartolini
ilias.bartolini@gmail.com
Roberto Bettazzoni
roberto@bettazzoni.it
http://creativecommons.org/licenses/by-sa/3.0/
02/04/07
1

2. Programma
Stima
Presentazione
Presentazione delle Metodologie Agili
Q&A sulle metodologie
Presentazione delle Pratiche Agili
Q&A sulle pratiche
3 min.
20 min.
5 min.
20 min.
5 min.
Scelta tra alcune presentazioni / discussioni in
base al vostro interesse ed al tempo restante
Saluti e riferimenti
Q&A di argomenti specifici
02/04/07
3 min.
Fuori
2

3. Parte a richiesta
Stima
Esempio d'applicazione di tecniche Agili
15 min.
Metodologie agili e l'Open Source
10 min.
Agile e OSS distribuito
15 min.
Come sopra con un approfondimento sulle
pratiche agili distribuite
Approfondimento sull'eXtreme Programming
15 min.
Argomento proposto da voi
A ruota libera
Se vi interessa scambiare informazioni a
ruota libera o fare altre domande
02/04/07
3

4. Parte 1
Metodologie Agili
02/04/07
4

5. Pratiche agili ... cosa sono?
Pratiche agili ... cosa sono?
Sono le pratiche utilizzate nelle
metodologie agili.
02/04/07
5

6. Metodologie agili ... cosa sono?
Metodologie agili ... cosa sono?
Sono le metodologie basate sui valori
dell'Agile Manifesto
02/04/07
6

7. Il Manifesto dell'Alleanza Agile
Stiamo portando alla luce metodi migliori di sviluppare software
facendolo 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
7

8. Metodologie e pratiche
●
Pratica
●
Metodologia
Modalità per il
conseguimento di uno
scopo. Spesso è
formulata in sequenze di
passi.
Insieme di pratiche legate
tra loro da una visione
filosofica d'insieme.
Es: Standup meeting
Es: Scrum
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
8

9. Metodologie Agili
Rispondere al cambiamento
più che
seguire un piano prestabilito
02/04/07
Agile @ ERLUG
9

10. Metodologie Agili
Rispondere al cambiamento
più che
seguire un piano prestabilito
Cambia il metodo di approccio al problema.
02/04/07
Agile @ ERLUG
10

11. Metodologie 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
11

12. Approccio Predittivo
●
●
●
Specifiche fissate
Condizioni al contorno
note
Metodo
●
●
02/04/07
Progetto la soluzione
La applico
Agile @ ERLUG
12

13. Approccio Adattativo
●
●
●
Specifiche instabili
Condizioni al contorno
variabili
Metodo.
●
●
02/04/07
Micro decisioni continue.
Sviluppo quello che in quel
momento genera maggiore
valore per il cliente.
verifico il valore prodotto.
Agile @ ERLUG
13

14. La differenza c'è
Cosa comporta questa diversa filosofia?
02/04/07
Agile @ ERLUG
14

15. Cosa comporta questa differenza?
Pratiche e
strumenti ad
hoc
02/04/07
Agile @ ERLUG
15

16. Cosa comporta questa differenza?
Con una base in
comune
02/04/07
Agile @ ERLUG
16

17. Un passo indietro ... cosa c'era prima?
Le metodologie a cui l'agile si contrapponeva
●
Nesuna metodologia (Cowboy coding)
●
Modello a Cascata (Waterfall)
●
●
'storica',
basato
Modello iterativo (Iterative)
●
02/04/07
La metodologia di costruzione
sull'esperienza manifatturiera.
Basato sul waterfall, permette di avere rilasci più
frequenti, fornendo incrementalmente « parti » del
prodotto finale (o prototipi)
17

18. Modello a cascata
L'applicazione del modello a cascata
nello sviluppo software.
02/04/07
18

19. Modello 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
19

20. Modello a cascata
Fasi del modello a cascata
studio di fattibilità
analisi dei requisiti
progetto
sviluppo
collaudo
integrazione
manutenzione
Fonte: http://it.wikipedia.org/wiki/Modello_a_cascata
02/04/07
20

21. Modello a cascata
Altri capisaldi nelle applicazioni reali
●
Comunicazione formale
●
●
Ruoli
●
●
Identifica un certo insieme di responsabilità attribuite a un
certo insieme di persone.
Gerarchia
●
02/04/07
Lo scambio di informazioni viene considerato un output
della fase.
La verifica dell'output prodotto da ogni fase viene mappato
su una gerarchia (solitamente quella aziendale).
21

22. Modello a cascata
02/04/07
22

23. 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
23

24. The CHAOS Report 1994
Analisi delle cause
Fonte: http://www.standishgroup.com/sample_research/chaos_1994_1.php
02/04/07
24

25. L'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
25

26. Modelli a iterazioni
●
Maggiore cura nell'analisi dei requisiti
●
Pratiche ad hoc per l'analisi ed il design
●
●
●
02/04/07
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
26

27. Modelli a iterazioni
Come ?
●
●
●
02/04/07
Specializzazione dell'analisi e del design
Vengono effettuati rilasci parziali che
incrementalmente portano al prodotto
richiesto
Ogni rilascio segue un 'piccolo' modello a
cascata
27

28. Modelli a iterazioni
02/04/07
28

29. Modelli a iterazioni
Fonte: http://en.wikipedia.org/wiki/RUP
02/04/07
29

30. The CHAOS Report 2003
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/press/article.php?id=2
02/04/07
30

31. Confronto The CHAOS Report '94 - '03
02/04/07
31

32. Modelli a iterazioni
PRO
●
●
Migliore probabilità di produrre ciò che è richiesto
nei requisiti
Reazione agli errori più veloce
CONTRO
●
●
02/04/07
Forte dipendenza dalla stabilità dei requisiti
Comunicazioni formali e lente
32

33. 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
33

34. Eric 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
34

35. Lezione imparata
●
Il lavoro è svolto dalle persone.
●
●
Una persona con una visione più ampia del problema
ha più possibilità di risolverlo.
●
02/04/07
Un gruppo di persone affiatate lavora meglio.
●
●
Una persona coinvolta e motivata lavora meglio.
Più persone conoscono il problema più è facile trovare
la soluzione.
I clienti e gli utenti sono persone
35

36. Lezione imparata
Feedback
●
Trarre insegnamento dalla verifica del lavoro
compiuto (proprio ed altrui)
●
●
02/04/07
Condividere l'esperienza con gli altri
●
●
Analizzare quello che si è fatto per migliorarsi
Insegnare mediante l'esempio
La storia insegna
36

37. Lezione imparata
La conoscenza si trasmette con la
comunicazione.
●
●
02/04/07
La comunicazione diretta è più efficace di
quella formale.
La conoscenza deve essere il più possibile
condivisa ed espressa nel linguaggio
appropriato.
37

38. Lezione imparata
Dare all'utente ciò che vuole il prima possibile
●
Lavorare in base alle esigenze dell'utente
●
Rilasciare il prima possibile
02/04/07
38

39. Lezione imparata
La stabilità dei requisiti è vitale,
ma nel mondo reale è rara
... cambiamo il mondo reale
o ci adattiamo?
02/04/07
39

40. Il Manifesto dell'Alleanza Agile
Stiamo portando alla luce metodi migliori di sviluppare software
facendolo 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
40

41. Alcune 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
41

42. Alcune 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
42

43. Metodologie Agili
Domande?
02/04/07
Agile @ ERLUG
43

44. Riassunto Metodologie Predittive
02/04/07
Agile @ ERLUG
44

45. Riassunto Metodologie adattative
02/04/07
Agile @ ERLUG
45

46. Riassunto metodologie adattative
02/04/07
Agile @ ERLUG
46

47. Extreme Programming
Extreme Programming Explained [2nded] – Kent Beck
Valori
Principi
Pratiche
(approfondimento a dopo)
02/04/07
Agile @ ERLUG
47

48. Lean Software Development
Taiici Hono – 1988
The 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
48

49. Lean 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
49

50. Lean 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
50

51. Lean 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
●
02/04/07
Rimuovi i circoli-viziosi
Agile @ ERLUG
51

52. Lean Software Development
7. Rispettare le persone
●
●
Best practice continuamente sottoposte a critica
●
02/04/07
Coinvolgimento allargato nel processo decisionale
Dare ai gruppi di lavoro spazio per sperimentare
le proprie idee
Agile @ ERLUG
52

53. Crystal
Sviluppo Software: un gioco cooperativo di
invenzione e comunicazione tra persone
●
●
02/04/07
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à.
Agile @ ERLUG
53

54. Crystal
7 principi per il disegno delle metodologie:
●
●
●
●
●
●
●
02/04/07
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
Agile @ ERLUG
54

55. Scrum
Agile Software Development with SCRUM – K. Schwaber,
M. Beedle
Daily
Scrum
Sprint
Product
Backlog
02/04/07
Sprint
Backlog
Agile @ ERLUG
Sprint
Review
Product
55

56. Parte 2
Pratiche
02/04/07
56

57. Alcune pratiche Agili
●
Implementazione
●
●
Refactoring
●
Pair Programming
●
●
Test Driven Development
...
Organizzazione
●
●
Shared Code / Collective Code Ownership
●
02/04/07
Stand-Up Meeting / Daily Scrum
...
Agile @ ERLUG
57

58. Alcune pratiche Agili
●
Gestione e pianiifcazione
●
●
Release frequenti
●
Customer On Site / Coinvolgimento Reale
●
User Stories e Planning game
●
02/04/07
Continuous Integration
...
Agile @ ERLUG
58

59. Stand-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
59

60. Stand-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
60

61. Pair Programming
Due persone, un unico task, una sola tastiera
●
●
02/04/07
Il «pilota» scrive il codice
Il «navigatore» verifica e pensa al prossimo
passo
Agile @ ERLUG
61

62. Pair Programming
Per un buon pair-programming:
●
●
●
●
●
02/04/07
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 :)
Agile @ ERLUG
62

63. Pair 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
63

64. Pair 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
64

65. Shared 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
65

66. Shared 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
66

67. Shared 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
67

68. Continuous 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 l'esecuzione dei test
●
02/04/07
Automatizzare le build
Automatizzare il deploy
Agile @ ERLUG
68

69. Refactoring
●
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
69

70. Refactoring
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
70

71. Refactoring
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
71

72. Refactoring
●
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
72

73. Refactoring
Alcune «puzze» comuni
...ed alcune soluzioni
1. 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!
1. 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
73

74. 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
74

75. Test Driven Development (TDD)
In TDD i test guidano lo sviluppo!
Implementa
Rifattorizza
il codice
Commit
Scrivi i test per una
nuova funzionalità
02/04/07
Agile @ ERLUG
75

76. 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
●
●
02/04/07
Verifica prima il risultato atteso, verifica i casi limite,
verifica le eccezioni
Rifattorizza sia l'implementazione che i test
Agile @ ERLUG
76

77. Test Driven Development (TDD)
TDD significa anche «Test Driven Design»
●
●
●
●
02/04/07
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
Agile @ ERLUG
77

78. 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
78

79. 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
79

80. 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
80

81. Tante pratiche... ma da dove comincio?
Dipende dal contesto
comincia dai problemi più urgenti
...un passo alla volta...
02/04/07
Agile @ ERLUG
81

82. Pratiche Agili
DOMANDE?
02/04/07
Agile @ ERLUG
82