Statistiche sulla velocità dello sviluppo software enterprise (2026)

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Le statistiche sulla velocità dello sviluppo software enterprise sono facili da trovare e difficili da verificare. La maggior parte delle raccolte mescola dimensioni di mercato e promesse dei fornitori e raramente dice quanto velocemente i team reali portano il codice dall’idea alla produzione. Questa pagina raccoglie solo dati legati alla velocità — benchmark di rilascio, cycle time, esperimenti controllati sull’IA, sforamenti di progetto e studi sull’uso del tempo — e indica la fonte e l’anno di ogni numero.

Il pubblico sono i responsabili tecnologici che hanno bisogno di una base difendibile: un CTO che prepara un aggiornamento per il consiglio di amministrazione, un VP Engineering che fissa gli obiettivi del prossimo anno o un ufficio acquisti che confronta fornitori che promettono una «consegna due volte più rapida». Se sta pianificando un grande progetto e vuole vedere come questi benchmark si traducono in un piano di rilascio, la pagina sui nostri servizi di sviluppo software enterprise mostra come organizziamo team, pipeline e milestone attorno a essi.

Legga i numeri tenendo presente una cautela: le metriche di velocità hanno senso solo insieme alla stabilità. Un team che rilascia dieci volte al giorno e rompe la produzione ogni settimana non è veloce, è rumoroso. Per questo ogni sezione qui sotto affianca dati di throughput e dati di qualità, esattamente come i KPI per lo sviluppo software andrebbero affiancati nella Sua dashboard.

Quali sono le principali statistiche sulla velocità dello sviluppo software enterprise nel 2026?

Le principali statistiche sulla velocità dello sviluppo software enterprise nel 2026 coprono quattro ambiti: quanto spesso i team rilasciano, quanto tempo impiega una modifica ad arrivare in produzione, quanto l’IA cambia questi tempi e quanto spesso i grandi programmi sforano. Questi dodici numeri sono i più citati nelle discussioni di pianificazione; ciascuno è spiegato in dettaglio più avanti.

1. Il 19% dei team era d’élite nella ricerca State of DevOps 2024 di DORA, con rilasci su richiesta e lead time inferiori a un giorno; il 25% era a bassa performance e rilasciava tra una volta al mese e una volta ogni sei mesi.
2. Meno di 25 ore è il cycle time d’élite (dal primo commit alla produzione) nei benchmark LinearB 2026, basati su 8,1 milioni di pull request di 4.813 team.
3. Meno di 1 ora di pickup e meno di 3 ore di revisione caratterizzano un flusso di pull request d’élite nello stesso dataset.
4. Il 90% dei professionisti tecnologici usava l’IA al lavoro secondo il report DORA 2025, e oltre l’80% dichiarava che aumentava la propria produttività.
5. Il 55,8% più veloci: è il risultato degli sviluppatori che usavano GitHub Copilot in un esperimento controllato del 2023.
6. Circa il 21% più veloci: è il risultato di 96 ingegneri Google che usavano l’IA in uno studio randomizzato del 2024.
7. Il 19% più lenti: sviluppatori open source esperti hanno impiegato più tempo su compiti reali con strumenti di IA nello studio METR del 2025, pur credendo di essere stati il 20% più veloci.
8. Il 91% in più di tempo di revisione e il 98% in più di pull request unite sono stati misurati da Faros AI nel 2025 nei team con uso intensivo di IA.
9. 10–15% di guadagno di produttività dai soli assistenti di codice IA, che sale al 25–30% con una riprogettazione completa dei processi, secondo il Bain Technology Report 2025.
10. Il 16% del tempo degli sviluppatori va alla scrittura di codice secondo l’Atlassian State of Developer Experience 2025; metà degli sviluppatori perde 10 o più ore a settimana per attriti organizzativi.
11. Il 45% oltre il budget e il 7% oltre i tempi è la media dei grandi progetti IT, con il 56% di valore in meno rispetto alle previsioni (McKinsey e Università di Oxford).
12. L’80% delle grandi organizzazioni di ingegneria del software avrebbe avuto team di platform engineering entro il 2026 secondo una previsione Gartner, contro il 45% del 2022.

Quanto velocemente rilasciano i team enterprise? Benchmark DORA

