Molte aziende non hanno una cultura DevOps completa

Lo sviluppo software moderno si basa su iniziative DevOps e su metodi di lavoro agili. Ma un recente studio dimostra che questo potenziale è ben lungi dall'essere sfruttato nelle aziende internazionali: Meno della metà dei team di sviluppatori intervistati utilizza già i metodi di lavoro pertinenti in modo completo e ha un livello di maturità DevOps corrispondentemente elevato.

Le aziende che investono in DevOps ne traggono vantaggio. Secondo uno studio, è quindi giunto il momento di pensare ai metodi di lavoro agili fino in fondo. (Immagine: Unsplash.com)

Le aziende sprecano potenziale nello sviluppo del software: meno della metà ha una cultura DevOps completa. Lo dimostra l'indagine sullo stato dell'esperienza degli sviluppatori 2022 di LeanIX. Secondo questo studio, la maggior parte degli intervistati applica i metodi caratteristici di DevOps solo sporadicamente e si lamenta più spesso che gli ostacoli diventano una sfida nel lavoro quotidiano. Considerando l'importanza dello sviluppo del software per il raggiungimento degli obiettivi aziendali, è allarmante che la maggior parte dei team di sviluppo abbia una scarsa conoscenza del valore immediato del proprio lavoro per i clienti, conclude lo studio. Sono disponibili solo pochi indicatori chiave di prestazione e anche l'efficienza dello sviluppo del software non è misurata in modo sufficiente. Un quarto degli intervistati non determina una delle quattro metriche DORA riconosciute. La mancanza di metriche sui benefici per i clienti e sull'efficienza rende difficile la comunicazione: solo il 42% degli intervistati afferma che l'IT e il business parlano la stessa lingua nella propria azienda. Il sondaggio LeanIX State of Developer Experience, condotto per la prima volta nel 2022, lo dice chiaramente: un po' di DevOps non è sufficiente - e una maggiore attenzione ad esso può migliorare in modo decisivo lo sviluppo del software.

Il potenziale di DevOps non viene sfruttato nel lavoro quotidiano

I partecipanti allo studio sono stati interrogati sull'uso di cinque metodi di lavoro caratteristici di DevOps, con risultati sconfortanti:

Mentre poco meno del 60% degli intervistati dichiara di poter reagire in modo flessibile alle mutevoli esigenze dei clienti e di disporre di pipeline CI/CD, la flessibilità in vista del cliente e la capacità di automatizzare e testare le modifiche al codice sono fondamentali per le iniziative DevOps. Tuttavia, la flessibilità in funzione del cliente e la capacità di automatizzare e testare le modifiche al codice tramite pipeline CI/CD sono fondamentali per le iniziative DevOps. È quindi notevole che per oltre il 40% delle squadre questo requisito di base sia soddisfatto solo in parte o non sia affatto soddisfatto. Il quadro è ancora peggiore quando si tratta del tipico principio DevOps di "build-ship-own your code", dell'organizzazione dei team basata sulle topologie dei team o della libera scelta dello stack tecnologico. In sintesi: le iniziative DevOps sono espandibili nelle aziende internazionali.

Il livello di maturità DevOps influenza la percezione delle barriere al lavoro

Se analizziamo i cinque metodi di lavoro interrogati, vediamo che la maggior parte dei team di sviluppatori (53%) utilizza solo fino a tre di questi metodi. Questo basso livello di maturità DevOps influisce sulla valutazione degli ostacoli nel lavoro quotidiano. Gli intervistati di questi team li considerano costantemente una sfida maggiore:

Ridurre l'impegno manuale a causa della mancanza di automazione: è in cima alla lista degli ostacoli descritti come una "grande sfida" per tutti gli intervistati. Tuttavia, i team con un livello di maturità DevOps inferiore percepiscono questo aspetto in modo significativamente più forte, con il 41% contro il 25%. Che si tratti di rompere i silos o della difficoltà di concentrarsi sui propri compiti a causa dei frequenti cambiamenti di contesto, che si tratti di scoprire i colli di bottiglia, la sfida di dare priorità ai progetti o di allocare le risorse in modo efficiente: in teoria, i metodi di lavoro agili portano all'eliminazione o alla riduzione significativa di questi ostacoli. Il fatto che la maggior parte degli intervistati descriva questi problemi come impegnativi è un'altra indicazione del fatto che i team DevOps sono ancora in viaggio. È qui che i responsabili possono iniziare a migliorare e accelerare ulteriormente lo sviluppo del software in azienda.

