Cos'è la metodologia Agile: esempi e vantaggi

Che cosa si intende per metodologia Agile?

Una metodologia Agile, a grandi linee, è un insieme di pratiche e regole codificate, che hanno lo scopo di facilitare la migrazione dei processi produttivi da una logica waterfall ad un approccio più iterativo e incrementale.

Nell’approccio waterfall, tutta la progettazione viene fatta in una fase iniziale. La realizzazione ha come focus principale l’aderenza stringente a quanto progettato e il risultato viene verificato alla fine, tramite collaudi che a loro volta hanno lo scopo di verificare l’aderenza del progetto alle specifiche.

Gli autori del manifesto Agile, reduci da svariati progetti infruttuosi, notarono che la principale causa di problemi era la totale mancanza di evoluzione in questa equazione.

Se in un progetto di lunga durata, non si rimuove il vincolo della stringente aderenza alle specifiche iniziali, si accumula tutto il rischio alla fine. Eventi imprevisti, aree non coperte dall’analisi, requisiti incompleti o involontariamente errati, mutamenti del mercato o della strategia aziendale, il feedback degli utenti… tutto viene ignorato finché il progetto non viene portato in produzione, ovvero quando tempo e budget sono terminati (e quasi sempre anche superati).

Nello sviluppo Agile del software, lo scopo principale è adottare pratiche e prassi tali da aiutare i team di prodotto a focalizzarsi su ciò che realmente porta valore, migliorando costantemente i propri processi e la qualità del risultato. 

I metodi Agili si focalizzano sulle modalità di collaborazione tra le persone (tutti coloro che sono coinvolti nel processo produttivo, a volte persino gli utenti finali), affinché l’organizzazione sia in grado di rilasciare frequentemente quelle caratteristiche del software che sono davvero rilevanti, adattando le sua strategia alle evidenze e a ciò che apprende dal mercato.

Il Manifesto Agile

Dunque quando parliamo di metodologia Agile ci riferiamo in realtà ad un approccio. Un modo di lavorare che prediliga la collaborazione, l’adattamento e l’aderenza del prodotto ai mutevoli obiettivi di business, al rispetto di piani prestabiliti e non più discutibili.

Così come il modello Cloud Native, il movimento Agile prese le mosse dalla stesura di un manifesto che sintetizza in dodici punti fondamentali i principi che guidano l’adozione e la personalizzazione del framework. Di seguito un estratto:

• La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua [...]

• Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo [...]

• Committenti e sviluppatori devono lavorare insieme [...]

• Fondiamo i progetti su individui motivati [...]

• Il software funzionante è il principale metro di misura [...]

• La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità [...]

Prima di approfondire ulteriormente, facciamo un passo indietro per capire cosa ha dato origine a questo manifesto di valori.

Quali sono gli obiettivi della metodologia agile?

Il Manifesto Agile, contrariamente a quanto si possa credere, non è un prodotto seminale. Si tratta di una sintesi dei principi che hanno spinto, fin dall’inizio degli anni ‘90, alcuni sviluppatori a elaborare metodologie che permettessero di non veder fallire la maggioranza dei progetti software in capo alle proprie organizzazioni.

Agile non è dunque la risposta a fare di più con meno, anche se è vero che un team agile, sul medio-lungo periodo aumenta la sua efficienza grazie alle buone pratiche, ad una comunicazione efficiente e a rapporti di fiducia su tutti i livelli.

Agile è la risposta alla riduzione del rischio di un progetto, che vede in un approccio empirico, basato sull’apprendimento e il miglioramento continuo dei processi, la soluzione a un possibile lancio disastroso.

Generalmente le organizzazioni agili adottano le seguenti prassi per ottenere questo risultato:

