Metodologia agile: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
FrescoBot (discussione | contributi)
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 29:
 
=== Obiettivi ===
L'obiettivo è la piena soddisfazione del cliente e non solo l'adempimento di un contratto. L'Il corretto uso di queste metodologie, inoltre, servepuò adconsentire di abbattere i costi e i tempi di sviluppo del software, aumentandone la qualità.
 
Essa è esplosa proprio in concomitanza con la crisi successiva al boom di Internet prendendo spunto dai metodi applicati in piccole [[software house]].
Riga 37:
* le persone e le interazioni sono più importanti dei processi e degli strumenti (ossia le relazioni e la comunicazione tra gli attori di un progetto software sono la miglior risorsa del progetto);
* è più importante avere software funzionante che documentazione (bisogna rilasciare nuove versioni del software ad intervalli frequenti, e bisogna mantenere il codice semplice e avanzato tecnicamente, riducendo la documentazione al minimo indispensabile);
* bisogna collaborare con i clienti aloltre diche rispettare delil contratto (la collaborazione diretta offre risultati migliori dei rapporti contrattuali);
* bisogna essere pronti a rispondere ai cambiamenti piùoltre che aderire alalla progettopianificazione (quindi il team di sviluppo dovrebbe essere autorizzatopronto, in ogni momento, a suggeriremodificare modifichele alpriorità progettodi inlavoro ogninel momentorispetto dell'obiettivo finale).
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.