Lezione 1: I metodi agili

  • 2,997 views
Uploaded on

✦ Limitazioni dei metodi tradizionali …

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

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,997
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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