“Le metriche funzionali restano chiave nell’era dell’IA” Conversazione con Luigi Buglione

Il 16 maggio scorso, in occasione del 1° Evento Metrico organizzato dal GUFPI-ISMA a Roma, iniziativa che abbiamo avuto il piacere di sponsorizzare, abbiamo avuto l’opportunità di confrontarci con uno dei massimi esperti internazionali nel campo delle metriche software: Luigi Buglione.

Presidente di GUFPI-ISMA, Segretario di IFPUG, Direttore per le Università e Vicepresidente dell’ISBSG, Luigi ha dedicato la sua carriera alla promozione di standard quali gli IFPUG Function Points e SNAP, con l’obiettivo di ottimizzare la stima, la produttività e il processo decisionale basato sui dati.

In questa intervista, abbiamo approfondito il ruolo dell’intelligenza artificiale nello sviluppo e nella stima del software, lo stato attuale dell’Agile, l’imprescindibile necessità di misurare per migliorare e come affrontare le sfide future integrando una prospettiva quantitativa e umana.

Intervista realizzata da Julián Gómez, CDAIO di LedaMC e Quanter. In italiano, con sottotitoli disponibili in spagnolo e inglese.

Julián Gómez: Prima di tutto, grazie, Luigi, per aver accettato questa intervista. Credo che sarà molto interessante perché sei un punto di riferimento nel mondo delle metriche.
La tua opinione è sempre importante per capire come evolverà questo mondo.

Luigi Buglione: Grazie a te, Julián, grazie a Quanter Smart AI Estimation.

J.G.: Ok, grazie. Per cominciare, H.P. Lovecraft diceva: «Non è morto ciò che può attendere in eterno, e con il passare di strani eoni anche la morte può morire».
Agile è morto o ha ancora molto da offrire?

L.B.: Ha ancora molto valore da offrire. Quello che serve è migliorare le nostre competenze, soprattutto su come misurare sprint e interazioni.

Bisogna smettere di fare stime basate solo sull’esperienza, usando story point o t-shirt sizing, e iniziare a introdurre come base nella pianificazione degli sprint anche una misurazione funzionale e non funzionale, ma con metriche quantitative.

Usare Function Point, SNAP Point o altre metriche ISO non funzionali può sicuramente aiutare.

Senza questo, le stime in giorni-persona continuano a essere molto variabili.

J.G.: Ok, bene, ma restando su questa linea, visto che stiamo parlando della valorizzazione dei Function Point e degli SNAP Point, recentemente IFPUG, in collaborazione con Quanter, ha pubblicato un report sul mercato dello sviluppo software, evidenziando i benefici di queste metriche anche in contesti Agile. Quali benefici vedi per le aziende che non hanno ancora utilizzato metriche basate sul prodotto software? Che cosa si stanno perdendo?

L.B.: Principalmente due cose:

Non possono quantificare il valore di un asset, perché ciò che non misuri non esiste: esiste soltanto il tempo di lavoro.

E l’altra cosa diventa molto importante anche per un altro elemento che coinvolge molte delle nostre aziende, all’interno di un altro gruppo che è ISBSG, cioè la produttività.

Se non hai una quantità divisa per un tempo di lavoro, non puoi calcolare la produttività, perché avrai solo uno sforzo espresso in story point o in una stima basata sull’esperienza.

E quindi, mancando l’elemento della storicizzazione, ogni volta si riparte da zero. In italiano diremmo: un po’ come la memoria di un pesce rosso.

J.G.: Effettivamente. Hai parlato altre volte del concetto di decisioni basate sui fatti, qualcosa che si applica perfettamente al paradigma dello sviluppo software. Quali errori comuni vedi nelle organizzazioni quando cercano di prendere decisioni basate sui dati?

L.B.: Che non raccolgono dati.

E in particolare i capi progetto, che normalmente dovrebbero aver studiato, anche su guide come il PMBOK e molte altre, che la prima cosa da fare in una fase di chiusura è storicizzare i dati. In un progetto Agile, questo significa fare una retrospective.

Il problema è che non sempre si fa, perché si dice che manca il tempo per farla.
Il che vuol dire che non è stata pianificata.

E quindi questo può essere il primo punto di miglioramento.

J.G.: Ok, grazie Luigi. Con la tua esperienza in organizzazioni come GUFPI-ISMA, IFPUG o ISBSG, che cosa pensi serva per superare la resistenza che alcune aziende mostrano ancora nell’adottare standard ISO/IEE come IFPUG Function Points o IFPUG SNAP Points?

L.B.: L’importante è capire bene il punto di vista di chi risponderebbe: «Non mi servono» o «Penso che non servano».

La motivazione, nella mia esperienza, è che spesso si incontrano manager che non vogliono approfondire il tema e guardano solo alla redditività di breve periodo.

Se invece uno cominciasse a capire che non puoi dire quanto tempo ti serve per fare una cosa se prima non dici quanto è grande, e per di più con una misura oggettiva, che abbia un margine di soggettività molto, molto ridotto, allora qualsiasi numero diventa importante.

Come nella “Guida galattica per autostoppisti“, dove il numero magico è 42.

J.G.: Esattamente, tutto torna. Ci sono critiche ai processi di misurazione, no? Alcuni li considerano un carico inutile che non porta benefici.

Tuttavia Agile ci ha mostrato che usare le metriche giuste fa la differenza.
Lord Kelvin diceva: «Ciò che non si misura non si può migliorare». Pensi che questa frase sia ancora valida oggi?

L.B.: Assolutamente sì, ma per un motivo molto, molto semplice: se non sai quanto vale un oggetto, cioè la sua quantità, non puoi sapere quanto tempo richiede.

