Agile: Iterativo, Incrementale, Evolutivo

Evolution

Il mondo AGILE offre una varietà di stili di gestione  dei requisiti per lo sviluppo software. Molti dicono di aver adottato un approccio AGILE, semplicemente perché organizzano qualche riunione in più, credono di collaborare tra utente e sviluppatori, praticano la revisione del codice o il “pair programming“, chiamano i requisiti “stories, utilizzano i post-it per indicare la fase di avanzamento dello sviluppo di una funzione. In realtà, ogni ambiente ha le sue peculiarità croniche, per cui la prima operazione da fare è intendersi sul significato delle parole e iterativo, incrementale e evolutivo possono dar adito a differenti interpretazione in funzione della cultura in ogni contesto.

Vediamo quali sono  le differenze salienti tra lo stile iterativo, incrementale e evolutivo.

Stile Iterativo

Agile-iterativo

Il team di sviluppo segue una prassi molto efficace basata su: riunioni, pianificazione, iterazioni brevi, flusso kanban, prove, revisione del codice, ristrutturazione del codice, integrazione continua e così via.  Spesso queste operazioni si riducono a delle semplici formalità che possono sfociare nella banale burocrazia, se non c’è la convinzione di cambiare modo di operare.

In pratica, con questo approccio, i requisiti arrivano in massa con un documento. Nulla è cambiato. Il documento può addirittura provenire da un consulente esterno non più disponibile. Qualcuno assume l’incarico di produrre e rilasciare quanto previsto nel documento in un determinato tempo e budget. L’impegno è riuscire a rispettare tempo e budget.

Per riuscirci, il Product Owner affetta i requisiti in parti maneggevoli per il team di sviluppo in modo che possano coprire il lavoro di ogni iterazione.

Il  team di sviluppo si isola dal resto dell’organizzazione e inizia a sviluppare. Interferenze e richieste di modifica dei requisiti del prodotto da realizzare costituiscono dei disturbi indesiderati, specialmente sui progetti molto brevi.

Questo è l’approccio di grandi aziende che dicono di utilizzare AGILE con budget annuale.

Stile Incrementale

Agile-incrementale

E’ simile allo stile iterativo. I requisiti sono stati raccolti in un documento ed il team di sviluppo si impegna a realizzare il prodotto nei tempi e nel budget concordati.

La differenza sostanziale è che il team di sviluppo realizza e consegna immediatamente all’utente in modo da dimostrare cosa è stato realizzato e ottenere il feedback dell’utente. Se l’utente accetta il software prodotto potenzialmente può iniziare anche d utilizzarlo, anche se parzialmente.

Il vantaggio è che l’utente fornisce il suo feedback su ciò che vede e ciò che vorrebbe. L’utente può scoprire di aver bisogno di qualche altra funzionalità o di non aver bisogno di altre, preventivamente richieste.

Il progetto viene realizzato in modo tradizionale, cioè tutto ciò che fa parte del documento dei requisiti deve essere realizzato, a meno che l’utente attraverso il “Product Owner” non decida diversamente. E questo è come rivedere i requisiti iniziali. Il dialogo con l’utente rende molto più flessibile il contenuto del documento dei requisiti.

In pratica si tratta di sviluppo incrementale in quanto l’utente vede il prodotto crescere incremento dopo incremento, traendone immediatamente vantaggi se riesce ad utilizzare il prodotto parzialmente ricevuto.

Questo approccio è molto problematico, perché bisogna tracciare con rigore le richieste di modifiche e formalizzare i vari rilasci incrementali con relative prove di collaudo e passaggio in produzione.

Stile evolutivo

Agile-evolutivo

Questo è il vero approccio AGILE. Il team di sviluppo segue lo stesso un approccio iterativo, ma non dispone di alcun documento dei requisiti. Il lavoro consiste nello sviluppare un’idea, raccogliendo strada facendo i requisiti di dettaglio. Il team dispone solo di indicazioni di alto livello e a volte non ci sono neanche quelle. Questo approccio significa “Evolvere”.

