✦ Limitazioni dei metodi tradizionali ✦ I metodi agili: caratteristiche comuni ✦ Introduzione a Extreme Programming (XP)

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