Notizia

May 22, 2023

Perché gli sviluppatori di software preferiscono le metriche DORA

Di Dylan Etkin, InfoWorld | Tecnologia emergente analizzata dagli esperti di tecnologia Per anni, i team di ingegneria del software hanno cercato un modo per misurare la propria efficienza con parametri concreti che li aiutassero veramente

Di Dylan Etkin, InfoWorld |

Tecnologia emergente sezionata dai tecnologi

Per anni, i team di ingegneria del software hanno cercato un modo per misurare la propria efficienza con parametri concreti che li aiutassero davvero a migliorare, senza far sentire gli sviluppatori spiati. Finalmente stiamo arrivando da qualche parte.

Qualsiasi sviluppatore conosce il dolore, o il potenziale dolore, di essere misurato rispetto a parametri dubbi come righe di codice scritte o numero di richieste pull unite, per cui il nostro settore è storicamente noto. E qualsiasi responsabile tecnico conosce il contraccolpo e la sfiducia che tali misure possono instillare nel proprio team.

Ma quando i consigli di amministrazione, i responsabili tecnici e gli sviluppatori vogliono tutti sapere se un processo funziona, se il team è efficiente e come migliorarsi, abbiamo bisogno di un modo per misurare il lavoro svolto.

Per raggiungere questo obiettivo sono sorti diversi set di parametri, strutture e migliori pratiche. Inevitabilmente, alcuni lo fanno meglio di altri. Il Santo Graal è misurare il lavoro con gli strumenti e i sistemi con cui gli sviluppatori già lavorano quotidianamente. Le metriche DORA possono farlo, ed è in parte il motivo per cui stanno diventando lo standard del settore.

Approfondiremo ulteriormente l'argomento, ma prima comprendiamo gli altri tipi di metriche disponibili.

Si può pensare che le metriche di attività misurino la quantità di tempo di flusso a disposizione di uno sviluppatore. Se il tuo flusso viene interrotto due o tre volte al giorno, sai che è quasi impossibile portare a termine le cose.

Nel tentativo di tutelare il tempo degli sviluppatori, è stata sviluppata un'intera categoria di strumenti per l'efficienza ingegneristica che si collegano ai sistemi e ai calendari delle risorse umane. Cercano di valutare se uno sviluppatore ha troppi cambi di contesto, riunioni e processi che richiedono tempo da seguire.

In definitiva, questi parametri cercano di prevenire il burnout guardando il lato umano della codifica, che certamente conta, ma questi parametri non sono molto utilizzabili.

Se sai che gli sviluppatori partecipano a troppe riunioni, come strutturare un ambiente in cui si svolgono le riunioni necessarie ma il flusso è anche più efficiente? Le metriche sull'attività non includono una serie di potenziali miglioramenti per guidarti.

Nicole Forsgren, una delle fondatrici di DORA (DevOps Research Assessment), ha sviluppato questo framework, che mira a comprendere la produttività degli sviluppatori. Ma piuttosto che su parametri concreti, il framework SPACE si concentra sullo stato d'animo e sul benessere fisico degli sviluppatori, che sono senza dubbio fattori importanti per il godimento generale del loro lavoro da parte degli sviluppatori e per le prestazioni ingegneristiche di un team.

Il framework SPACE misura cinque dimensioni della produttività degli sviluppatori:

Come le metriche di attività, il framework SPACE acquisisce informazioni valide, ma è difficile agire in base. Considerateli principalmente come migliori pratiche difficili da misurare in base al lavoro svolto. Manca la concisione e i risultati orientati agli obiettivi.

Queste sono le misure difficili che sono facili da ingannare e che non catturano il reale impegno dello sviluppatore: cose come righe di codice scritte, numero di richieste pull unite, numero di ore trascorse a scrivere codice. Queste misure risalgono ai tempi della programmazione con schede perforate, dove il leader era lo sviluppatore che eseguiva il compito con il minor numero di istruzioni.

Ma gli sviluppatori sanno che in realtà non misurano nulla di importante. Posso scrivere le cinque righe di codice più importanti nell'applicazione che sono così complesse che mi occorrerebbero due settimane per assicurarmi che siano le cinque righe di codice corrette. Oppure potrei scrivere cinque milioni di righe di codice che non sono molto utili. È lo stesso con la misurazione del numero di richieste pull unite. Questo può dirti qualcosa sulla dimensione complessiva del batch, ma non è incredibilmente intuitivo o utile per aiutare un team a migliorare.

Se giudichi gli sviluppatori rispetto a queste misure, sapranno che non capisci loro o il loro lavoro. Inoltre, misurare queste cose su scala individuale è tossico. Gli sviluppatori si sentiranno spiati e giudicati e punteranno sui talloni.