Anche se le abilità pratiche e la conoscenza di specifici linguaggi di programmazione, strumenti e tecnologie sono la chiave per ottenere un lavoro a tempo pieno come sviluppatore di software, c'è un altro indicatore prezioso che per molti versi può essere visto come un presupposto per il successo in questa professione: produttività. La misurazione della produttività è qualcosa che tutti gli sviluppatori di software professionisti devono comprendere e tenere in considerazione poiché le metriche delle prestazioni sono intrinsecamente importanti per qualsiasi team di sviluppo software nell'ambiente aziendale di oggi.
Perché la tua produttività come sviluppatore è importante?
Nell'era dello sviluppo Agile, DevOps e della riduzione dei cicli di rilascio del software, quando gli sviluppatori devono distribuire nuove versioni dei prodotti il più rapidamente possibile, le aziende utilizzano più metriche di produttività diverse per valutare le prestazioni dei singoli programmatori e di un team nel suo insieme. Guardando questo dal punto di vista di uno sviluppatore, la misurazione delle prestazioni può servire a una serie di scopi preziosi, aiutandoti a monitorare i progressi delle tue capacità di programmazione, il che ti consentirebbe di ottenere una crescita professionale costante. I programmatori altamente produttivi sono quelli che finiscono per ricevere offerte di stipendio sbalorditive e si mettono al lavoro sui progetti più entusiasmanti. Ma anche se non sei esattamente un grande successo e desideri solo un lavoro nello sviluppo di software e avere un discreto successo in esso, devi comunque avere almeno una conoscenza di base degli indicatori di prestazione e di come vengono utilizzati per misurare la produttività del tuo contributo sul lavoro. Che è ciò di cui parleremo oggi.
Metriche di misurazione della produttività dello sviluppo software
Quali sono le metriche di produttività dello sviluppo software?
Le metriche di sviluppo del software sono le aree del lavoro di programmazione in cui è possibile applicare misurazioni quantitative per monitorare le prestazioni, la qualità del lavoro e la produttività di uno sviluppatore. Ogni parametro di produttività si basa sull'acquisizione di dati dal processo di sviluppo e sul loro utilizzo per misurare la produttività. Poiché praticamente nulla relativo allo sviluppo del software è facile e diretto, si potrebbe dire che anche la misurazione della produttività della programmazione è piuttosto incoerente e frammentata in tutto il settore. Oppure, in poche parole, vari team e aziende possono utilizzare indicatori di prestazione completamente diversi e affrontare questo problema da diverse angolazioni. Quindi non è necessario preoccuparsi di apprendere ogni singola metrica che può essere utilizzata dai team di sviluppo software.
Quali tipi di metriche di produttività dello sviluppo software esistono?
Naturalmente, esistono diverse metriche di produttività che si avvicinano alla misurazione delle prestazioni su vari livelli e angolazioni. Ecco i tipi più comuni di tali metriche di produttività:
Metriche formali incentrate sulle dimensioni.
Queste metriche sono incentrate sulla misurazione delle dimensioni del risultato del lavoro di un programmatore, come righe di codice (LOC), lunghezza delle istruzioni del codice, complessità del codice, ecc. Queste metriche sono sempre più considerate obsolete nell'industria odierna dello sviluppo software.
Metriche di produttività incentrate sul tempo e sulla funzione.
Esiste una selezione di metriche di produttività tradizionali utilizzate nello sviluppo di software a cascata, come i giorni attivi, l'ambito della funzionalità fornita in un determinato periodo di tempo, i tassi di abbandono del codice, il numero di attività assegnate, ecc.
Metriche del processo di sviluppo agile.
Le metriche del processo di sviluppo agile, come il rapporto di burndown dello sprint, la velocità, il tempo di consegna, il tempo di ciclo e altri, sono probabilmente le metriche più comunemente utilizzate dai team di sviluppo software oggi. Parleremo delle metriche Agile in modo più dettagliato più avanti nell'articolo.
Metriche di analisi operativa.
Questo insieme di metriche è incentrato sulla misurazione delle prestazioni del software nel suo attuale ambiente di produzione. Il tempo medio tra i guasti (MTBF), il tempo medio di ripristino (MTTR) e il tasso di arresti anomali dell'applicazione sono le metriche più utilizzate qui.
Metriche di test.
Il test del software ha il proprio set di metriche per misurare la qualità del test del sistema, come la percentuale di test automatizzati, la copertura del codice, ecc.
Metriche di soddisfazione del cliente.
Infine, la metrica definitiva per qualsiasi software è l'esperienza del cliente finale, e anche per questo esiste un intero set di metriche, come il punteggio di sforzo del cliente (CES), il punteggio di soddisfazione del cliente (CSAT), il punteggio netto del promotore (NPS) e altri.
Metriche di sviluppo del software Agile
Come puoi vedere, è abbastanza facile perdersi in tutte le complessità delle metriche di produttività del software. Gli unici con cui un normale sviluppatore di software dovrebbe avere familiarità, tuttavia, sono le metriche Agile, comunemente utilizzate dai team di sviluppo software oggi come standard di misurazione della produttività del team in diverse parti del ciclo di vita dello sviluppo del software. Elenchiamo le metriche Agile principali e più comunemente utilizzate.
1. Burndown dello sprint.
I report Sprint Burndown sono una delle metriche chiave per i team di sviluppo Agile Scrum. Poiché in Agile il processo di sviluppo è organizzato attraverso sprint limitati nel tempo, Sprint Burndown viene utilizzato come un modo per tenere traccia del completamento delle attività durante uno sprint. Le ore o i punti della storia sono usati come unità di misura. L'obiettivo è raggiungere progressi coerenti e fornire un lavoro in linea con le proiezioni iniziali. Sprint Burndown aiuta i team a misurare il ritmo di lavoro e ad adeguarlo quando necessario.
2. Velocità di squadra.
La velocità è un altro indicatore chiave, anch'esso basato sulle ore o sui punti della storia come unità di misura. Misura la quantità media di lavoro che un team completa durante uno sprint e viene utilizzato per la stima e la pianificazione durante tutto il progetto. Il monitoraggio della velocità è importante per assicurarsi che il team offra prestazioni costanti.
3. Punti della storia.
A livello di un singolo membro del team di sviluppo, i punti della storia sono una metrica preziosa, poiché la dimensione delle storie che un programmatore fornisce durante ogni rilascio è un indicatore della produttività di questo programmatore.
4. Grafico di controllo del ciclo.
Misura il tempo totale dal momento in cui il lavoro su un'attività o su un altro elemento del backlog è iniziato fino al suo completamento. Consente di tracciare e controllare i tempi di ciclo fornendo risultati più prevedibili.
5. Throughput e valore fornito.
I project manager analizzano le attività assegnate agli sviluppatori e assegnano loro un valore. Questa metrica viene quindi utilizzata per misurare il rendimento del team o, in altre parole, la quantità di lavoro a valore aggiunto svolto.
6. Modifica del codice.
Il code churn è un'altra metrica che vale la pena menzionare in quanto viene utilizzata sia per misurare la produttività di un team nel suo insieme sia per monitorare le prestazioni dei singoli programmatori. Il code churn misura la frequenza con cui uno sviluppatore rimuove o apporta modifiche a righe di codice aggiunte in precedenza e quale percentuale di codice scritto in precedenza finisce per essere modificata o eliminata.
Opinioni di esperti
Infine, per aggiungere un po' di prospettiva, alcune citazioni sull'argomento da parte di esperti professionisti del settore dello sviluppo software. “Spero che tu non stia cercando di "confrontare" le tue metriche con qualche tipo di standard o anche con le prestazioni di un altro team in un'altra azienda. Ovunque ho lavorato ha avuto variazioni uniche nelle loro definizioni di punti della storia, velocità, stime orarie, compiti, ecc. che renderebbero davvero quasi impossibile confrontare le prestazioni di un team di una società direttamente con quelle di un altro team in un altro azienda", ha osservato Cliff Gilley, ex Technical Product Manager e Agile Coach. “Sono un po' diffidente nei confronti delle metriche quando si tratta di guidare le prestazioni del team. Una volta che presti attenzione solo a una o due variabili, diventa molto facile cadere (intenzionalmente o meno) nel gioco della metrica e illuderti che stai migliorando, quando tutto ciò che stai facendo è migliorare la metrica. Ad esempio, le metriche basate sulla velocità possono "migliorare" se il team passa a storie più piccole (meno lavoro per storia, quindi più storie completate, quindi la velocità aumenta). Potrebbe essere una buona cosa se le storie sono storie utente utili che forniscono incrementi minori di valore aziendale. Potrebbe essere una brutta cosa se le storie diventano compiti più piccoli e più "tecnici" che non offrono un valore reale da soli ", ha affermato Adrian Howard, un altro professionista del settore. “Quando lavoro in un sistema basato su pull, apprezzo la produttività e il tempo di ciclo. Il primo mi fornisce informazioni generali sulla capacità del nostro team e nel tempo può diventare una misura predittiva molto potente. Il secondo è utile come indicatore generale dell'efficienza dei nostri gasdotti. Se il tempo di ciclo è elevato, è il momento di iniziare a esaminare la pipeline, perché c'è un vincolo che probabilmente possiamo lavorare per facilitare/sfruttare. Ma le metriche sono solo strumenti. Non perderti in essi e certamente non iniziare a pianificare verso una metrica specifica. Pensa a cosa stai facendo come squadra e a come lavori in modo naturale, quindi costruisci il sistema attorno alle persone. Le metriche dovrebbero aiutarti a vedere come il tuo sistema supporta il lavoro di tutti. Oppure no", ha concluso Dave Cerra, produttore di sviluppo di videogiochi .