Con questo approccio utenti e sviluppatori viaggiano insieme fon dall’inizio del progetto. Si confrontano e decidono cosa mettere in lavorazione. Il team di sviluppo autonomamente decide come organizzare ogni iterazione sulla base del backlog di decisioni disponibili. Nel frattempo, il referente degli utenti (Product Owner) parla con gli utenti per catturare nuove informazioni o idee  e potersi nuovamente confrontare con il team di sviluppo. Questo è l’approccio con stile  “Evolutivo”. In pratica, il Product Owner tende a caricare il backlog di nuove idee, e il team di sviluppo a scaricarlo, eseguendole in iterazioni successive.

Ad un certo punto, il team di sviluppo è in grado di rilasciare del software e iniziare a fornire valore. Questo approccio è molto più comune di quello che si pensa ed è anche la massima espressione della filosofia AGILE, dove deve prevalere la competenza del team di sviluppo, la collaborazione con il referente dell’utente, l’ascolto delle richieste di modifiche e l’attenzione al business.

Cosa Dice il PMBOK Guide

Il moderno project management è aperto a queste definizioni con qualche sfumatura leggermente differente. Il PMBOK definisce tre tipi di cicli di vita:

Ciclo di Vita Predittivo

Con il ciclo di vita predittivo  si determina il prima possibile l’ambito del progetto, i tempi ed i costi per realizzarlo. Il progetto passa attraverso una serie di fasi sequenziali o sovrapposte. Ogni fase si dedica ad una specifica tipologia di lavoro (requisiti, fattibilità, pianificazione, progettazione, sviluppo, collaudo, rilascio). Ogni eventuale modifica all’ambito richiede una formale accettazione e una ripianificazione. Questo approccio è più efficace quando si conoscono tutti i dettagli del prodotto da realizzare.

Cicli di Vita Incrementali e Iterativi

Sono i cicli di vita che intenzionalmente ripetono una o più attività del progetto all’aumentare della comprensione del progetto.  Le iterazioni sviluppano il prodotto, gli incrementi ne aumentano progressivamente la funzionalità. I progetti possono procedere per fasi sequenziali o sovrapposte. Alla fine di ogni iterazione viene completata una deliverable. Le iterazioni successive o migliorano quella stessa deliverable o ne creano di nuove. Ogni iterazione migliora in modo incrementale le deliverable fino all’uscita dalla singola fase o dal progetto stesso.

Questo tipo di ciclo di vita è tipico dei progetti con obiettivi e ambito mutevoli. Ad esempio, un grande progetto può essere eseguito in modo iterativo per ridurre i rischi, sfruttando il feedback dell’utente tra una iterazione e l’altra.

Adattivo (o Evolutivo)

I cicli di vita adattivi o “agile” rispondono meglio agli alti livelli di richieste di modifiche e al continuo coinvolgimento degli  stakeholder. Questo approccio è anche iterativo e incrementale con iterazioni molto rapide con tempi e costi fissi.

L’ambito del progetto consiste in requisiti e lavoro individuato per realizzare il prodotto considerato  backlog di progetto. Il team di progetto decide quanto e quale lavoro inserire in ogni iterazione successiva fino alla creazione del prodotto da mostrare al cliente. Lo sponsor e i rappresentanti del cliente devono continuamente fornire feedback sulle deliverable ricevute per confermare che il backlog rappresenti sempre le loro esigenze.

Questo metodo è efficace in presenza di un ambiente in continua evoluzione e requisiti ed ambito sono difficili da definire anticipatamente, mentre con piccoli incrementi si fornisce valore agli stakeholder.

Promo

Se vuoi veramente comprendere  in cosa consiste l’approccio Agile, puoi accedere al corso

PMI ACP-Prep Online

un corso autodidatta completo per preparare l’esame di certificazione PMI-ACP