I team enterprise rilasciano a velocità molto diverse: nella ricerca DORA 2024, il quinto più veloce rilascia su richiesta con lead time inferiori a un giorno, mentre il quarto più lento impiega da uno a sei mesi perché una modifica arrivi in produzione. DORA (DevOps Research and Assessment, oggi parte di Google Cloud) conduce questa indagine da oltre dieci anni, il che ne fa il benchmark pubblico più usato per le prestazioni di rilascio del software.

DORA misura la velocità con due metriche — frequenza di deployment e lead time delle modifiche — e la stabilità con altre due: tasso di fallimento delle modifiche e tempo di ripristino dopo un deployment fallito. I cluster di performance 2024 sono questi:

Fonte: DORA, Accelerate State of DevOps Report 2024. Le percentuali sono quote di rispondenti, non di aziende.

Per chi lavora in un’azienda enterprise contano due dettagli. Primo, velocità e stabilità vanno di pari passo: i team d’élite hanno sia i lead time più brevi sia i tassi di fallimento più bassi, il che smentisce la convinzione diffusa che andare più veloci significhi rompere di più. Secondo, il cluster medio ha un tasso di fallimento più basso (10%) di quello alto (20%). DORA lo spiega con il fatto che alcuni team comprano stabilità rilasciando meno spesso, un compromesso che di solito non regge quando i sistemi crescono.

Cosa è cambiato nel report DORA 2025?

Il report DORA 2025, pubblicato a settembre 2025 con il titolo State of AI-assisted Software Development, ha sostituito i quattro cluster classici con sette archetipi di team, basati su quasi 5.000 risposte e oltre 100 ore di interviste. Il cambiamento principale riguarda l’IA: per la prima volta la sua adozione risultava positivamente legata al throughput di rilascio, pur restando negativamente legata alla stabilità.

Per le aziende, gli archetipi «frenati dai processi» e «collo di bottiglia legacy» coprono insieme il 28% dei rispondenti. Sono i due punti in cui la velocità si perde a causa dell’organizzazione e dell’architettura e non delle competenze degli ingegneri, ed entrambi sono tipici delle grandi aziende con sistemi core di lunga data.

Cosa ha rilevato DORA nel 2024 su IA e velocità di rilascio?

Nel 2024 DORA ha rilevato che un aumento del 25% nell’adozione dell’IA si associava a un calo dell’1,5% del throughput di rilascio e del 7,2% della stabilità, anche se la stessa adozione aumentava la produttività individuale del 2,1%, la soddisfazione sul lavoro del 2,6% e la qualità della documentazione del 7,5%. La spiegazione: l’IA rende facile produrre lotti di modifiche più grandi, e DORA ha sempre associato i lotti grandi a rilasci più lenti e rischiosi. Nel 2025 l’effetto sul throughput è diventato positivo, ma la penalità sulla stabilità è rimasta.

Qual è un buon cycle time? Benchmark di ingegneria

Un buon cycle time per un team enterprise è inferiore a una settimana lavorativa, e i team d’élite scendono sotto le 25 ore dal primo commit alla produzione secondo i Software Engineering Benchmarks 2026 di LinearB. Il dataset copre 8.109.244 pull request di 4.813 team e 163.820 contributori in 42 Paesi, ed è una delle maggiori fonti pubbliche di dati sulla velocità a livello di pull request.

Il cycle time si scompone in fasi, e ogni fase ha il proprio benchmark. Analizzarle separatamente è il modo più rapido per capire dove un team enterprise perde giorni:

Fonte: LinearB, 2026 Software Engineering Benchmarks Report (soglie P75 del livello d’élite).

La tabella spiega perché le modifiche piccole contano tanto. Pickup e revisione sono le fasi in cui le pull request aspettano, e l’attesa cresce con la dimensione: una modifica di 100 righe si revisiona in pochi minuti, una di 1.000 righe aspetta che qualcuno abbia un pomeriggio libero. I team che riducono il cycle time di solito lo fanno rimpicciolendo le pull request e proteggendo il tempo di revisione, non chiedendo agli ingegneri di digitare più in fretta. La nostra guida su CI/CD nello sviluppo software affronta il lato pipeline dello stesso problema: la fase di deploy.

