Confronto tra metodi tradizionali e agili
Progetto tradizionale:
- Requisiti dettagliati -> specifica -> piano
- Visto come “ben compreso”
Problemi:
- Si affida ai requisiti di correzione anticipatamente
- Difficile per i clienti perché non sanno esattamente cosa vogliono
- Costretto a definire qualcosa che non capiscono
- I requisiti di base possono essere modificati solo attraverso il controllo formale delle modifiche
- Alla consegna del progetto, il prodotto finale non è quello che il cliente avrebbe scelto perché la comprensione e le circostanze potrebbero essere cambiate.
- Soddisfare bisogni reali significa utilizzare il controllo delle modifiche
- Il controllo delle modifiche è essenziale, le modifiche possono essere costose.
- L’analisi dell’impatto illustra l’effetto del cambiamento su tempo, budget, qualità, rischi, benefici.
- Più avanti nel ciclo di vita del progetto viene generato un cambiamento, più tende a costare in quanto possono essere necessarie ulteriori lavorazioni
- Controllo di qualità, i test di ispezione arrivano verso la fine del progetto.
- Se il progetto è in ritardo, scegliere tra svolgere TUTTE le attività di controllo qualità pianificate o consegnare in tempo.
- Generalmente la consegna puntuale riduce il controllo di qualità, portando alla consegna di risultati che non sono come dovrebbero
- La correzione dei difetti può essere costosa e, come le richieste di modifica, più tardi nel progetto vengono identificate, più tendono a costare.
- A volte i costi di correzione offrono un valore inferiore e vengono quindi lasciati al loro posto
- In generale, non tutti i requisiti sono uguali.
- Alcuni sono essenziali, altri desiderabili, altri sono solo cosmetici.
- Alcuni offrono un ritorno significativo, altri molto inferiore.
- Poiché tutti i requisiti devono essere consegnati, insieme, i requisiti di valore elevato / elevato vengono mantenuti in attesa di requisiti cosmetici di scarso valore. Il ROI può essere ritardato.
- Il progetto può superare il tempo e il budget
- Risolvere requisiti / funzionalità consentendo a tempo, budget e qualità di variare anche quando non sono previsti
Progetto agile:
- Meno sequenziale
- Concentrati su ciò che l’impresa considera importante
- Garanzia per soddisfare gli standard di qualità
- Consegna puntuale
- Rispettare il budget
I requisiti vengono acquisiti ad alto livello all’inizio, i dettagli possono evolversi:
- Collaborazione e comunicazione vengono utilizzate per comprendere i dettagli di livello inferiore man mano che il progetto si svolge
- Trasforma il cambiamento e l’innovazione in progettazione e sviluppo e ha l’effetto di ridurre i costi del cambiamento
- Il controllo delle modifiche viene ancora mantenuto per regolare l’ampiezza dell’ambito, il che significa che i clienti possono aggiungere dettagli ai requisiti, ma se desiderano aggiungere nuovi requisiti, viene richiamato il controllo delle modifiche
La qualità è integrata poiché il controllo di qualità ha luogo durante tutta la durata del progetto. Il controllo avviene un po ‘alla volta, specialmente dopo l’integrazione dei componenti man mano che vengono prodotti. Se possibile, i test sono automatizzati, in modo da poter effettuare un nuovo controllo o test di regressione in modo semplice e facile.
I progetti agili non forniranno necessariamente la portata completa!
Un compromesso che consente ad Agile di fissare tempi, budget e qualità del progetto flettendo l’ambito. I requisiti di significato devono essere prioritari -> MoSCoW, come deciso dall’azienda / cliente / utente, non dai membri del team di progetto tecnico o da coloro che hanno una comprensione delle esigenze aziendali.
I progetti agili comprendono persone orientate al business e specialisti. Non solo sponsor aziendale, ma quelli con un ruolo all’interno dell’azienda in modo che le decisioni possano essere prese dal punto di vista aziendale portando alla comprensione delle esigenze, integrate nel risultato del progetto.