E se non sai quanto tempo richiede, né chi ci lavorerà, non sai quanto può costarti, né a quanto venderlo se fossi un fornitore, o quanto pagarlo se fossi un cliente.

Noi lo chiamiamo un flusso QTC: dalle quantità ai tempi, dai tempi ai costi.

Quindi un’altra delle cose che suggeriamo a tutta la comunità, metrica e non metrica, è usare le misure per determinare il tempo corretto e, a seconda delle persone assegnate al progetto, che hanno costi differenti.

Tenere conto dello skill mix, del costo medio giornaliero di quel team in quel contesto, per poi definire un prezzo di mercato.

Ed è questo che chiamiamo modello ABC.

J.G.: Perfetto, Luigi. Questo primo evento di GUFPI-ISMA dell’anno sta riscuotendo un grande successo. E quest’anno è sponsorizzato da Quanter, uno dei primi strumenti che integra l’intelligenza artificiale nel processo di stima.

Dal tuo punto di vista, come esperto di metriche, come dovrebbe un professionista integrare le metriche nel proprio lavoro quotidiano? Quali consigli daresti, oltre naturalmente all’uso di Quanter Smart AI Estimation?

L.B.: Ovviamente! Avere una buona pratica di prompt engineering è fondamentale.
Oggi, anche se in questa intervista non si sente, abbiamo generato canzoni con l’intelligenza artificiale. Anzi, ne abbiamo fatte varie versioni con prompt di meno di 10 parole, ottenendo un effetto che, a detta del pubblico, è stato simpatico, piacevole ed efficace.

La generazione e la strutturazione dei requisiti stanno diventando un patrimonio molto importante per un business analyst che, se ha o acquisirà competenze metriche, potrà usare l’intelligenza artificiale per accelerare i tempi, a condizione di aver ben compreso come interagire con la macchina.

Come è stato detto in una delle presentazioni di oggi: interazione uomo-IA, non più interazione uomo-macchina. E questa è sicuramente la direzione.

J.G.: Sì, possiamo dire che l’intelligenza artificiale non sostituirà le persone, ma le potenzierà. Grazie.

In questo contesto, come vedi l’impatto dell’intelligenza artificiale nello sviluppo software? Per esempio, l’uso di assistenti per generare codice e automatizzare i test. Che impatto pensi che avrà sulle metriche tradizionali come gli IFPUG Function Point o SNAP?

L.B.: Come si è detto anche in molte presentazioni di oggi e di altri eventi, bisogna mantenere consapevolezza sulle allucinazioni dell’IA.

Un hashtag che abbiamo proposto in ISBSG è #datahallucination.

Per cominciare a distinguere anche in gare, capitolati o contratti i valori non verificati di produttività, sizing o effort, se poi non c’è una corrispondenza con il mondo reale.

Generare modelli di machine learning ha comunque un costo. Quindi quello che va rivisto in un ciclo di vita complessivo è spostare a monte, nelle fasi iniziali, costi maggiori, che poi si ridurranno nelle fasi di elaborazione e realizzazione.

Parliamo quindi di una rimodulazione dei costi, non di piccoli risparmi: questo è indubbio.

L’altro elemento è che, come per tutti gli strumenti, non bisogna vedere l’IA come una sostituzione dell’uomo, ma come uno strumento che deve rimanere sotto il controllo dell’uomo.

J.G.: Grazie Luigi. Pensi che queste metriche continueranno a essere applicabili così come sono o sarà necessario adattarle a questo nuovo contesto dominato dall’IA?

L.B.: La parte funzionale nasce nel 1979 con Albrecht e rimane una metrica di processo, quindi indipendente dalla tecnologia.

La falsa credenza è pensare che la produttività sia legata solo alle quantità, mentre in realtà è nel rapporto tra quantità e tempi. Quindi misurare funzionalità rimarrà un processo stabile.

Quello che cambierà sarà la tecnica: IFPUG, COSMIC, NESMA, FISMA, Mark II… ma l’approccio rimarrà stabile.

Quello che cambierà, anche per noi in IFPUG, è che, creando e aggiornando SNAP, dovremo tenere sempre più conto, insieme a Fabrizio Di Cola e al gruppo non funzionale, della qualità dei dati, come definita dalla ISO 25012, attualmente non prevista in modo stretto nel modello, e anche della ISO 25059.

Perciò, quello che probabilmente vedremo saranno evoluzioni del modello SNAP.

J.G.: Ok, perfetto, grazie Luigi. Ora stanno emergendo nuovi approcci alla programmazione, come il Vibe Coding, dove l’IA genera codice a partire da descrizioni in linguaggio naturale. Secondo te arriveremo anche a una Vibe Estimation, in cui l’esperto di metriche coordinerà assistenti IA per fare le stime?

L.B.: Dipenderà sempre dai costi e dal rapporto costi-benefici.

Inizialmente ci saranno aziende che investiranno di più per avere prodotti che, in qualche modo, saranno assistenti per altri stakeholder.

E dipenderà sostanzialmente dalla quantità di dati e dal costo per addestrare un sistema che possa poi essere rivenduto al giusto prezzo.

Il problema sarà sempre la verifica a monte della correttezza dei dati immessi, che non riguarda né la qualità del codice né la qualità dell’IA, che in fondo è software, ma la qualità dei dati, che in ogni caso saranno sempre verificati in qualche modo dall’essere umano.

J.G.: Ok, perfetto, e l’ultima domanda è la più difficile di tutte, per concludere!
Inter o Milan?

L.B.: Inter. 31 maggio, Monaco.

J.G.: Grazie Luigi, è stato un piacere!

L.B.: Grazie a voi.