Come cambia la velocità delle pull request con il codice generato dall’IA?

Il codice generato dall’IA rende le pull request più grandi e più lente da unire, secondo i dati LinearB 2026. Le pull request assistite dall’IA erano di 408 righe al 75° percentile contro 157 senza IA, e solo il 32,7% delle pull request generate dall’IA veniva unito entro 30 giorni, contro l’84,4% di quelle manuali. Nello stesso tempo, l’88,3% delle organizzazioni usava strumenti di IA ogni giorno o più volte a settimana e il 44,7% non ne misurava formalmente l’impatto.

Jellyfish ha osservato il lato più ottimista della stessa tendenza nel suo bilancio 2025: quando l’adozione dell’IA in un team passava dallo 0% al 100%, il cycle time mediano scendeva da 16,7 a 12,7 ore (24% più veloce) e le pull request per ingegnere salivano da 1,36 a 2,9. L’adozione di agenti IA per la revisione del codice è cresciuta dal 14,8% al 51,4% delle aziende tra gennaio e ottobre 2025. I due dataset sono compatibili: i team che adottano pienamente l’IA e adattano il processo di revisione accelerano, mentre quelli che aggiungono semplicemente codice IA a un processo invariato creano una coda di revisione.

Le grandi aziende rilasciano software più lentamente delle startup?

Le grandi aziende rilasciano software in modo misurabilmente più lento delle startup, ma il divario è minore di quanto molti pensino e nasce dal carico organizzativo, non dalle capacità di ingegneria. I dati LinearB analizzati da DevPro Journal (3,6 milioni di pull request) collocavano il cycle time d’élite enterprise sotto le 29 ore, contro meno di 27 ore per le scale-up e meno di 21 ore per le startup.

Fonte: DevPro Journal, «A Quantitative (and Actionable) Analysis of Enterprise Software Delivery Speed», gennaio 2024, su dati LinearB.

La stessa analisi ha rilevato che i team enterprise condividono solo circa il 70% delle ore lavorative, perché sono distribuiti su più fusi orari. Questo da solo allunga i tempi di pickup e di revisione. Aggiungendo comitati di approvazione delle modifiche, revisioni di sicurezza, release train condivisi e dipendenze tra decine di servizi, le otto ore in più di cycle time d’élite si spiegano facilmente.

DORA indica altri due freni tipici delle grandi aziende. Le priorità organizzative instabili erano associate nel 2024 a un rischio di burnout più alto del 40%, e i team obbligati a usare una piattaforma interna hanno visto il throughput calare dell’8% e la stabilità delle modifiche del 14%. In altre parole, le strutture che le aziende introducono per andare più veloci possono rallentarle quando vengono imposte invece che adottate.

L’IA rende più veloce lo sviluppo software? Cosa mostrano gli studi

L’IA rende più veloci i compiti di sviluppo isolati negli esperimenti controllati, in genere del 20–55%, ma il suo effetto sul rilascio end-to-end in azienda è minore, e per sviluppatori esperti su codebase complesse può persino essere negativo. La risposta dipende da cosa si misura: un singolo compito ben definito, la settimana di uno sviluppatore o il percorso di un team dall’idea alla produzione.

Perché i guadagni sui singoli compiti non si traducono in rilasci più rapidi?

I guadagni dell’IA sui singoli compiti non si trasferiscono uno a uno sul rilascio perché scrivere codice è solo una piccola parte del ciclo di consegna. Bain stima che scrivere e testare il codice occupi solo il 25–35% del tempo dall’idea al lancio; il resto va a discovery, progettazione, revisione, integrazione, approvazioni e rilascio. Un passaggio di codifica più rapido del 50% dentro una fetta del 30% del calendario fa risparmiare al massimo circa il 15%, e solo se i passaggi successivi tengono il passo.

Faros AI lo chiama «paradosso della produttività dell’IA»: la produzione individuale sale molto, ma le metriche a livello aziendale si muovono appena, perché il codice in più si accumula in revisione e test. Nei dati 2025 Faros non ha trovato alcuna correlazione significativa tra adozione dell’IA e miglioramenti del rilascio a livello di azienda. L’indagine di Bain va nella stessa direzione: tre aziende su quattro indicano come parte più difficile dell’adozione dell’IA il cambiamento del modo di lavorare, non l’introduzione degli strumenti.

