Misurare la produttività degli sviluppatori

Misurare la produttività degli sviluppatori

Misurare, tracciare e confrontare la produttività degli sviluppatori è da tempo considerato una scatola nera. Non deve essere per forza così.

Rispetto ad altre funzioni aziendali critiche come le vendite o le operazioni con i clienti, lo sviluppo software è perennemente sottostimato. La convinzione radicata da molti nel settore tecnologico è che non sia possibile farlo correttamente e che, in ogni caso, solo gli ingegneri qualificati siano sufficientemente competenti per valutare le prestazioni dei loro pari. Tuttavia, questo status quo non è più sostenibile. Ora che la maggior parte delle aziende sta diventando (in un modo o nell’altro) aziende di software, indipendentemente dal settore, i leader devono sapere che stanno impiegando il loro talento più prezioso nel modo più efficace possibile.
Non si può negare che misurare la produttività degli sviluppatori sia difficile. Altre funzioni possono essere misurate abbastanza bene, alcune anche con una sola metrica; mentre nello sviluppo software, il collegamento tra input e output è considerevolmente meno chiaro. Lo sviluppo software è anche un lavoro altamente collaborativo, complesso e creativo e richiede metriche diverse per livelli diversi (come sistemi, team e individui). Inoltre, anche se c’è un impegno genuino per Misurare la produttività degli sviluppatori, le metriche tradizionali possono richiedere sistemi e software impostati per consentire una misurazione più sfumata e completa. Per alcune metriche standard, interi stack tecnologici e pipeline di sviluppo devono essere riconfigurati per consentire il monitoraggio e l’implementazione degli strumenti e dei tool necessari per ottenere informazioni significative può richiedere investimenti significativi a lungo termine. Inoltre, il panorama dello sviluppo software sta cambiando rapidamente poiché strumenti di intelligenza artificiale generativa come Copilot X e ChatGPT hanno il potenziale per consentire agli sviluppatori di completare le attività fino a due volte più velocemente .

Per aiutare a superare queste sfide e rendere questo compito critico più fattibile, la società internazionale di consulenza Mckinsey e Company, ha sviluppato un approccio alla misurazione della produttività degli sviluppatori software che è più facile da implementare con sondaggi o dati esistenti (come negli strumenti di gestione del backlog). Così facendo, hanno costruito sulla base di metriche di produttività esistenti che i leader del settore hanno sviluppato nel corso degli anni, con un occhio di riguardo per rivelare opportunità di miglioramento delle prestazioni.

Questo nuovo approccio è stato implementato in circa 20 aziende tecnologiche, finanziarie e farmaceutiche, e i risultati iniziali sono promettenti. Includono i seguenti miglioramenti:

• Riduzione dal 20 al 30 percento dei difetti dei prodotti segnalati dai clienti
• Miglioramento del 20 percento nei punteggi dell’esperienza dei dipendenti
• Miglioramento di 60 punti percentuali nei punteggi di soddisfazione dei clienti

Sfruttare le informazioni sulla produttività
Grazie all’accesso a dati e approfondimenti più approfonditi sulla produttività, i leader possono iniziare a rispondere a domande urgenti sui talenti dell’ingegneria del software che hanno lottato così duramente per attrarre e trattenere, come le seguenti:

• Quali sono gli ostacoli che impediscono agli ingegneri di lavorare al meglio?
• Quanto incidono la cultura e l’organizzazione sulla loro capacità di produrre il miglior lavoro possibile?
• Come facciamo a sapere se stiamo utilizzando il loro tempo in attività che generano davvero valore?
• Come possiamo sapere se disponiamo di tutti i talenti ingegneristici del software di cui abbiamo bisogno?

Comprendere le basi – Misurare la produttività degli sviluppatori
Per utilizzare un sistema sufficientemente sofisticato per misurare la produttività degli sviluppatori, è essenziale comprendere i tre tipi di metriche che devono essere monitorate: quelle a livello di sistema, a livello di team e a livello individuale. A differenza di un processo come le vendite, in cui una metrica a livello di sistema di euro guadagnati o accordi chiusi potrebbe essere utilizzata per misurare il lavoro sia dei team che degli individui, lo sviluppo software è collaborativo in un modo distintivo che richiede punti di vista differenti. Ad esempio, mentre la frequenza dei rilasci è una metrica perfettamente valida per valutare sistemi o team, dipende da tutti i membri del team che svolgono i rispettivi compiti e, pertanto, non è un modo utile per monitorare le prestazioni individuali.
Un’altra dimensione critica da riconoscere è cosa ti dicono e cosa non ti dicono le varie metriche. Ad esempio, misurare la frequenza di rilascio o il “lead time” per le modifiche può dare una visione chiara di determinati risultati, ma non se un’organizzazione di ingegneria è ottimizzata. E mentre metriche come story point completati o interruzioni possono aiutare a determinare l’ottimizzazione, richiedono ulteriori indagini per identificare i miglioramenti che potrebbero essere utili.

