Metodologia agile: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
→Obiettivi Principi:
Revisione dei Principi: i metodi Agili non devono essere intesi come incentivo alla pratica del Gold-Plating
Revisione degli Obiettivi: la versione precedente focalizzava l'attenzione sui costi, tralasciando tempi e qualità Etichette: Modifica visuale gettingstarted edit |
|||
Riga 41:
In sintesi, l'Agile Manifesto, sottolinea l'importanza dei su citati principi fermo restando il valore di processi, strumenti, documentazione, contratti e pianificazione.
=== Pratiche ===
Le singole pratiche applicabili all'interno di una metodologia leggera sono decine e dipendono essenzialmente dalle necessità dell'azienda e dall'approccio del [[project manager]]. Nella scelta però bisogna tenere conto delle caratteristiche di ogni pratica per i benefici che apporta e le conseguenze che comporta. Ad esempio, in [[Extreme Programming]], si supplisce alla mancanza assoluta di qualsiasi forma di progettazione e documentazione con lo strettissimo coinvolgimento del cliente nello sviluppo e con la progettazione in coppia.
Le pratiche più diffuse tra cui scegliere sono simili fra di loro e possono essere raggruppate in categorie:
* '''Automazione''' - Se l'obiettivo delle metodologie leggere è concentrarsi sulla programmazione senza dedicarsi alle attività collaterali, allora queste ultime possono essere eliminate o automatizzate; la seconda soluzione è migliore perché si può, ad esempio, eliminare la documentazione aumentando il testing, ma non si possono eliminare entrambe; quindi si sceglie che strada si vuole percorrere e si fa in modo da utilizzare strumenti per automatizzare il maggior numero di attività collaterali;
* '''Comunicazione stretta''' - Secondo Alistar Cockburn, probabilmente il primo teorico delle metodologie leggere, questo è l'unico vero aspetto nodale che renda ''leggera'' una metodologia. Per comunicazione diretta si intende la comunicazione interpersonale, fra tutti gli attori del progetto, cliente compreso. Ciò serve ad avere una buona analisi dei requisiti ed una proficua collaborazione fra programmatori anche in un ambito di quasi totale assenza di documentazione;
* '''Coinvolgimento del cliente''' - Il coinvolgimento del cliente è qui indicato singolarmente perché ci sono differenti gradi di coinvolgimento possibili; ad esempio in [[Extreme Programming]] il coinvolgimento è totale, il cliente partecipa persino alle riunioni settimanali dei programmatori; in altri casi, il cliente è coinvolto in una prima fase di progettazione e poi non più; in altri ancora il cliente partecipa indirettamente e viene usato come test della versione rilasciata;
* '''Progettazione e documentazione''' - Pensare che le metodologie leggere ''eliminino'' la progettazione e la documentazione è un errore, in effetti non è così, le metodologie leggere introducono un'iterazione nel ciclo di vita del progetto; quanta progettazione fare e quanta documentazione produrre, escludendo i casi estremi, è una scelta lasciata a chi gestisce il progetto e spesso i teorici dell'Agile Alliance avvisano che è un errore trascurare o addirittura omettere queste due fasi;
* '''Consegne frequenti''' - Effettuare rilasci frequenti di versioni intermedie del software permette di ottenere più risultati contemporaneamente: si ricomincia l'iterazione avendo già a disposizione un blocco di codice funzionante in tutti i suoi aspetti, si offre al cliente "qualcosa con cui lavorare" e lo si distrae così da eventuali ritardi nella consegna del progetto completo, si usa il cliente come se fosse un test visto che utilizzerà il software e riscontrerà eventuali anomalie, si ottengono dal cliente informazioni più precise sui requisiti che probabilmente non sarebbe riuscito ad esprimere senza avere a disposizione utilità e carenze del progetto;
|