Dove l’IA fa risparmiare più tempo?

L’IA fa risparmiare più tempo su attività ben definite e poco complesse come documentazione, codice ripetitivo e scheletri di test, e meno su progettazione complessa e debugging in codebase grandi e poco conosciute. Questo schema attraversa tutti gli studi citati: l’esperimento Copilot usava un piccolo compito partendo da zero, mentre METR usava repository grandi e maturi che gli sviluppatori conoscevano già bene. Per i team enterprise ciò suggerisce di puntare l’IA prima su documentazione, migrazioni, generazione di test e codice di integrazione ripetitivo. Il nostro articolo su come i team sviluppano davvero con l’IA descrive questi flussi di lavoro nel dettaglio.

Statistiche su adozione e fiducia nell’IA nei team software

L’IA fa ormai parte del lavoro di quasi tutti gli sviluppatori, ma la fiducia nei suoi risultati è bassa, e questo limita il guadagno di velocità reale. Questi dati su adozione e fiducia spiegano perché revisione e verifica sono diventate il nuovo collo di bottiglia:

• L’84% degli sviluppatori usa o intende usare strumenti di IA, contro il 76% del 2024, e il 51% degli sviluppatori professionisti li usa ogni giorno (Stack Overflow Developer Survey 2025).
• Solo il 3,1% degli sviluppatori si fida molto dell’accuratezza dell’IA, mentre il 45,7% ne diffida attivamente; il giudizio favorevole è sceso al 60% (Stack Overflow 2025).
• Il 66% indica come principale frustrazione le risposte dell’IA «quasi giuste, ma non del tutto», e il 45,2% afferma che il debugging del codice generato dall’IA richiede più tempo (Stack Overflow 2025).
• Il 30% dei rispondenti del report DORA 2025 aveva poca o nessuna fiducia nel codice generato dall’IA, e l’utente mediano lavorava con l’IA circa 2 ore al giorno.
• Il 99% degli sviluppatori dice che l’IA fa risparmiare tempo e il 68% risparmia più di 10 ore a settimana (Atlassian State of Developer Experience 2025).
• Il 90% degli ingegneri software enterprise userà assistenti di codice IA entro il 2028, contro meno del 14% all’inizio del 2024 (previsione Gartner).

Il contrasto tra «il 99% risparmia tempo» e «il 3,1% si fida molto dei risultati» è il cuore del quadro 2026. Il tempo risparmiato in scrittura viene in parte speso di nuovo in verifica, e la verifica avviene nella code review, la fase che già limita il cycle time.

Quanto tempo dedicano davvero alla programmazione gli sviluppatori enterprise?

Gli sviluppatori enterprise dedicano alla scrittura di codice solo l’11–16% del tempo di lavoro secondo due dei grandi studi più recenti, quindi i maggiori guadagni di velocità arrivano di solito dalla riduzione degli attriti attorno al codice e non da una codifica più veloce. L’Atlassian State of Developer Experience 2025, basato su 3.500 sviluppatori e manager in sei Paesi, colloca la codifica al 16% del tempo.

Fonte: Microsoft Research, «Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era», ICSE SEIP 2025, indagine su 484 sviluppatori Microsoft. Il tempo restante è distribuito su altre attività.

Gli attriti sono il motivo principale di una quota di codifica così bassa. Nello studio Atlassian, il 50% degli sviluppatori perdeva 10 o più ore a settimana per inefficienze organizzative e il 90% almeno 6 ore; le cause principali erano la ricerca di informazioni, l’adattamento a nuove tecnologie e i cambi di contesto. Il 63% dichiarava che i propri responsabili non comprendevano questi problemi, contro il 44% dell’anno precedente.

Il debito tecnico è la versione di lungo periodo dello stesso problema. Lo studio Developer Coefficient di Stripe ha rilevato che, su una settimana media di 41,1 ore, gli sviluppatori dedicavano 17,3 ore alla manutenzione, di cui 13,5 al debito tecnico, e il 52% indicava sistemi legacy e debito tecnico come principale ostacolo alla produttività. Il dato risale al 2018, ma resta la misura più citata di quanta capacità assorba il codice vecchio, ed è coerente con l’11% di rispondenti che DORA 2025 classifica come «collo di bottiglia legacy».