• Rilasci frequenti: Il software viene messo in produzione molto frequentemente, senza aspettare la perfezione. Rilasci frequenti di nuove funzionalità permettono di registrarne l’effettiva adozione da parte dei clienti e raccogliere feedback utile a non costruire “cattedrali nel deserto”.
• Niente debito tecnico: L’organizzazione (non solo il team di sviluppo!) non ritiene accettabile accumulare debito tecnico, poiché renderebbe progressivamente impossibile manutenere una base di codice in rapido cambiamento, impedendo di operare rilasci frequenti. Il team ha il mandato di migliorare costantemente lo stato del codice e le proprie pratiche, senza che la corsa alle nuove funzionalità prenda il sopravvento.
• Comunicazione: La comunicazione tra team e stakeholder sui temi di business è possibile e anzi incoraggiata: un team agile non implementa solo funzionalità  (il cui comportamento end-to-end è nel migliore dei casi precisato da requisiti e scenari d'uso), ma è chiamato anche a immaginare soluzioni, soprattutto in caso di imprevisti. Chi sviluppa non è quindi solo un mero esecutore, ma deve essere orientato al risultato, saper fare proposte e generare soluzioni.

Si tratta di un approccio che può apparire più costoso del classico waterfall, ma questa impressione è spesso falsa. Quanti progetti sembrano perfettamente incasellati finchè, a ridosso della fine, non emergono problemi, ritardi e rilavorazioni?

Un approccio agile cerca di anticipare il più possibile i test e persino l’adozione di un prodotto dai veri utenti, così da conoscere e indirizzare fin da subito eventuali problematiche e mettere il tutto sui giusti binari quando farlo è ancora semplice, rapido e rilevante.

Ma è sempre necessario?

Qual è la caratteristica tipica dei progetti Agile?

In termini di gestione del rischio, non ci sono progetti che non beneficiano di un approccio empirico. Mettere frequentemente e da subito il prodotto al vaglio dei suoi stakeholder, compresi ove possibile gli utenti finali, non può che far emergere presto e in modo lampante le informazioni vitali per poter plasmare il software attorno ai veri bisogni, investendo su ciò che porta realmente valore.

L’apprendimento (non solo tecnico, anche di business) e l’adattamento, sono infatti i due aspetti più premiati da un simile approccio.

Ci sono casi in cui un approccio progressivo, a partire da zero, non è applicabile. Immaginiamo di voler creare un nuovo prodotto che vada a sostituirne uno già in produzione. È improbabile che gli utenti si possano accontentare di un sottoinsieme delle funzionalità, aspettando che nel corso del tempo tutte quelle a cui sono già abituati arrivino a compimento.

Questi casi sembrano candidati ideali per un approccio waterfall: dobbiamo portare in produzione un corpus ben consolidato di funzionalità. Sappiamo tutto quello che dobbiamo fare e come lo dobbiamo fare, giusto?

Forse.

Innanzitutto in tal caso, perché costruire un nuovo prodotto? Certo ci sono motivi puramente tecnici: dipendenze chiave in end of life, sistemi legacy non più manutenibili, termine di contratti di licenza che forzano un cambio di tecnologia… ma l’occasione rimane buona per osservare il sistema con occhio critico e rimanere agili e critici nell’approccio, per cogliere opportunità di aumentare il valore del risultato.

Ad esempio, il team può esporre agli utenti finali le funzionalità mano a mano che vengono completate, in un ambiente di test. L’organizzazione può quindi raccogliere feedback, prendere decisioni adattive e adeguare la roadmap per garantire il rispetto di tempi e budget, anticipando eventuali compromessi, ma anche decidendo di fare a meno di vecchie funzionalità mai usate (o apertamente detestate) per investire sul migliorare quelle più critiche o introdurre novità.

In questi scenari, anche le scelte di architettura compiute in passato influenzano il modo e la misura in cui l’approccio agile potrà aiutare l’evoluzione del prodotto. un’architettura a microservizi, infatti, si sposa in modo ottimale con un modo empirico ed evolutivo di concepire il cambiamento. 

Ma soprattutto, il focus sulle buone pratiche e sulla qualità dei processi produttivi, garantisce la realizzazione di un prodotto manutenibile e sotto controllo, sia prima che dopo la messa in produzione.

D’altronde, quale progetto non beneficia di investire il tempo e il budget sulle cose che portano maggior valore?

LEGGI ANCHE:

• Come introdurre la cultura DevOps in azienda
• Microservizi: cosa sono e perché usarli

Quali sono i framework Agile?

D’accordo, abbiamo parlato di mindset e di principi, ma in pratica come ci si riorganizza per lavorare in modo agile?

Come già accennato, esistono varie declinazioni metodologiche del mindset Agile; anzi, il manifesto è nato dal confronto tra diverse realtà organizzative, distillandone a ritroso i principi comuni.

Gli Agile Framework sono scheletri di pratiche già consolidate che possono facilitare l’adozione e maturazione di un mindset agile all’interno di un’organizzazione.

Perché li chiamano framework? Perché danno delle indicazioni e delle “prescrizioni”, senza imporre le modalità operative. Ad esempio Scrum impone l’uso di un product backlog ordinato, emergente e dettagliato; ma non dice se questo backlog debba essere rappresentato su una board o composto da una pila di bigliettini in una scatola di scarpe. Ogni team può implementare il suo backlog, come gli è più comodo e congeniale.

Framework diversi risultano più o meno adatti a seconda dello scenario e, sebbene sia possibile farsi un’idea di quale sia il più indicato per partire, la sperimentazione rimane una componente molto importante. Cambiare approccio organizzativo ha inevitabilmente degli effetti sul contesto ed è frequente che introducendo un framework adatto in un dato momento storico, questo finisca per mutare l’organizzazione fino al punto di “andare stretto” ed dare luogo a un’evoluzione.

L’importante è non confondere i framework (o le metodologie) con l’agilità: seguire alla lettera i dettami di un qualsiasi Agile Framework, senza maturare un sistema valoriale agile, può portare risultati ben diversi da quelli sperati e persino peggiorare la proficiency di un team.

A titolo di esempio vediamo molto sinteticamente tre esempi di framework Agile, nello specifico: Scrum, Kanban ed eXtreme Programming.

Scrum

Scrum è il più famoso tra gli Agile Framework, al punto che ormai molti utilizzano erroneamente “Agile” e “Scrum” come sinonimi.

La guida Scrum lo definisce così: “Scrum è un framework di processo utilizzato dai primi Anni Novanta per gestire lo sviluppo di prodotti complessi. Scrum non è un processo o una tecnica per costruire prodotti, ma piuttosto è un framework all’interno del quale è possibile utilizzare vari processi e tecniche. Scrum rende chiara l'efficacia del proprio product management e delle proprie pratiche di sviluppo così da poterle migliorare”.

È un framework orientato alla produzione di software funzionante fin dalla prima iterazione e richiede che l’intera organizzazione (non solo il team di sviluppo) ne abbracci i valori perché ne possa raccogliere i frutti.

Oltre ad essere il più famoso, Scrum è anche il più travisato e male implementato e questo gli è valso l’immeritato odio di molti sviluppatori delusi. Nelle parole dei suoi creatori infatti, Scrum è facile da capire, ma difficile da padroneggiare.

È un framework particolarmente adatto per la creazione di nuovi prodotti, per i quali il feedback degli utenti può fare la differenza.

Kanban

Si tratta di una metodologia ispirata ai principi dello sviluppo software Agile, alla teoria dei vincoli e ai principi del Toyota Production System. Elaborata da David J. Anderson nel 2007 dopo una lunga gestazione in Microsoft, è stata ufficializzata nel libro "Kanban" pubblicato nel 2010. Fonda il suo funzionamento su sei principi e sei pratiche: 

1. visualizzare il flusso di lavoro; 
2. limitare il work in progress; 
3. misurare e gestire il flusso di lavoro; 
4. rendere esplicite le regole del processo; 
5. istituire dei cicli di feedback; 
6. istituire dei cicli di evoluzione e miglioramento del processo.

Come Scrum, anche Kanban è spesso travisato e ridotto a una delle sue componenti fisiche: la board. La famosa lavagna bianca popolata di post-it colorati, diligentemente incolonnati a rappresentare il flusso è un ausilio molto frequente per implementare la prima delle pratiche (visualizzare il flusso di lavoro). Tuttavia Kanban va ben al di là, fornendo strumenti per individuare i colli di bottiglia, misurare l’efficacia delle evoluzioni di processo e fare forecasting accurati sulla delivery del team.

Il focus di Kanban è sul creare un flusso il più possibile fluido e continuativo di erogazione. Ha la proprietà di “partire da ciò che il team sta facendo, ed evolvere in base alle evidenze” e questo lo rende un framework leggerissimo da adottare. Tuttavia, per metterlo in pratica per la prima volta, l’aiuto di un facilitatore è spesso un elemento chiave per non perdersi nelle molte opzioni e dare il giusto abbrivio.

Kanban è un framework scalabile, che può essere adottato da un singolo team all’interno di un’organizzazione più grande ma che è particolarmente adatto per ottimizzare sistemi composti da molteplici flussi di lavoro interdipendenti. È un punto d’ingresso ottimo per le organizzazioni che vogliono maturare un mindset agile un passo alla volta, modificando le proprie abitudini in modo progressivo e senza strattoni. Per questo però, richiede molta disciplina.

Extreme Programming (XP)

L'extreme programming, è una metodologia di sviluppo del software che enfatizza la scrittura di codice di qualità e la rapidità di risposta ai cambiamenti dei requisiti. È un framework molto ferreo, che prescrive dodici pratiche che un team di sviluppo deve adottare al fine di ottenere i risultati attesi.

XP ha il grande merito di aver distillato e promosso molte delle buone pratiche di sviluppo che sono diventate elementi comuni per ogni team agile, a prescindere dal metodo con cui questo lavori. Ad esempio ha promosso: 

• continuous integration;
• peer programming; 
• sviluppo e pianificazione iterativi;
• l’utilizzo delle User Stories;
• la sistematizzazione di testing e refactoring; 
• il divieto ai programmatori di sviluppare codice non strettamente necessario;
• l'enfasi sulla chiarezza e la semplicità del codice; la preferenza per strutture gestionali non gerarchiche;
• infine, l'importanza data alla comunicazione diretta e frequente tra sviluppatori e cliente e fra gli sviluppatori stessi.

Extreme Programming, spesso criticato per essere un modello troppo incentrato sull’ingegneria del software, e per portare più valore agli sviluppatori che al business, è un modello di sviluppo che, in cambio di una ferrea disciplina e di un processo molto focalizzato sulle pratiche di sviluppo, consegna un’altissima qualità tecnica.

LEGGI ANCHE: User Story Mapping: come progettare un prodotto web insieme al tuo team

Metodologia Agile: un esempio pratico

Per avere un’idea più precisa della metodologia Agile, un esempio pratico ci può aiutare a coglierne le peculiarità. Proviamo a confrontare il modo in cui due diverse metodologie operano in vari momenti del ciclo di vita del progetto. Per fare questo esempio, confrontiamo un approccio waterfall, generalmente contrapposto a quello Agile, usando come esempio il framework Scrum.

Ci preme far presente che si tratta di generalizzazioni, volutamente polarizzate sui casi estremi. La realtà è sempre più sfumata e dipende moltissimo dal grado di maturità nell’applicare entrambi gli approcci.

Sulla sinistra della tabella troviamo le fasi condivise dai due approcci, mentre nelle colonne troviamo rispettivamente la modalità di gestione della fase nei due diversi framework.

Fase	Waterfall	Agile (Scrum)
Analisi	Questa fase richiede molto tempo ed  è fatta in anticipo per evitare rework.	Step breve che non punta alla perfezione, ma coinvolge da subito il cliente su decisioni che saranno affinate in iterazioni successive.
Planning	Viene fatto all’inizio del progetto e non è più modificabile.	Priorità e timeline del lavoro ridefinite ciclicamente durante la fase di sprint review e sprint planning. Flessibilità nei cambiamenti.
Monitoring	Fatto in base al piano di progetto.	Gestito in base allo scope dello Sprint.
Collaborazione	Solo il PM è il punto di contatto tra team e cliente.	La comunicazione è frequente, faccia a faccia e tra tutti i membri del team e il cliente.
Organizzazione	Ruoli funzionali e responsabilità assegnati in modo puntuale e spesso individuale.	Team multidisciplinare, responsabilità per ogni interazione assunta dall'intero team di sviluppo.
Documentazione	Enfasi sulla produzione di documentazione di progetto esaustiva e con un alto livello di dettaglio.	È prodotta solo la documentazione di progetto necessaria alla realizzazione del software e l’esecuzione dei test. Importanza al feedback degli utenti e al relativo adattamento.

 

Bello, ma funziona veramente?

Un esempio concreto di agilità in azione è rappresentato dalla success story di Telethon che compare tra i nostri case study.  

La Fondazione Telethon ha ingaggiato SparkFabrik per migliorare la percentuale di donazioni veicolate sul sito, che al momento dell'ingaggio si attestava attorno al 3% del totale di donazioni durante la maratona invernale.

Grazie all’approccio Agile adottato dall’intera organizzazione, lo sviluppo del sito web per le donazioni è stato completato con una settimana di anticipo rispetto ai piani e senza necessità di una fase di collaudo poiché il cliente ha potuto convalidare gli incrementi di prodotto alla fine di ogni sprint. 

Poter rivedere le componenti dell’applicazione ogni settimana con gli utenti e i responsabili lato cliente ha permesso di rivedere tempestivamente gli assunti, aggiustare il tiro e prendere decisioni facili da implementare, accelerando nella giusta direzione. L’incremento delle donazioni ricevute tramite il nuovo sito è stato del 37%!

Ritrovi gli elementi discussi fin qui, all’interno di questo racconto?

Il rilascio del prodotto in tempi brevi; la costante comunicazione tra il team e il cliente; i feedback puntuali e ciclici e ovviamente anche la qualità e la soddisfazione del cliente visti i risultati ottenuti: tutti gli elementi promossi dal Manifesto Agile.

SCOPRI ALTRI FRAMEWORK:

• DevOps
• DevSecOps
• FinOps

Attenzione alle trappole: come non farsi male

Come abbiamo scritto, l’agilità è prima di tutto un mindset e richiede un cambio di rotta. Pensare di adottare Scrum e poi chiedere al proprio PM di assicurarsi che le cose vengano consegnate “esattamente come da progetto alla fine di ogni sprint” non è diverso da pretendere che “il lavoro sia terminato come da specifiche, in tempo per il SAL”. 

Si tratta di una semplice “rietichettatura” e non porterà che frustrazione e pessimi risultati, poiché non fa che accelerare la realizzazione del “piano”, spesso a scapito della qualità del prodotto (esattamente il contrario di quanto ci si prefigge!).

C’è un termine che usiamo in SparkFabrik per definire questo approccio: Agile à la carte. È un modo provocatorio per chiamare la tendenza, riscontrata in diverse nostre esperienze, ad adottare solo gli aspetti facili e immediatamente comprensibili delle metodologie e dei framework. Solitamente si tratta delle cose meno sostanziali e più di superficie, e comunque dei cosiddetti low-hanging fruit, le parti facili da appiccicare ai processi già in corso, illudendosi che questo ne cambi la sostanza.

Non c’è nulla di particolarmente deplorevole. Introdurre nuovi principi di gestione non è un processo facile né gratuito e non sempre adottare un framework è la strada migliore per “agilizzare” la propria impresa.

L’adozione di pratiche Lean, già consolidata in molti ambiti anche manageriali, o la nascita di approcci relativamente recenti e meno chiacchierati come Disciplined Agile (che si definisce un toolkit e si differenzia dai framework per il fatto di non voler essere prescrittivo) o SAFe (un insieme di pratiche e modelli per l’adozione di Agile su scala aziendale che incorpora alla sua base il concetto di value stream, mutuato proprio dal mondo Lean), sono tutti segnali che i modi di fare agilità sono tanti quante le imprese che la vogliono adottare. 

Forse è tempo di smettere di parlare di metodologia Scrum o Kanban, di strumenti, framework e soluzioni precotte, e tornare ad analizzare i principi fondamentali. Ci sono ad esempio ibridazioni interessanti tra gli approcci più tradizionali alla gestione dei progetti e le pratiche Agile, con tanto di programmi di certificazione per PMI “agilisti”, che possono costituire una soluzione ottimale per introdurre un cambio di pensiero, facendo un passo alla volta nella giusta direzione.

Il percorso da un’organizzazione “tradizionale” a una pienamente Agile è a sua volta un processo empirico, non sistematizzabile (e guardatevi da chi vi promette altrimenti). E d’altronde non c’è un momento in cui un’organizzazione diventa agile. L’agilità, come tutte le qualità, non è nettamente misurabile e a volte è solo l’osservazione di altre realtà a dirci se e come possiamo migliorare.

È bene mettere in conto esperimenti e qualche fallimento, provare più approcci e soprattutto, trovare confronto. Da questo punto di vista la partecipazione alle community, come agli eventi (siano essi conferenze di settore come Agile Business Day o le cosiddette unconference come Play14) gioca un ruolo fondamentale nel creare occasioni di confronto, di maturazione e anche nell'identificare pattern di successo e fallimento, comuni ad altre organizzazioni.

In sostanza, i percorsi e le metodologie sono numerosi e in continua evoluzione, spesso i loro nomi sono marchi registrati e servono in qualche modo a fare dell’agilità un business a sé stante.

La metodologia agile è ancora attuale?

A oltre due decadi dalla nascita del Manifesto Agile nel 2001, la domanda se Agile sia ancora rilevante nello sviluppo software è più che legittima. La risposta rimane un convinto sì. Il mondo del software è in continua evoluzione, con nuove tecnologie e requisiti emergenti che richiedono flessibilità e adattabilità, caratteristiche intrinseche dell'approccio Agile. Proprio per questo motivo, cambiamenti come l'introduzione di nuovi linguaggi di programmazione, il cloud computing e altre innovazioni tecnologiche non rischiano di rendere vetusto l'approccio Agile, ma semmai costituiscono l’occasione per applicare i principi della metodologia, testimoniandone l’estrema necessità. Ecco perché Agile continua a essere una metodologia preziosa. I principi fondamentali, come la collaborazione tra team e clienti, la consegna iterativa e incrementale e la capacità di reagire ai cambiamenti, non solo continueranno a essere utili e attuali, ma lo saranno ancora di più in contesti disruptive e scenari sempre nuovi.

I nuovi trend

Agile è dunque, a tutti gli effetti, un mindset future-proof. Sarà quindi immutabile nel corso degli anni a venire? Sarebbe ingenuo pensarlo, e le già citate ibridazioni tra diversi framework testimoniano il contrario. Semmai saranno i principi (quelli sì) a permanere a lungo pressoché immutati, mentre i framework evolveranno significativamente. Possiamo citare, ad esempio, il trend dell’Obeya Management System, un approccio che trascende e include qualsiasi metodologia Lean Agile. Anch'esso derivato dal Toyota Production System, Obeya è un sistema di Visual Management che allinea strategia ed esecuzione attraverso un'architettura collaborativa, senza necessità di certificare schiere di Scrum Master o Agile Coach. Questo sistema promuove la collaborazione, la trasparenza, la comunicazione e la responsabilità, offrendo un potente strumento di management team-centrico.

Un altro trend è legato alla crescente diffusione dei principi Agile, che hanno ormai rotto i confini dello sviluppo software per riversarsi in una gran varietà di ruoli professionali. Oggi, competenze Agile sono richieste in tantissimi ambiti aziendali, costituendo un requisito fondamentale anche per figure come project manager, addetti alle vendite, business analyst e specialisti di risorse umane, solo per citarne alcuni. Questo sottolinea l'importanza di una mentalità agile diffusa in tutta l'organizzazione, a tutti i livelli.

Come la metodologia Agile può esserti utile?

In conclusione, possiamo dire che le metodologie Agile possono essere un ingrediente fondamentale per accompagnare le aziende verso una piena trasformazione digitale. Un nuovo modo di lavorare, ideale per mettere in pista una gestione efficiente di progetti con una forte connotazione Digital e Cloud.

L’agilità è una qualità che, una volta acquisita, si riflette lungo tutto il ciclo di vita di un progetto portando benefici in termini di qualità del prodotto, soddisfazione del cliente, capacità di controllo e monitoraggio, incremento della predicibilità dei risultati e riduzione dei rischi, maggiore flessibilità e promozione di miglioramenti continuati ed evoluzioni incrementali.

Ultimo, ma non meno importante, implementare una metodologia Agile con successo, si riflette positivamente sul morale del team e migliora sensibilmente le dinamiche al suo interno; aspetti fondamentali per mantenere un ambiente di lavoro stimolante, creativo e orientato al risultato.

Ciò che conta di più è maturare la corretta postura verso il modo in cui l’organizzazione affronta i progetti. Invece che cercare di prevenire ogni possibilità e sperare che le cose vadano come programmato dall’inizio alla fine, accettare che il mondo è complesso e imprevedibile, lavorare iterativamente con trasparenza e gli occhi ben aperti e adattare i propri piani per massimizzare il valore, impiegando le risorse per trarne il miglior risultato possibile.