Nel creare il set di metriche, Mckinsey ha cercato di espandere i due set di metriche già sviluppati dal settore del software. Il primo è DORA, chiamato così per il team di ricerca e valutazione DevOps di Google. Sono le più vicine a uno standard che il settore tecnologico ha e sono ottime per misurare i risultati. Quando una metrica DORA restituisce un risultato mediocre, è un segnale per indagare su cosa è andato storto, il che può spesso comportare un’indagine prolungata. Ad esempio, se una metrica come la frequenza di distribuzione aumenta o diminuisce, le cause possono essere molteplici. Determinare quali sono e come risolverle spesso non è semplice.
l secondo set di misurazioni sviluppate dal settore sono le metriche SPACE (soddisfazione e benessere, performance, attività, comunicazione e collaborazione, efficienza e flusso), che GitHub e Microsoft Research hanno sviluppato per aumentare le metriche DORA. Adottando uno sguardo individuale, in particolare per quanto riguarda il benessere degli sviluppatori, le metriche SPACE sono ottime per chiarire se un’organizzazione di ingegneria è ottimizzata. Ad esempio, un aumento delle interruzioni che gli sviluppatori sperimentano indica la necessità di ottimizzazione.

Oltre a queste metriche già potenti, l’ approccio di Mckinsey cerca di identificare cosa si può fare per migliorare il modo in cui i prodotti vengono consegnati e quanto valgono tali miglioramenti, senza la necessità di una strumentazione pesante. L’integrazione delle metriche DORA e SPACE con metriche incentrate sulle opportunità può creare una visione end-to-end della produttività degli sviluppatori software (Figura sotto).

Questi parametri di produttività incentrati sulle opportunità utilizzano diversi punti di vista per generare una visione specifica della complessa gamma di attività coinvolte nello sviluppo di prodotti software.

Tempo impiegato nel ciclo interno/esterno.

Per identificare aree specifiche di miglioramento, è utile pensare alle attività coinvolte nello sviluppo software come organizzate in due cicli (Figura sotto).

Un ciclo interno comprende attività direttamente correlate alla creazione del prodotto: codifica, creazione e test unitari. Un ciclo esterno comprende altre attività che gli sviluppatori devono svolgere per spingere il loro codice in produzione: integrazione, test di integrazione, rilascio e distribuzione. Sia dal punto di vista della produttività che dell’esperienza personale, è auspicabile massimizzare la quantità di tempo che gli sviluppatori trascorrono nel ciclo interno: la creazione di prodotti genera direttamente valore ed è ciò che la maggior parte degli sviluppatori è entusiasta di fare. Le attività del ciclo esterno sono considerate dalla maggior parte degli sviluppatori come compiti necessari ma generalmente insoddisfacenti. Investire tempo in migliori strumenti e automazione per il ciclo esterno consente agli sviluppatori di dedicare più tempo alle attività del ciclo interno.

Le principali aziende tecnologiche puntano a far sì che gli sviluppatori trascorrano fino al 70 percento del loro tempo in attività di inner-loop. Ad esempio, un’azienda che aveva precedentemente completato una trasformazione agile di successo ha scoperto che i suoi sviluppatori, invece di scrivere codice, stavano dedicando troppo tempo a compiti a basso valore aggiunto come il provisioning dell’infrastruttura, l’esecuzione di unit test manuali e la gestione dei dati di test. Partendo da questa intuizione, ha lanciato una serie di nuovi strumenti e progetti di automazione per aiutare con quei compiti durante il ciclo di vita dello sviluppo del software.

Benchmark Developer Velocity Index.