Quanto spesso i progetti software enterprise sono in ritardo o fuori budget?

I grandi progetti software enterprise sono più spesso in ritardo o fuori budget che in regola: uno studio di McKinsey e dell’Università di Oxford su oltre 5.400 progetti IT da più di 15 milioni di dollari ha rilevato in media uno sforamento del budget del 45%, un ritardo del 7% e il 56% di valore in meno del previsto. Circa il 17% di quei progetti è andato così male da minacciare l’esistenza stessa dell’azienda.

• 45% di sforamento medio del budget, 7% di ritardo e 56% di valore in meno del previsto per i grandi progetti IT (McKinsey e Università di Oxford).
• Ogni anno in più di durata del progetto aggiungeva circa il 15% allo sforamento dei costi nello stesso studio: i progetti lunghi sono quindi sproporzionatamente rischiosi.
• Il 31% dei progetti software era riuscito, il 50% in difficoltà e il 19% fallito secondo i dati CHAOS 2020 dello Standish Group; il tasso di successo era del 16,2% nel 1994 e del 37% nel 2012.
• I piccoli progetti riescono in circa il 90% dei casi secondo i dati CHAOS, quelli molto grandi in meno del 10%.
• Il 73,8% dei progetti raggiungeva in media gli obiettivi di business secondo il PMI Pulse of the Profession 2024.
• I progetti guidati da professionisti con forte acume di business raggiungevano gli obiettivi nell’83% dei casi, rispettavano i tempi nel 63% e il budget nel 73% dei casi secondo l’indagine PMI 2025 su quasi 3.000 rispondenti.

Il denominatore comune è la dimensione. Gli sforamenti crescono con durata e perimetro, e i progetti migliori sono suddivisi in piccoli rilasci, ciascuno con un valore autonomo — la stessa lezione che DORA e LinearB traggono a livello di singola modifica. Si noti anche che il 7% di ritardo sottostima il ritardo percepito dagli utenti: i progetti rispettano spesso le date tagliando il perimetro, ed è per questo che il deficit di valore (56%) è molto più ampio del ritardo. Per dimensionare un progetto prima di avviarlo, consulti la nostra guida alla stima dei progetti software.

Platform engineering, low-code e altre leve di velocità: statistiche

Il platform engineering è la leva di velocità più diffusa nelle aziende: Gartner prevede che entro il 2026 l’80% delle grandi organizzazioni di ingegneria del software avrà team di piattaforma, contro il 45% del 2022. I dati DORA mostrano che il beneficio è reale, ma dipende da come la piattaforma viene introdotta.

Lo schema è coerente: gli strumenti accelerano il rilascio quando eliminano attese e passaggi manuali, e lo rallentano quando aggiungono processi obbligatori. Una piattaforma «golden path» che rende la strada giusta anche la più semplice aiuta; una piattaforma imposta a ogni team a prescindere dall’utilità danneggia. Lo stesso vale per l’automazione cloud, ed è per questo che consideriamo l’ingegneria cloud e DevOps parte della velocità di rilascio e non un lavoro infrastrutturale separato.

Come misurare la velocità di rilascio della propria azienda?

Per misurare la velocità di rilascio occorre rilevare le quattro metriche DORA e le fasi del cycle time sui propri dati per almeno un trimestre, poi confrontare le mediane con i benchmark pubblici illustrati sopra. Le medie di settore diventano utili solo quando si conosce la propria base di partenza. Una sequenza pratica è questa:

1. Definire il perimetro. Inizi da tre-cinque team responsabili di servizi rilasciabili, non dall’intera organizzazione; i portafogli misti nascondono i colli di bottiglia.
2. Raccogliere le quattro metriche DORA. Frequenza di deployment e lead time arrivano dal sistema CI/CD, tasso di fallimento e tempo di ripristino dai dati sugli incidenti.
3. Scomporre il cycle time. Misuri separatamente codifica, pickup, revisione e deploy a partire dal sistema di controllo versione; la fase più lenta è il primo obiettivo.
4. Monitorare la dimensione delle pull request. Mediana e 75° percentile delle righe modificate per pull request prevedono i ritardi di revisione meglio di qualsiasi altro singolo numero.
5. Aggiungere una lente IA. Etichetti le pull request assistite dall’IA e ne confronti dimensione, tempo di revisione e tasso di merge con le altre, come fa LinearB.
6. Rilevare gli attriti. Chieda agli sviluppatori quante ore a settimana perdono tra attese, ricerche e cambi di contesto; i dati Atlassian offrono un termine di paragone.
7. Rivedere ogni trimestre e cambiare una cosa alla volta. Tratti ogni miglioramento come un esperimento e osservi le metriche di stabilità con la stessa attenzione di quelle di velocità.

