introduzione alle metodologie e pratiche agili ... ma l'agile c'entra qualcosa con...

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 [email protected]

Roberto [email protected]

http://creativecommons.org/licenses/by-sa/3.0/

mailto:[email protected]

mailto:[email protected]

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.


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.


Metodologie AgiliMetodologie Agili

Rispondere al cambiamento

più che seguire un piano prestabilito



Rispondere al cambiamento

più che seguire un piano prestabilito

Cambia il metodo di approccio al problema.



Le metodologie 'storiche' hanno un approccio

PREDITTIVO(elaborare un piano e seguirlo)

Le metodologie agili hanno un approccio ADATTATIVO

(rispondere al cambiamento)


Approccio PredittivoApproccio Predittivo

● Specifiche fissate● Condizioni al contorno

note● Metodo

● Progetto la soluzione● La applico


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.


La differenza c'èLa differenza c'è

Cosa comporta questa diversa filosofia?


Cosa comporta questa differenza?Cosa comporta questa differenza?

Pratiche e strumenti ad

hoc


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


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


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


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


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


● 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


02/04/07 29


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


● 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


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


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


Dare all'utente ciò che vuole il prima possibile

● Lavorare in base alle esigenze dell'utente

● Rilasciare il prima possibile

02/04/07 39


La stabilità dei requisiti è vitale,

ma nel mondo reale è rara

... cambiamo il mondo reale

o ci adattiamo?


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.


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

● ...........


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)

● ...



Domande?


Riassunto Metodologie PredittiveRiassunto Metodologie Predittive


Riassunto Metodologie adattativeRiassunto Metodologie adattative


Riassunto metodologie adattativeRiassunto metodologie adattative


Extreme ProgrammingExtreme Programming

Extreme Programming Explained [2nded] – Kent Beck

Valori

Principi

Pratiche

(approfondimento a dopo)


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



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



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



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



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


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


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


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


Alcune pratiche AgiliAlcune pratiche Agili

● Implementazione● Test Driven Development● Refactoring● Pair Programming● ...

● Organizzazione● Stand-Up Meeting / Daily Scrum● Shared Code / Collective Code Ownership● ...


Alcune pratiche AgiliAlcune pratiche Agili

● Gestione e pianiifcazione● Continuous Integration● Release frequenti● Customer On Site / Coinvolgimento Reale● User Stories e Planning game● ...


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


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


Pair ProgrammingPair Programming

Due persone, un unico task, una sola tastiera● Il «pilota» scrive il codice● Il «navigatore» verifica e pensa al prossimo

passo



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 :)



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à



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


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?



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



● 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?)


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


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?



Qualcuno aveva già sentito puzza di bruciato:

«Plan to throw one away; you will, anyhow.»

The Mythical Man-Month - Fred Brooks



Processo di modifica evolutiva di un sistema software in modo da non

modificarne il comportamento esterno migliorandone la sua struttura



● 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»



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!


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



In TDD i test guidano lo sviluppo!

Scrivi i test per una nuova funzionalità

Implementa Rifattorizzail codice

Commit



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



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



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



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! :)



Strumenti:● *Unit: JUnit, PyUnit, NUnit, CPPUnit, PHPUnit, ...

● DBUnit, SQLUnit, PL/SQL Unit, ...

● EasyMock, Moquer, MockEJB, ...

● Selenium, HttpUnit, Jmeter, ...

● Fit, Fitnesse, ...

...forse pure troppi


Tante pratiche... ma da dove comincio?Tante pratiche... ma da dove comincio?

Dipende dal contesto

comincia dai problemi più urgenti

...un passo alla volta...


Pratiche AgiliPratiche Agili

DOMANDE?

introduzione alle metodologie e pratiche agili ... ma l'agile c'entra qualcosa con...

Technology