Il Developer Velocity Index (DVI) è un sondaggio che misura la tecnologia, le pratiche di lavoro e l’abilitazione organizzativa di un’azienda e le confronta con i pari. Questo confronto aiuta a scoprire aree specifiche di opportunità, sia nella gestione del backlog, nei test o nella sicurezza e nella conformità. Ad esempio, un’azienda, nota per la sua competenza tecnologica e per i suoi sviluppatori di prim’ordine, ha cercato di definire in modo più attento le pratiche di lavoro standard per la collaborazione tra team dopo aver scoperto un elevato livello di insoddisfazione, rielaborazione e inefficienza segnalati dagli sviluppatori.

Analisi del contributo.

Valutare i contributi dei singoli al backlog di un team (iniziando con i dati provenienti da strumenti di gestione del backlog come Jira e normalizzando i dati utilizzando un algoritmo proprietario per tenere conto delle sfumature) può aiutare a far emergere le tendenze che inibiscono l’ottimizzazione della capacità di quel team. Questo tipo di intuizione può consentire ai team leader di gestire aspettative chiare per l’output e migliorare le prestazioni di conseguenza. Inoltre, può aiutare a identificare opportunità di aggiornamento o formazione individuale e ripensare la distribuzione dei ruoli all’interno di un team (ad esempio, se un tester di garanzia della qualità ha abbastanza lavoro da fare). Ad esempio, un’azienda ha scoperto che i suoi sviluppatori più talentuosi dedicavano troppo tempo ad attività non di codifica come sessioni di progettazione o gestione delle interdipendenze tra i team. In risposta, l’azienda ha cambiato il suo modello operativo e ha chiarito ruoli e responsabilità per consentire a quegli sviluppatori di valore più elevato di fare ciò che sanno fare meglio: codificare. Un’altra azienda, dopo aver scoperto un contributo relativamente basso da parte degli sviluppatori nuovi nell’organizzazione, ha riesaminato il suo programma di onboarding e tutoraggio personale.

Punteggio di capacità del talento.

Basato sulle mappe di capacità standard del settore, questo punteggio è un riepilogo delle conoscenze, delle competenze e delle abilità individuali di un’organizzazione specifica. Idealmente, le organizzazioni dovrebbero aspirare a una distribuzione “a diamante” della competenza, con la maggior parte degli sviluppatori nella fascia media di competenza. Ciò può far emergere opportunità di coaching e di aggiornamento delle competenze e, in casi estremi, richiedere una riconsiderazione della strategia dei talenti. Ad esempio, un’azienda ha riscontrato una maggiore concentrazione dei propri sviluppatori nella capacità “principiante” rispetto all’ideale. Hanno implementato percorsi di apprendimento personalizzati basati su lacune specifiche e sono stati in grado di far passare il 30 percento dei propri sviluppatori al livello successivo di competenza entro sei mesi.

Evitare errori nelle metriche
Per quanto preziosi possano essere, i dati sulla produttività degli sviluppatori possono danneggiare le organizzazioni se usati in modo scorretto, quindi è importante evitare certe insidie. Nel lavorodi sviluppatori vediamo verificarsi due tipi principali di passi falsi: uso improprio delle metriche e incapacità di andare oltre le vecchie mentalità.

L’uso improprio è più comune quando le aziende cercano di impiegare misure eccessivamente semplici, come le linee di codice prodotte o il numero di commit di codice (quando gli sviluppatori inviano il loro codice a un sistema di controllo delle versioni). Non solo queste metriche semplici non riescono a generare informazioni veramente utili, ma possono avere conseguenze indesiderate, come i leader che fanno compromessi inappropriati. Ad esempio, l’ottimizzazione per il lead time o la frequenza di distribuzione può far soffrire la qualità. Concentrarsi su una singola metrica o su una raccolta di metriche troppo semplice può anche incentivare facilmente cattive pratiche; nel caso della misurazione dei commit, ad esempio, gli sviluppatori possono inviare modifiche più piccole più frequentemente mentre cercano di ingannare il sistema.

Per trarre davvero vantaggio dalla misurazione della produttività, sia i leader che gli sviluppatori devono andare oltre la vecchia idea che i leader “non possono” comprendere le complessità dell’ingegneria del software o che l’ingegneria è troppo complessa da misurare. L’importanza del talento ingegneristico per il successo di un’azienda e la forte competizione per i talenti degli sviluppatori negli ultimi anni sottolineano la necessità di riconoscere che lo sviluppo del software, come tante altre cose, richiede una misurazione migliorata. Inoltre, attrarre e trattenere i migliori talenti nello sviluppo del software dipende in gran parte dalla fornitura di un ambiente di lavoro e di strumenti che consentano agli ingegneri di svolgere al meglio il loro lavoro e incoraggino la loro creatività. La misurazione della produttività a livello di sistema consente ai datori di lavoro di vedere i punti di attrito nascosti che impediscono quel lavoro e quella creatività.