Manca un linguaggio comune tra IT e business.

Le iniziative DevOps di successo richiedono la collaborazione con tutti gli stakeholder dell'azienda - sottolineano gli analisti di Gartner. Si osserva che molte iniziative falliscono anche perché le aspettative ad esse associate non sono chiaramente definite all'interno dell'azienda. Per gestire queste aspettative, l'IT e l'azienda dovrebbero concordare obiettivi e metriche comuni, e quindi un linguaggio comune, chiedono gli esperti.

Tuttavia, è proprio questo linguaggio comune che manca nelle aziende: Solo il 42% degli intervistati in questo studio afferma che l'IT e l'azienda si comprendono a vicenda. Se si guarda a quali metriche vengono registrate ed esaminate più da vicino, la mancanza di una base di comprensione diventa evidente.

Scarsa conoscenza dei vantaggi per i clienti e dell'efficienza dello sviluppo del software

Circa il 70% dei team di sviluppatori guarda a due metriche in relazione al cliente e al proprio lavoro: i ticket di assistenza aperti e gli utenti attivi mensili - metriche facilmente accessibili, che hanno il maggior potenziale di frustrazione e non si riferiscono direttamente al software fornito e al suo valore per il cliente:

Che si tratti dell'adozione di funzionalità, del tasso di abbandono, del ritorno sull'investimento o del Net Promoter Score come espressione della soddisfazione, ognuna di queste metriche è presa in considerazione da meno della metà dei team di sviluppo software. Pertanto, la maggior parte dei team ha una scarsa conoscenza del successo effettivo e del valore per il cliente delle loro specifiche prestazioni lavorative, e non può condividerle con l'azienda.

Anche la possibilità di misurare le prestazioni dello sviluppo del software utilizzando le quattro metriche DORA riconosciute (Deployment Frequency, Failure Rate, Lead Time for Changes, Mean Time to Recovery) non è percepita in modo completo. Un quarto degli intervistati non considera nemmeno una di queste metriche. Tuttavia, una tale misurazione delle prestazioni contribuirebbe anche a creare un linguaggio comune che rende possibile l'apprezzamento reciproco.

Le diverse fonti di dati complicano la panoramica

Le informazioni necessarie per le metriche dei clienti o per le metriche DORA sono spesso distribuite tra diverse fonti. La loro raccolta viene spesso effettuata con grande sforzo manuale e, in quasi il 40% dei casi, anche con fogli di calcolo Excel.

Le moderne piattaforme di gestione del flusso di valore possono aiutare. Ma solo il 20% degli intervistati li utilizza già per collegare i flussi di dati in modo automatizzato e per stabilire un collegamento diretto con i risultati aziendali.

Espandere i metodi di lavoro agili nonostante l'esperienza prevalentemente positiva degli sviluppatori

Nessuna implementazione DevOps completa, ostacoli nel lavoro quotidiano, scarsa conoscenza dei vantaggi diretti per i clienti del software sviluppato: nonostante questa situazione nei team di sviluppatori, la leggera maggioranza degli intervistati valuta in generale l'esperienza degli sviluppatori in modo piuttosto positivo:

Ciò che sembra positivo in un primo momento, tuttavia, a uno sguardo più attento emerge anche che quasi la metà degli intervistati non riesce a esprimere una valutazione positiva. A fronte della massiccia carenza di lavoratori qualificati nel settore IT e della crescente importanza del software come elemento di differenziazione sul mercato, le aziende dovrebbero fare tutto il possibile per trattenere i propri team di sviluppo software.

(Visitato 195 volte, 1 visita oggi)

Altri articoli sull'argomento