Agile Manifesto: le basi da cui partire

L’agile manifesto o manifesto agile per dirla all’italiana, è una sintesi di tutte le riflessioni nate dall’analisi delle diverse metodologie di sviluppo esistenti. In questo articolo andiamo a sviscerare i 4 valori ed i 12 principi alla base di questo manifesto che tanto ha influenzato e continua ad influenzare il modo di realizzare software.

L’agile manifesto o manifesto agile per dirla all’italiana, è una sintesi di tutte le riflessioni nate dall’analisi delle diverse metodologie di sviluppo esistenti.

Durante i nostri workshop su SCRUM illustriamo le diverse metodologie classiche di sviluppo ed evoluzione di un progetto (Waterfall in primis) le quali hanno nel tempo mostrato tutti i loro limiti e, per quanto in alcuni settori applicativi possano risultare ancora valide, hanno portato a profonde riflessioni sintetizzate all’interno dell’ agile manifesto sotto forma di 4 valori e 12 principi con l’intento di aiutare i professionisti a capire come avere un significativo impatto sul futuro della gestione di un progetto informatico.

L’agile manifesto è stato formulato con molta attenzione per catturare l’essenza dell’agile in poche parole:


Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso.Grazie a questa attività siamo arrivati a considerare importanti:

  1. Gli individui e le interazioni più che i processi e gli strumenti
  2. Il software funzionante più che la documentazione esaustiva
  3. La collaborazione col cliente più che la negoziazione dei contratti
  4. Rispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.
