Agile requirements - alla ricerca del filo rosso (iad 2013)Fabio Armani
requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.
Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...Roberto Bettazzoni
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
Agile requirements - alla ricerca del filo rosso (iad 2013)Fabio Armani
requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.
Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...Roberto Bettazzoni
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
Come abbiamo introdotto la metodologia agile, attraverso SCRUM, in una piccola agenzia web multi progetto seguendo un approccio lean per gestire sia i team che i progetti.
Cosi come non si può prescindere dal buon design quando si progetta un software, allo stesso tempo va fatta estrema attenzione al consumo di risorse, alle performances, all’affidabilità, criteri che nell’ubiquità del software non possono mai essere dati per scontato. Vediamo come approcciare questi problemi.
Perchè l’approccio accademico al software impone spesso di ragionare “a risorse infinite”, mentre nella realtà dei fatti questo non è vero? Abbiamo la possibilità di intercettare rapidamente il degrado del software e il consumo di risorse? In questo talk vorremmo condividere alcune esperienze di team atte a misurare la “febbre” del software, ovvero discutere di alcuni indicatori che possono dare un buon feeling sullo stato di salute del software che stiamo sviluppando, monitorando i quali possiamo far avvicinare l’approccio accademico, teorico a quello pratico e di produzione.
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
Come funziona Scrum? Quali sono i suoi mattoni base? Questa presentazione è il primo tassello della collana divulgativa di Agile Reloaded su Agile e Lean Software Development. Lasciate i vostri commenti, li utilizzeremo per il cartone animato!
Better Software 2010 - Applicazione pratica di un processo di sviluppo Agile ...Paolo Quaglia
Nel panorama delle Metodologie Agili esistono molteplici processi di sviluppo (es XP e SCRUM) che ereditano ed interpretano in maniera leggermente diversa i principi espressi dal Manifesto Agile.
Il talk approfondirà la tematica dell’implementazione reale e pratica di un processo di sviluppo Agile derivato dalle metodologie citate, ma customizzato per adattarlo alle esigenze aziendali e alla tipologia dei nostri progetti.
Verranno approfonditi i ruoli e le responsabilità individuati dal processo, le competenze soft necessarie, le fasi, i singoli passi e gli output, cioè gli artefatti prodotti, siano essi documenti, codice, test automatici, etc.
Verranno trattati anche la documentazione, che ha la caratteristica di essere il più snella possibile, ed i tool software che vengono utilizzati per la gestione e controllo dei progetti.
Lo scopo è quello di fornire un case study di implementazione reale (anche da un punto di vista contrattuale) approfondendo i pro ed i contro di questa metodologia, per dar possibilmente vita ad una discussione costruttiva sull’argomento.
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Agile Project Management - the Board Game workshopGiulio Roggero
Agile workshop based on the board game "Agile: the Board Game" -
http://code.google.com/p/agile-the-board-game
(Italian Version).
During this 1day workshop participants embrace the Agile values and Lean principles using the Agile board game and the A3 Airplane game.
The spirit of the workshop is learning by doing.
You can download and use freely these slide under CC3 License.
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...Vittorio Polizzi
Perché i progetti falliscono? Gli approcci tradizionali nei progetti di sviluppo hardware e software sono davvero efficaci in un mercato in continua evoluzione e con prodotti ad elevata obsolescenza? Le caratteristiche dell’approccio Agile possono essere applicate per ideare e creare soluzioni innovative in modo efficace ed economico?
In occasione di questo incontro affronteremo questi quesiti e le metodologie agili che possono dare una risposta.
Far scalare la Continuous Delivery per il middle managementMatteo Emili
Sessione tenuta a DevOpsHeroes 2017 su approcci per rendere Continuous Delivery praticabile in modo trasversale all'azienda, con attenzione particolare al middle management.
Come abbiamo introdotto la metodologia agile, attraverso SCRUM, in una piccola agenzia web multi progetto seguendo un approccio lean per gestire sia i team che i progetti.
Cosi come non si può prescindere dal buon design quando si progetta un software, allo stesso tempo va fatta estrema attenzione al consumo di risorse, alle performances, all’affidabilità, criteri che nell’ubiquità del software non possono mai essere dati per scontato. Vediamo come approcciare questi problemi.
Perchè l’approccio accademico al software impone spesso di ragionare “a risorse infinite”, mentre nella realtà dei fatti questo non è vero? Abbiamo la possibilità di intercettare rapidamente il degrado del software e il consumo di risorse? In questo talk vorremmo condividere alcune esperienze di team atte a misurare la “febbre” del software, ovvero discutere di alcuni indicatori che possono dare un buon feeling sullo stato di salute del software che stiamo sviluppando, monitorando i quali possiamo far avvicinare l’approccio accademico, teorico a quello pratico e di produzione.
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
Come funziona Scrum? Quali sono i suoi mattoni base? Questa presentazione è il primo tassello della collana divulgativa di Agile Reloaded su Agile e Lean Software Development. Lasciate i vostri commenti, li utilizzeremo per il cartone animato!
Better Software 2010 - Applicazione pratica di un processo di sviluppo Agile ...Paolo Quaglia
Nel panorama delle Metodologie Agili esistono molteplici processi di sviluppo (es XP e SCRUM) che ereditano ed interpretano in maniera leggermente diversa i principi espressi dal Manifesto Agile.
Il talk approfondirà la tematica dell’implementazione reale e pratica di un processo di sviluppo Agile derivato dalle metodologie citate, ma customizzato per adattarlo alle esigenze aziendali e alla tipologia dei nostri progetti.
Verranno approfonditi i ruoli e le responsabilità individuati dal processo, le competenze soft necessarie, le fasi, i singoli passi e gli output, cioè gli artefatti prodotti, siano essi documenti, codice, test automatici, etc.
Verranno trattati anche la documentazione, che ha la caratteristica di essere il più snella possibile, ed i tool software che vengono utilizzati per la gestione e controllo dei progetti.
Lo scopo è quello di fornire un case study di implementazione reale (anche da un punto di vista contrattuale) approfondendo i pro ed i contro di questa metodologia, per dar possibilmente vita ad una discussione costruttiva sull’argomento.
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Agile Project Management - the Board Game workshopGiulio Roggero
Agile workshop based on the board game "Agile: the Board Game" -
http://code.google.com/p/agile-the-board-game
(Italian Version).
During this 1day workshop participants embrace the Agile values and Lean principles using the Agile board game and the A3 Airplane game.
The spirit of the workshop is learning by doing.
You can download and use freely these slide under CC3 License.
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...Vittorio Polizzi
Perché i progetti falliscono? Gli approcci tradizionali nei progetti di sviluppo hardware e software sono davvero efficaci in un mercato in continua evoluzione e con prodotti ad elevata obsolescenza? Le caratteristiche dell’approccio Agile possono essere applicate per ideare e creare soluzioni innovative in modo efficace ed economico?
In occasione di questo incontro affronteremo questi quesiti e le metodologie agili che possono dare una risposta.
Far scalare la Continuous Delivery per il middle managementMatteo Emili
Sessione tenuta a DevOpsHeroes 2017 su approcci per rendere Continuous Delivery praticabile in modo trasversale all'azienda, con attenzione particolare al middle management.
Slide aggiornate del workshop di una giornata con il gioco da tavolo Agile the Board Game che spiega in pratica, usando i lego, come funziona Scrum.
Non manca durante la giornata anche l'esercitazione su A3 Reporting, il metodo Lean per apportare continui cambiamenti ai processi eliminando le cause di spreco.
Potete usare le slide per divulgare Agile e Lean, anche a livello commerciale. Ricordatevi solo di rispettare i termini della licenza Creative Common :-)
Commenti e miglioramenti sempre ben accetti!
Agile Project Management: Insieme di attività che rendono la gestione di un processo più flessibile. Nel complesso la sua caratteristica principale è che consente al project manager e ai membri del team di capire le priorità e seguire l’avanzamento delle differenti fasi.
Noi conosciamo Kanban e Scrum come metodologie di gestione Agile. Lo Scrumban unisce le migliori caratteristiche di entrambi i metodi, combinando la natura prescrittiva dello Scrum e la capacità di miglioramento dei processi del Kanban, consentendo ai team di avvicinarsi allo sviluppo Agile e di migliorare costantemente i loro processi
Project Management - Breve IntroduzioneRighetconsult
Una breve introduzione al Project Management: problemi, cause dei problemi, criteri per la valutazione di un progetto veramente riuscito, organizzazione, ecc.
Principi di Project Management nella Pubblica AmministrazioneEmilioGianatti
Questa presentazione descrive i principi del Project Management nella Pubbliche Amministrazioni, evidenziando analogie ed aspetti peculiari rispetto alla gestione nel settore privato.
L'Autore, Emilio Gianatti, ha una esperienza pluriennale nella gestione aziendale ed è stato Professiore a Contratto presso il Corso di Laurea in Ingegneria Gestionale dell'Università di Parma.
✦ Progettazione in XP
✦ Principi di progettazione: Semplicità
✦ Test Driven Development
✦ Self Documenting Code
✦ Once and Only Once
✦ You Ain’t Gonna Need It
✦ Automazione dei test in Java: JUnit
✦ Introduzione
✦ Connessioni TCP lato client: la classe
Socket
✦ Connessioni TCP lato server: la classe
ServerSocket
✦ Struttura di un server multi-threaded
1. Lezione 15: I metodi agili
Corso di Ingegneria del Software
Laurea Magistrale in Ing. Informatica
Università degli Studi di Salerno
1
2. Outline
✦ Limitazioni dei metodi tradizionali
✦ I metodi agili: caratteristiche comuni
✦ Introduzione a Extreme Programming
(XP)
2
3. Limitazioni dei metodi tradizionali
✦ L’approccio tradizionale all’ingegneria del
software, per contrastare i problemi del
“Cowboy Programming”, porta allo
sviluppo di metodologie che sono:
• predittive, nel senso che richiedono un grosso
lavoro di previsione e pianificazione prima di
cominciare la produzione di codice funzionante
• “pesanti”, in termini della quantità e del livello di
dettaglio della documentazione da produrre e da
validare
3
4. Limitazioni dei metodi tradizionali
✦ Carattere predittivo
• evidente nel modello a cascata
• anche i modelli iterativi/incrementali tradizionali
prevedono iterazioni lunghe (2-6 mesi), per cui
all’interno di una iterazione occorre fare un grosso
lavoro di pianificazione
• spesso modelli flessibili (come RUP) sono
interpretati in modo da diventare a cascata, o
iterativi ma su iterazioni di lungo periodo
4
5. Limitazioni dei metodi tradizionali
✦ Problemi degli approcci predittivi
• in molti domini applicativi le previsioni a medio-
lungo termine hanno un elevato rischio di risultare
errate
• produrre previsioni accurate con largo anticipo
richiede uno sforzo che ha un costo non
trascurabile rispetto al costo complessivo del
progetto
• riduzione dei gradi di libertà a disposizione del
team di sviluppo durante lo svolgimento del
lavoro
5
6. Limitazioni dei metodi tradizionali
✦ Documentazione “pesante” (heavy-
weight)
• generalmente i metodi tradizionali prescrivono la
produzione di un gran numero di artefatti che
documentano le diverse fasi del processo
• spesso questi artefatti richiedono un elevato
livello di dettaglio, e utilizzano formalismi (anche
grafici) non banali
6
7. Limitazioni dei metodi tradizionali
✦ Problemi dei documenti “pesanti”
• difficoltà di mantenere la sincronizzazione tra il
programma e i documenti (e tra i diversi
documenti)
• il livello di dettaglio richiesto spesso nasconde gli
aspetti essenziali
• spesso la comprensione dei documenti è più
difficile della comprensione del codice (e quindi i
documenti non hanno nessuna utilità)
• si ritarda il momento in cui è possibile mostrare
un prodotto funzionante all’utente
• la produzione dei documenti incide
significativamente sul costo complessivo del
7 progetto
8. Limitazioni dei metodi tradizionali
✦ Altre limitazioni
• spesso i metodi tradizionali, prescrivendo con un
elevato livello di dettaglio le operazioni da
svolgere, non consentono di sfruttare le abilità
specifiche presenti nel team
• spesso la ripetibilità del processo viene garantita
a scapito della qualità del prodotto finale
8
9. I metodi “agili”
✦ a partire dagli anni ’80, sulla base delle
innovazioni metodologiche introdotte in altri
settori (es. il sistema di produzione Toyota),
diversi autori hanno proposto processi
software che fossero adattativi e leggeri
invece che predittivi e pesanti
✦ nel 2001, in un incontro tra 17 proponenti di
questo tipo di metodi, venne coniato il termine
Agile Software Development per indicare gli
elementi comuni, e redatto un documento,
noto come “The Agile Manifesto”, che
riassumeva i principi di base
9
10. I metodi “agili”
✦ Inizialmente accolti come “eretici” dalla
comunità Software Engineering
✦ Una serie di successi ha attirato una
notevole attenzione su questa famiglia di
metodologie
✦ Oggi molti metodi cercano di appropriarsi
dell’etichetta “agile” per beneficiare
dell’immagine positiva conquistata dai
metodi agili (es. lo stesso RUP)
10
11. I valori fondamentali
✦ Individui e interazioni
• più importanti di processi e strumenti
✦ Software funzionante
• più importante di una documentazione
onnicomprensiva
✦ Collaborazione con il cliente
• più importante della negoziazione contrattuale
✦ Rispondere al cambiamento
• più importante di seguire un piano dettagliato
11
12. I principi fondamentali
✦ Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
• attenzione alla qualità del software, intesa come
capacità di soddisfare i bisogni del cliente
• il cliente è parte integrante del processo di
sviluppo
12
13. I principi fondamentali
✦ Welcome changing requirements, even
late in development. Agile processes
harness change for the customer's
competitive advantage.
• il software deve essere facile da cambiare, e non
deve cercare di prevedere tutti i cambiamenti
dall’inizio
13
14. I principi fondamentali
✦ Deliver working software frequently, from
a couple of weeks to a couple of months,
with a preference to the shorter
timescale.
• il processo di sviluppo deve essere incrementale e
iterativo, con un tempo di iterazione basso
• il deliverable principale di ogni iterazione è un
programma funzionante con cui l’utente può
interagire
14
15. I principi fondamentali
✦ Business people and developers must
work together daily throughout the
project.
• non deve esserci una divisione in compartimenti
stagni tra il team di sviluppo e chi gestisce altri
aspetti del progetto come il project management
o la parte commerciale
15
16. I principi fondamentali
✦ Build projects around motivated
individuals. Give them the environment
and support they need, and trust them to
get the job done.
• il compito di un buon manager non è costringere
le persone a lavorare e sorvegliare il loro lavoro
(in stile “Grande Fratello”), ma rimuovere tutti gli
ostacoli che impediscono alle persone di lavorare
16
17. I principi fondamentali
✦ The most efficient and effective method
of conveying information to and within a
development team is face-to-face
conversation.
• occorre rimuovere le barriere (anche
“architettoniche”) alla comunicazione tra i membri
del team di sviluppo
17
18. I principi fondamentali
✦ Working software is the primary measure
of progress.
• gli artefatti documentali dei metodi “pesanti” non
devono essere considerati significativi nella
misura dell’avanzamento del progetto
• questo non vuol dire che non bisogna produrre
documentazione, ma il valore della
documentazione è misurato in base alla sua utilità
per la comprensione del software
18
19. I principi fondamentali
✦ Agile processes promote sustainable
development. The sponsors, developers,
and users should be able to maintain a
constant pace indefinitely.
• non bisogna “sovraccaricare” di lavoro il team con
politiche aziendali che incoraggiano o impongono
“marce forzate”, straordinari (non retribuiti),
atteggiamenti stakhanovistici etc.: nel lungo
termine queste politiche pregiudicano sia la
qualità del prodotto che la stessa produttività
19
20. I principi fondamentali
✦ Continuous attention to technical
excellence and good design enhances
agility.
• il team di sviluppo deve essere “orgoglioso” del
lavoro prodotto
• il software ben progettato è più facile da
modificare
• il software già realizzato può essere modificato
per migliorare il design (refactoring)
20
21. I principi fondamentali
✦ Simplicity - the art of maximizing the
amount of work not done - is essential.
• la semplicità è il criterio fondamentale nelle
decisioni di progettazione
• semplicità non significa “superficialità” o
“ignoranza”: spesso occorre notevole esperienza e
competenza per riconoscere ed eliminare ciò che
non è necessario
21
22. I principi fondamentali
✦ The best architectures, requirements, and
designs emerge from self-organizing
teams.
• il team di sviluppo deve sfruttare al meglio le
abilità e competenze specifiche di ogni persona,
invece di basarsi sull’assunzione che le persone
sono perfettamente intercambiabili
• i metodi agili preferiscono un’organizzazione
informale e flessibile del team invece di
un’organizzazione rigidamente gerarchica
22
23. I principi fondamentali
✦ At regular intervals, the team reflects on
how to become more effective, then
tunes and adjusts its behavior
accordingly.
• il processo di sviluppo è esso stesso oggetto di
aggiornamenti e miglioramenti; i miglioramenti
non vengono “calati dall’alto” a partire da
considerazioni astratte, ma nascono dalla reale
esperienza del team
23
24. Critiche ai metodi agili
✦ I metodi agili sono “indisciplinati”
• i metodi agili richiedono generalmente una
disciplina rigorosa e un processo ben definito; il
processo però è di tipo adattativo e gli artefatti
sono “leggeri”
• non bisogna confondere i metodi agili con il
“Cowboy programming”
24
25. Critiche ai metodi agili
✦ I metodi agili realizzano il software senza
progettazione
• in realtà il lavoro di progettazione è continuo e
distribuito in tutto lo svolgimento del processo
anziché essere concentrato all’inizio; anche le
parti già realizzate possono essere modificate per
migliorare l’architettura del software
• quello che manca è una documentazione
“pesante” della progettazione
25
26. Critiche ai metodi agili
✦ I metodi agili funzionano solo per team
piccoli e localizzati nello stesso posto
• ci sono in effetti rapporti contrastanti sull’efficacia
di metodi agili in team di grandi dimensioni; in
questi casi l’approccio agile suggerisce di
partizionare il problema in modo da avere più
team piccoli poco interdipendenti
• il lavoro a distanza è problematico, ma vi sono
esperienze positive in cui il problema della
comunicazione è risolto con strumenti informatici
(instant messaging, videoconferenza, forum, wiki
ecc.)
26
27. Critiche ai metodi agili
✦ I metodi agili richiedono sviluppatori
esperti
• i metodi agili si basano sull’ipotesi che
l’esperienza del team di sviluppo sia
commensurata al problema da affrontare;
comunque alcuni di essi prevedono esplicitamente
dei meccanismi per la formazione “on the job”
degli sviluppatori junior
• nessun metodo (agile o no) consente la
realizzazione di un software di qualità partendo da
un team di sviluppo privo di competenze
27
28. Critiche ai metodi agili
✦ I metodi agili richiedono un cambiamento
culturale troppo forte
• in parte è vero; il team di sviluppo deve essere
adeguatamente motivato per effettuare il
cambiamento: la scelta di adottare un metodo
agile deve essere condivisa dal team, e non può
essere imposta dall’alto
28
29. Critiche ai metodi agili
✦ I metodi agili sono difficili da gestire
contrattualmente
• è vero; nella maggior parte dei casi il cliente
richiede che al momento del contratto siano
definiti in dettaglio i costi, i tempi e le funzioni del
programma (e quindi è necessaria una
pianificazione accurata prima della stipula del
contratto); i metodi agili invece assumono che ci
sia un rapporto di fiducia reciproca tra il cliente e
l’azienda che sviluppa il software
29
30. Applicabilità
✦ I metodi agili sono applicabili con
successo se:
• il team è formato da poche (<20) persone e i
membri del team sono sviluppatori esperti
• i requisiti cambiano spesso
✦ Possono invece esserci dei problemi se:
• il team è di grandi dimensioni e solo pochi tra gli
sviluppatori hanno esperienza
• l’applicazione è safety critical, e quindi è
necessario usare strumenti formali per verificare i
risultati di tutte le attività
• il contesto aziendale impone rigidità negli aspetti
30
contrattuali e organizzativi
31. Extreme Programming
✦ Uno dei metodi agili più popolari è
Extreme Programming (XP)
✦ Sviluppato a partire dal 1996 da Kent
Beck nell’ambito di un progetto per la
Chrysler
✦ Divenuto popolare all’inizio degli anni
2000, anche grazie all’adozione di alcune
pratiche di XP in numerosi progetti open
source
31
32. Extreme Programming
✦ I valori fondamentali di XP:
• Comunicazione
• Semplicità
• Feedback
• Coraggio
• Rispetto
32
33. Ruoli in XP
✦ Il cliente
• definisce i requisiti, la loro priorità e il modo di
verificarli
✦ I programmatori
• esaminano i requisiti e definiscono le attività da
svolgere per realizzarli; stimano i tempi delle
attività; producono l’implementazione e i test di
unità e di integrazione
✦ I tester
• implementano ed eseguono i test di accettazione,
e rendono i loro risultati accessibili al team
33
34. Ruoli in XP
✦ Il manager
• organizza le riunioni, e si occupa degli aspetti
politici ed commerciali; NON dice al team cosa
deve fare o come e quando deve farlo; NON
controlla il lavoro svolto dal team
✦ Il tracker
• controlla l’avanzamento del progetto, e mantiene
aggiornate le stime sulla velocità del lavoro;
inoltre raccoglie i suggerimenti o le difficoltà
incontrate dagli sviluppatori, e suggerisce azioni
correttive
34
35. Ruoli in XP
✦ Il coach
• Controlla che i membri del team applichino in
maniera corretta la metodologia; inoltre si occupa
degli aspetti motivazionali e delle relazioni
interpersonali tra i membri del team
✦ I doomsayer
• si assicurano che tutti siano consapevoli dei rischi,
e che le cattive notizie non vengano nascoste; ma
si assicurano anche che la reazione alle cattive
notizie sia proprorzionata alla loro effettiva
gravità, evitando reazioni eccessive
35
36. Ruoli in XP
✦ I ruoli descritti non sono mutuamente
esclusivi
✦ Scompare la distinzione tradizionale tra
analista, progettista e programmatore
• i programmatori svolgono anche il lavoro di
progettazione
• il lavoro di analisi è implicitamente distribuito tra
il cliente, i programmatori e i tester
36