Eviti di trasformare questi numeri in obiettivi individuali. DORA e il framework SPACE avvertono entrambi che le metriche di rilascio descrivono sistemi, non persone; quando gli ingegneri vengono valutati sul numero di pull request, quel numero sale, ma la velocità di rilascio no. La nostra guida al DevOps nello sviluppo software illustra le pratiche che migliorano queste metriche in modo sostenibile.

Cosa significano queste statistiche per chi acquista software enterprise nel 2026?

Per le aziende che acquistano o commissionano software enterprise nel 2026, le statistiche portano a una conclusione: la velocità di rilascio dipende da dimensione dei lotti, flusso di revisione e attriti organizzativi molto più che da organico o strumenti. Quando valuta un piano interno o un partner esterno, queste sono le domande che i dati suggeriscono di porre:

• Quale cadenza di rilascio è prevista? Un piano con un unico grande rilascio finale porta con sé il rischio di sforamento del 45% dei grandi progetti; rilasci mensili o più frequenti lo riducono.
• Come verranno riportati lead time e tasso di fallimento delle modifiche? Un fornitore che non sa mostrare le metriche DORA dei progetti in corso Le chiede di fidarsi di una promessa.
• Come viene revisionato il codice generato dall’IA? Pull request più grandi e revisioni più lunghe legate all’IA sono ben documentate; un team credibile ha una regola per entrambe.
• Quanta parte del calendario è attesa? Approvazioni, ambienti e richieste di accesso consumano spesso più tempo di calendario dello sviluppo stesso.
• Come viene suddiviso il perimetro in rilasci? Secondo i dati CHAOS i piccoli progetti riescono circa nove volte più spesso di quelli molto grandi, quindi chieda come il perimetro sarà diviso in incrementi con valore autonomo.
• Cosa misura il team prima del primo rilascio? Una base rilevata già nel primo sprint rende verificabili le successive affermazioni sulla velocità e fa emergere presto ambienti lenti e passaggi di approvazione.
• Come viene gestita l’integrazione con i sistemi legacy? I colli di bottiglia legacy riguardano circa un team su nove in DORA 2025, ed è nell’integrazione che i calendari enterprise slittano più spesso.

Questi criteri valgono sia per una nuova piattaforma, sia per un programma di modernizzazione, sia per un progetto ad alta intensità di integrazione. Spiegano anche perché il mercato dello sviluppo software su misura continua a spostarsi verso partner in grado di mostrare dati di rilascio e non solo tariffe orarie, e perché le tendenze dello sviluppo software nel 2026 sono dominate da platform engineering e governance dell’IA più che da nuovi linguaggi.

FAQ

Pubblicato il 25 ottobre 2026. Fonti: DORA, Accelerate State of DevOps Report 2024; DORA, State of AI-assisted Software Development 2025; LinearB, 2026 Software Engineering Benchmarks; DevPro Journal, analisi della velocità di rilascio enterprise (2024); Faros AI, The AI Productivity Paradox (2025); Jellyfish, 2025 AI metrics in review; Peng et al., The Impact of AI on Developer Productivity (2023); Google, How much does AI impact development speed? (2024); METR (2025) e aggiornamento METR (2026); Stack Overflow Developer Survey 2025; Bain Technology Report 2025; Atlassian State of Developer Experience 2025; Microsoft, Time Warp (2025); Stripe, The Developer Coefficient (2018); McKinsey e Università di Oxford, Delivering large-scale IT projects on time, on budget, and on value (2012); Standish Group CHAOS 2020; PMI Pulse of the Profession 2024 e 2025; previsioni Gartner su assistenti di codice IA, platform engineering e low-code. Le previsioni sono stime, non misurazioni.