(https://agilemanifesto.org/iso/it/manifesto.html)


Come possiamo vedere, si tratta di affermazioni piuttosto concise e semplici che rendono molto chiaro ciò che i fondatori volevano promuovere. Di solito, i metodi tradizionali sono rigidi e sottolineano procedure e tempistiche mentre l’agile manifesto mette in primo piano esattamente le cose opposte privilegiando quindi:

  • persone e prodotto
  • comunicazione e reazione

I 4 Valori dell’AGILE

Di seguito analizzeremo in dettaglio i valori alla base di AGILE.

1 – Gli individui e le interazioni più che i processi e gli strumenti

Gli individui e le interazioni sono preferiti rispetto ai processi e agli strumenti perché rendono il team più reattivo. Se gli individui sono allineati ed affiatati, il team può risolvere eventuali problemi selezionando rapidamente ed in autonomia gli strumenti o i processi più adeguati.

Ma se i team insistono per attenersi ciecamente ai processi, ciò potrebbe causare incomprensioni tra gli individui e creare blocchi inaspettati con conseguenti ritardi nel progetto o, nel peggiore dei casi, vicoli ciechi da cui è complesso ed oneroso fare retromarcia.

Ecco perché è sempre preferibile avere interazioni e comunicazioni tra i membri del team piuttosto che fidarsi ciecamente dei processi per scegliere la strada da percorrere ed uno dei modi più efficienti per raggiungere questo obiettivo è avere l’ideatore / owner del prodotto fortemente coinvolto così che possa facilmente prendere decisioni in collaborazione con il team di sviluppo.

Consentire ai membri del team di contribuire autonomamente e con meno vincoli alla crescita del progetto permette loro di mostrare liberamente il valore che possono mettere a disposizione. Quando queste interazioni di gruppo sono dirette alla risoluzione di un problema comune, i risultati possono essere sorprendenti.

2 – Il software funzionante più che la documentazione esaustiva

La gestione tradizionale di un progetto prevedeva una documentazione completa che definisse ogni aspetto da prendere in considerazione ed ha spesso, per non dire sempre,  comportato ritardi di mesi portando a mettere inutili pressioni e vincoli sul progetto oltre che relegando i membri del team a semplici esecutori che avendo per le mani una specifica presumibilmente omnicomprensiva non si assumono la responsabilità di scelte fatte da terzi.

Il tipo di documentazione creata in passato è stata molto dettagliata e sono stati creati così tanti documenti che molti di essi non sono stati nemmeno citati durante l’avanzamento del progetto. Questo era un male inutile con cui i team di progetto erano soliti convivere.

Ma ciò ha anche esacerbato i problemi di consegna. L’attenzione si è concentrata sulla documentazione in misura tale perché i team volevano pubblicare un prodotto finito che era al 100% compatibile con le specifiche. Tuttavia, il prodotto finale era piuttosto diverso dalle aspettative perché al netto degli sforzi risultava impossibile trasmettere appieno una visione complessiva del tutto e spesso si finiva con il realizzare qualcosa di molto diverso da ciò che era effettivamente richiesto. 

Ecco perché Agile afferma che un software funzionante è un’opzione molto migliore per valutare le aspettative dei clienti rispetto a una enorme documentazione.

Ciò non implica che la documentazione non sia necessaria. Significa solo che un prodotto funzionante è ogni giorno un indicatore migliore dell’allineamento alle esigenze e alle aspettative del cliente rispetto a un documento creato mesi prima. Implica anche che i team siano pronti ad adattarsi ai cambiamenti come e quando richiesto, mostrando al cliente il software funzionante ad ogni rilascio.

La mancata verifica del prodotto durante lo sviluppo comporta costi e sforzi molteplici nel futuro. Una volta implementata la funzionalità, il costo di queste modifiche aumenta in maniera incrementale.

3 – La collaborazione col cliente più che la negoziazione dei contratti

Negoziazione significa che i dettagli del progetto vengono definiti a priori prima di essere finalizzati ed in maniera molto simile alla documentazione vincolano a priori delle scelte che non possono effettivamente essere fatte in fase negoziale. C’è ancora spazio per la rinegoziazione certo ma, una volta conclusa la negoziazione, non ci sarà più alcuna discussione al riguardo. Ciò che dice agile è che invece di investire tempo e risorse nel negoziare sarebbe opportuno scegliere la via della collaborazione continua.

La collaborazione implica che c’è ancora spazio per la discussione e la comunicazione è costantemente in corso.

Ciò offre un duplice vantaggio: mentre aiuta il team a fare una correzione del corso se richiesto in una fase precedente, aiuta anche il cliente a perfezionare la propria visione e ridefinire i propri requisiti se richiesto nel corso del progetto.

Inoltre mentre i modelli di sviluppo software tradizionali coinvolgono il cliente esclusivamente prima che inizi lo sviluppo e durante la fase di negoziazione e documentazione, nel modello agile il cliente/ideatore è costantemente coinvolti durante lo sviluppo del progetto.

Questo aiuta i team agili ad allinearsi meglio alle esigenze reali.

4 – Rispondere al cambiamento più che seguire un piano

Il processo standard prevede che i cambiamenti siano costosi e che dovremmo evitare cambiamenti a tutti i costi. Questo è l’obiettivo non necessario della documentazione e dei piani elaborati da rispettare rispettando le tempistiche e le specifiche del prodotto.

Ma come l’esperienza ci insegna i cambiamenti sono per lo più inevitabili e invece di scappare da essi dovremmo cercare di abbracciarle e pianificarli o quantomeno mettere in conto che ci saranno ed essere pronti a gestirli.

Agile ci permette di fare questa transizione. Ciò che suggerisce agile è che il cambiamento non è una spesa, è un feedback positivo che aiuta a migliorare il progetto. Non deve essere evitato, ma cercato perché aggiunge valore al prodotto.

Con i brevi cicli di rilascio proposti da Agile, i team possono ottenere un rapido feedback e spostare le priorità in breve tempo. È possibile aggiungere nuove funzionalità ad ogni rilascio per andare in contro alle esigenze del prodotto/mercato.

Perché lo facciamo? Perché la maggior parte delle funzionalità sviluppate con l’approccio a cascata non vengono mai utilizzate.

Anche Agile pianifica, ma sposando un ‘approccio just in time in cui la pianificazione viene effettuata quanto basta quando necessario. E i piani sono sempre aperti a cambiare con l’evolversi costante del prodotto.

I 12 Principi AGILE

Ci sono 12 principi agili che sono stati aggiunti dopo la creazione del manifesto per aiutare e guidare la transizione dei team in agili e verificare se le pratiche che stanno seguendo sono in linea con la cultura agile.

Questi principi forniscono una guida pratica per i team di sviluppo e sono finalizzati a:

  • Soddisfazione del cliente
  • Qualità del prodotto
  • Lavoro di squadra
  • Gestione di progetto

1 – La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua

I clienti saranno ovviamente entusiasti di vedere un software funzionante distribuito ad ogni rilascio piuttosto che dover attraversare un ambiguo e spesso indefinito periodo di attesa alla fine di cui vedere il prodotto.

2 – Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente

Le modifiche possono essere incorporate senza molti ritardi nelle tempistiche generali poiché i team agili credono nella qualità sopra ogni cosa e preferirebbero incorporare le modifiche piuttosto che evitare le modifiche e consegnare un prodotto che non soddisfa le esigenze reali.

3 – Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi

Poiché i rilasci sono iterazioni temporizzate e forniscono un software funzionante alla fine di ogni rilascio, i clienti hanno regolarmente un’idea dei progressi.

4 – Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto

Le migliori decisioni vengono prese quando entrambi lavorano insieme in collaborazione e c’è un circuito di feedback costante tra i due per la correzione del corso e l’agilità del cambiamento. La comunicazione tra le parti interessate è sempre la chiave per l’agile.

5 – Fondiamo i progetti su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine

E’ indispensabile supportare, fidarsi e motivare i team. È più probabile che un team motivato abbia successo e fornisca un prodotto superiore rispetto ai team infelici che non sono disposti a dare il meglio. Autorizzare il team di sviluppo ad auto-organizzarsi e prendere le proprie decisioni è uno dei modi migliori per raggiungere questo obiettivo.

6 – Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team

La comunicazione è migliore e più efficace se i team possono comunicare agevolmente e possono incontrarsi faccia a faccia per le discussioni. Aiuta a costruire la fiducia e porta la comprensione tra le varie parti interessate.

7 – Il software funzionante è il principale metro di misura di progresso

Un software utilizzabile, anche se imperfetto, batte tutti gli altri KPI ed è il miglior indicatore del lavoro svolto.

8 – I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante

La coerenza della consegna è enfatizzata. Il team dovrebbe essere in grado di mantenere il proprio ritmo per tutta la durata del progetto e non esaurirsi dopo i primi rilasci.

9 – La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità

Il team dovrebbe avere tutte le competenze e un buon design del prodotto per gestire i cambiamenti e produrre un prodotto di alta qualità pur essendo in grado di incorporare i cambiamenti.

10 – La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale

Spesso la cosa più utile da fare è non realizzare una funzionalità se non è davvero indispensabile per massimizzare la qualità del lavoro svolto.

11 – Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.

Ciò porta a una comunicazione aperta e alla condivisione regolare delle idee tra i membri del team che nella maggior parte dei casi è un valore inestimabile per il progetto.

12 – A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza

L’auto-miglioramento porta a risultati più rapidi e minori rielaborazioni del prodotto, prendersi il tempo per discutere ed approfondire successi e fallimenti conseguenti ad un rilascio permette al team di costruirsi un bagaglio di esperienze inestimabili e trasversali ad aspetti tecnici e commerciali del prodotto.

Conclusioni

La centralità del cliente e l’attenzione alla comunicazione hanno portato il successo all’agile che è oggi evidente a tutti.

Agile non è una tecnica ma un mindset, un insieme di best practice collaudate con implicazioni non solo sulla consegna del software ma anche in altri settori ed oggi è diventato fondamentale non solo per l’industria del software venendo declinato anche in numerosi altri ambiti (hardware, digital marketing, …).

Sei incuriosito da mondo agile? Leggi gli altri articoli sulle metodologie agili e SCRUM

Add a Comment

You must be logged in to post a comment