Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcosa con l'Open Source? (2006)

970 views

Published on

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

Published in: Technology
  • Be the first to comment

Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcosa con l'Open Source? (2006)

  1. 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. 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. 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. 4. Parte 1 Metodologie Agili 02/04/07 4
  5. 5. Pratiche agili ... cosa sono? Pratiche agili ... cosa sono? Sono le pratiche utilizzate nelle metodologie agili. 02/04/07 5
  6. 6. Metodologie agili ... cosa sono? Metodologie agili ... cosa sono? Sono le metodologie basate sui valori dell'Agile Manifesto 02/04/07 6
  7. 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. 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. 9. Metodologie Agili Rispondere al cambiamento più che seguire un piano prestabilito 02/04/07 Agile @ ERLUG 9
  10. 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. 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. 12. Approccio Predittivo ● ● ● Specifiche fissate Condizioni al contorno note Metodo ● ● 02/04/07 Progetto la soluzione La applico Agile @ ERLUG 12
  13. 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. 14. La differenza c'è Cosa comporta questa diversa filosofia? 02/04/07 Agile @ ERLUG 14
  15. 15. Cosa comporta questa differenza? Pratiche e strumenti ad hoc 02/04/07 Agile @ ERLUG 15
  16. 16. Cosa comporta questa differenza? Con una base in comune 02/04/07 Agile @ ERLUG 16
  17. 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. 18. Modello a cascata L'applicazione del modello a cascata nello sviluppo software. 02/04/07 18
  19. 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. 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. 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. 22. Modello a cascata 02/04/07 22
  23. 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. 24. The CHAOS Report 1994 Analisi delle cause Fonte: http://www.standishgroup.com/sample_research/chaos_1994_1.php 02/04/07 24
  25. 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. 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. 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. 28. Modelli a iterazioni 02/04/07 28
  29. 29. Modelli a iterazioni Fonte: http://en.wikipedia.org/wiki/RUP 02/04/07 29
  30. 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. 31. Confronto The CHAOS Report '94 - '03 02/04/07 31
  32. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 43. Metodologie Agili Domande? 02/04/07 Agile @ ERLUG 43
  44. 44. Riassunto Metodologie Predittive 02/04/07 Agile @ ERLUG 44
  45. 45. Riassunto Metodologie adattative 02/04/07 Agile @ ERLUG 45
  46. 46. Riassunto metodologie adattative 02/04/07 Agile @ ERLUG 46
  47. 47. Extreme Programming Extreme Programming Explained [2nded] – Kent Beck Valori Principi Pratiche (approfondimento a dopo) 02/04/07 Agile @ ERLUG 47
  48. 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. 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. 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. 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. 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. 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. 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. 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. 56. Parte 2 Pratiche 02/04/07 56
  57. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 82. Pratiche Agili DOMANDE? 02/04/07 Agile @ ERLUG 82

×