Iniziare
La meccanica di creazione di un’iniziativa di produttività per sviluppatori può sembrare scoraggiante, ma non c’è momento migliore del presente per iniziare a gettare le basi. I fattori che spingono la necessità di elevare il dibattito sulla produttività degli sviluppatori software ai leader di livello C superano gli impedimenti a farlo.

L’aumento del lavoro da remoto e la sua popolarità tra gli sviluppatori sono un fattore determinante. Gli sviluppatori hanno lavorato a lungo in team agili, collaborando nello stesso spazio fisico, e alcuni leader della tecnologia ritengono che questo tipo di lavoro di squadra di persona sia essenziale per il lavoro. Tuttavia, gli strumenti digitali che sono così centrali per il loro lavoro hanno reso facile il passaggio al lavoro da remoto durante i blocchi della pandemia e, come nella maggior parte dei settori, questo cambiamento è difficile da annullare. Man mano che il lavoro da remoto e ibrido diventa sempre più la norma, le organizzazioni dovranno fare affidamento su misurazioni ampie e oggettive per mantenere la fiducia in queste nuove modalità di lavoro e garantire che migliorino costantemente la funzione che potrebbe facilmente determinare il loro successo o fallimento futuro. Il fatto che i mercati stiano ora ponendo maggiore enfasi sulla crescita efficiente e sul ROI rende solo più importante che mai sapere come possono ottimizzare le prestazioni del loro talento ingegneristico altamente apprezzato.

Un altro fattore chiave di questa necessità di maggiore visibilità è il rapido progresso negli strumenti abilitati dall’intelligenza artificiale, in particolare nei modelli di linguaggio di grandi dimensioni come l’intelligenza artificiale generativa. Questi stanno già rapidamente cambiando il modo in cui si lavora, il che significa che misurare la produttività degli sviluppatori di software è solo un primo passo per comprendere come vengono distribuite queste preziose risorse.

Ma per quanto critica stia diventando la produttività degli sviluppatori, le aziende non dovrebbero sentirsi costrette a imbarcarsi in una revisione massiccia e radicale quasi da un giorno all’altro. Invece, possono iniziare il processo con una serie di passaggi chiave:

Imparare le basi. Tutti i leader C-suite che non sono ingegneri o che sono stati a lungo nella gestione avranno bisogno di un primer sul processo di sviluppo software e su come si sta evolvendo.

Valutare i propri sistemi. Poiché la produttività degli sviluppatori non è stata in genere misurata al livello necessario per identificare opportunità di miglioramento, gli stack tecnologici della maggior parte delle aziende richiederanno una riconfigurazione potenzialmente estesa. Ad esempio, per misurare la copertura dei test (la misura in cui le aree del codice sono state adeguatamente testate), un team di sviluppo deve dotare la propria base di codice di uno strumento in grado di tracciare il codice eseguito durante un’esecuzione di test.

Creare un piano. Come per la maggior parte delle iniziative di analisi, perdersi in montagne di dati è un rischio. È importante iniziare con un’area che sai che porterà a un chiaro percorso di miglioramento, come l’identificazione di punti di attrito e colli di bottiglia. Sii esplicito riguardo all’ambito di tale piano, poiché anche gli approcci migliori, non importa quanto completi, non saranno una panacea.

Ricordare che la misurazione della produttività è contestuale. Il punto è guardare un intero sistema e capire come può funzionare meglio migliorando l’ambiente di sviluppo a livello di sistema, team o individuo.

Indipendentemente dall’approccio specifico, la misurazione della produttività dovrebbe idealmente creare trasparenza e approfondimenti sulle aree di miglioramento chiave. Solo allora le organizzazioni possono creare iniziative specifiche per guidare l’impatto sia sulla produttività che sull’esperienza degli sviluppatori, impatto che andrà a vantaggio sia di quegli individui che dell’azienda nel suo complesso.

(fonte)

Innovaformazione, scuola informatica specialistica promuove la cultura consapevole nello sviluppo software. Trovate l’elenco corsi dell’offerta formativa per le aziende sul nostro sito QUI.

Per altri articoli sul mondo IT invitiamo a navigare sul nostro blog QUI.

INFO: info@innovaformazione.net / Tel. 3471012275 (Dario Carrassi)