Benchmarking del software

Benchmark software per la prevedibilità del progetto

Vuoi confrontare come te la cavi con gli altri, internamente o con i team di altre organizzazioni. Per i confronti tra team interni puoi stabilire i tuoi benchmark interni, mentre per il confronto con altri team nel settore del software, cercherai benchmark del software del settore. Questo articolo si concentra su benchmarking appropriato del lavoro del software in modo da poter confrontare le prestazioni delle tue squadre con quelle di altre. 

N.B. Questo articolo non riguarda il benchmarking delle prestazioni (velocità) del software.

Il Software Benchmarking può aiutare le organizzazioni a capire quanto stanno andando bene e dove potrebbero cercare di migliorare. Anche con i benchmark, i manager possono rispondere alle domande vitali su un progetto software "Quanto tempo ci vorrà?" E "Quanto costerà?"   I benchmark possono essere utilizzati anche per prendere preziose decisioni aziendali su quale software lavorare su cui concentrarsi.

Sfondo

Il software sta diventando un elemento chiave di differenziazione tra le aziende di successo e quelle di insuccesso nella maggior parte dei settori. La capacità di produrre funzionalità software innovative e differenzianti di alta qualità più velocemente rispetto alla concorrenza è una chiave per un'azienda che batte i suoi concorrenti. Alla fine potrebbe diventare un fattore determinante nella sopravvivenza aziendale, come lo è già per le aziende basate sulla tecnologia.

Conoscere le prestazioni della propria azienda rispetto alle altre nella capacità di fornire funzionalità software sta diventando sempre più importante. È qui che entra in gioco il benchmarking.

Benchmarking della produttività degli sviluppatori

Il focus tende a essere su produttività degli sviluppatori, anzi per tre motivi:

1. Variabile. La produttività degli sviluppatori varia in modo significativo: i più qualificati sono 100 volte più produttivi dei meno esperti.
2. Significativo. Il costo dello sviluppatore è solitamente la componente di costo più importante nella fornitura del software.
3. Prezioso. Le aziende dipendono dalla fornitura di software per rimanere competitive, quindi la velocità con cui può essere consegnato è importante per un'organizzazione.

La misura di base dell'output è la dimensione funzionale, ma non ignorare la qualità.

La misura di base più utile della produzione è la quantità di funzionalità riconoscibili dall'utente che può essere fornito ad alta qualità da uno sviluppatore o da un team di sviluppo. Il modo migliore per determinarlo non è contare le righe di codice, ma piuttosto la dimensione funzionale del software consegnato. La dimensione funzionale viene misurata utilizzando lo standard ISO COSMIC Function Point (CFP). La CFP è la misura standard più moderna e universale per la dimensione del software. È una misura indipendente dalla tecnologia delle dimensioni riconoscibili dall'utente. La produttività degli sviluppatori e dei team di sviluppo può essere confrontata in CFP medio al mese o CFP medio per sprint.

Benchmark sulla produttività degli sviluppatori

Ogni sviluppatore o team può essere confrontato CFP per sprint.

Avvertimento: Le metriche di produttività devono richiedere che la qualità sia verificata.

Sono valori osservati dall'autore in decine di progetti di modeste dimensioni (250-1500 CFP). Dovresti stabilire e mantenere i tuoi parametri di riferimento. Spesso sono espressi anche come il contrario, ovvero la CFP erogata per unità di tempo. Per esempio. 20 CFP al mese.

Regola del pollice: 10-20 CFP per sviluppatore al mese è una regola generale. L'intervallo di produttività osservato per gli sviluppatori è compreso tra 2 e 200 CFP per sviluppatore al mese, a seconda delle circostanze, del dominio, degli strumenti e delle competenze.

Benchmark sulla produttività del team

Una guida generale è che in un team di sette, 4 sviluppatori, 2 tester e un analista aziendale, produrranno in media a una velocità di 4 ore per CFP, ovvero. 80 CFP per sprint di 2 settimane. Questo può essere ridotto se c'è un riporto di bug da correggere dagli sprint precedenti.

Regola del pollice: 70 CFP per sprint è una prima stima ragionevole, ma dovresti stabilire i tuoi parametri di riferimento.

La maggior parte dei manager desidera sapere come si confrontano il proprio team e la propria azienda con gli altri su:

• Produttività dello sviluppo software
• Qualità del software
• Spesa per il software
• Software con buon rapporto qualità-prezzo

Il benchmarking del software interno mette a confronto diversi team o progetti all'interno di un'organizzazione. Il benchmarking del software esterno o di settore confronta queste caratteristiche con le norme esterne.

Questo articolo esplora quali metriche del software possono essere sottoposte a benchmark e quali metriche utilizzare per non stimolare conseguenze indesiderate.

I valori di riferimento effettivi presentati sono solo indicativi e non devono essere considerati parametri di riferimento definitivi. In tutti i casi i benchmark interni sono i migliori, compilati dal lavoro precedente all'interno della vostra organizzazione.

L'intelligenza artificiale non è stata utilizzata per scrivere questo post.

Benchmark delle risorse software

Per la pianificazione del team, i leader devono sapere qual è il quantità ideale di lavoro che qualcuno può gestire. Il software è lavoro di conoscenza e i vincoli cognitivi degli sviluppatori sono tali che possono ragionevolmente gestire solo una certa quantità di funzionalità. Le nostre osservazioni indicano che si tratta di circa 150 CFP. Ciò significa che, indipendentemente dalle dimensioni del tuo progetto, probabilmente avrai bisogno di più di uno sviluppatore se il tuo ambito totale è superiore a 180 CFP. La tabella seguente fornisce linee guida per la capacità tipica in base al ruolo.

Ad esempio, un progetto da 1000 CFP avrà bisogno di 1 Project Manager, 2 Analisti aziendali, 3 tester e 5 sviluppatori. Questi numeri dipendono dalla competenza e dalla conoscenza del settore delle persone coinvolte. Ove possibile, è meglio puntare su team più piccoli composti da individui altamente competenti.

Tieni presente che per i lavori di manutenzione del software un singolo sviluppatore può solitamente gestire più di 180 CFP. Di solito richiede 1 sviluppatore a tempo pieno per 1500-2500 CFP per la manutenzione.

Benchmark di qualità del software

La qualità del software è una questione di vantaggio commerciale. L'organizzazione che fornisce costantemente software di qualità utile ai clienti probabilmente supererà i suoi rivali. Il benchmarking dei parametri di qualità del software diventa quindi un importante comparatore aziendale.

Potenziali difetti

È possibile prevedere il numero di difetti in un pezzo di software. I difetti possono essere previsti in base alle dimensioni del software. È ovvio che un software più grande ha il potenziale per essere più difettoso di un software piccolo. IL potenziale di difetto è il concetto del numero di difetti che potrebbero essere presenti in una parte di software prima di avviare qualsiasi misura di rilevamento/evitamento/rimozione dei difetti.

I tipici potenziali di difetto sono 4-5 difetti per CFP. Questi difetti varieranno in gravità e nella loro origine. Tipicamente come segue:

Fonte: Capers Jones, L'economia della qualità del software, 2011.

Ciò significa che è probabile che vi siano 5 difetti per CFP a meno che non vengano eseguite misure di miglioramento della qualità per individuare e correggere i difetti in ciascuna di queste aree.

La consapevolezza del potenziale difetto aiuta a rispondere a queste domande:

• Quanti difetti dobbiamo trovare per ottenere una qualità ragionevole?
• Quanti difetti potrebbero essere eccezionali?
• Quanti altri test dobbiamo eseguire?
• Siamo pronti per andare in diretta?

Efficienza nella rimozione dei difetti

La qualità di un prodotto software viene generalmente osservata come il numero di difetti esposti durante la produzione. Il numero dei “nuovi” difetti diminuisce nel corso dei primi 3 mesi, quindi possiamo dire che il L'efficienza nella rimozione dei difetti è determinata dal numero di difetti rilevati nei primi 3 mesi di utilizzo come percentuale dei potenziali difetti, che si basa sulla quantità di funzionalità fornite.

Benchmarking del software – Pianificazioni

Il programma, o il tempo impiegato per fornire il software, è una conseguenza diretta della produttività dei team che lavorano sul software. Abbiamo esaminato la produttività degli sviluppatori in termini di output del team per sprint a circa 70 CFP per sprint di due settimane, o 140 al mese. Questo ci dà una guida chiara per rispondere alla domanda. "Quando sarà pronto?"

Regola del pollice: Per piccoli progetti inferiori a 1000 CFP: un team in genere consegnerà 140 CFP al mese.

Regola del pollice: Per progetti di grandi dimensioni superiori a 1000 CFP+, la produttività diminuisce con la dimensione: il numero di mesi per la consegna = CFP ^ 0,4

Tieni presente che fornire funzionalità di scarsa qualità rallenterà il progetto nel complesso. Solo con un'alta qualità è possibile ottenere tempi di consegna più rapidi.

Mancia: Se un CFP è stato consegnato ma viene scoperto un difetto in uno sprint successivo, non lo conteggi come consegnato.

Benchmarking del valore consegnato

Se un'azienda spende $1000 per fornire 1 CFP di nuove funzionalità. Ci si aspetterebbe che il valore aziendale complessivo di tale funzionalità superi il costo di $1000 a breve e lungo termine. Il valore per CFP varierà, ma le aziende dovrebbero pensare a un ritorno di valore in 1-3 anni in termini di costi molte volte superiori per CFP. Il vantaggio commerciale triennale per CFP è un parametro utile da monitorare e può essere utilizzato come parametro di riferimento.

Costo totale della proprietà

Oltre al costo di costruzione iniziale $1000 di un CFP, le aziende dovrebbero tenere conto del costo totale di proprietà per tutta la durata di vita del software. Ad esempio, nei primi due anni successivi alla costruzione iniziale è probabile che vengano apportati notevoli miglioramenti, circa 20% nel primo anno e ulteriori 15% nel secondo, successivamente in genere 8% all'anno. Puoi stabilire internamente i tuoi parametri di riferimento per il TCO delle applicazioni software nel tuo portafoglio; questi dati ti aiuteranno a prendere decisioni sui piani di sostituzione del sistema.

Regola del pollice: il TCO totale a 5 anni è in genere 2-3 volte il costo iniziale.

Modifica dell'ambito del benchmarking

Nel corso di un progetto sorgeranno o diventeranno evidenti nuove esigenze. Mentre alcuni di questi sono conoscibili in anticipo, altri no. Le organizzazioni che investono adeguatamente nel lavoro sui requisiti (15% o superiore per lo sviluppo personalizzato, superiore per implementazioni di pacchetti come ERP) non solo otterranno tempistiche più brevi, ma sperimenteranno anche meno cambiamenti di ambito durante il progetto. Capperi Jones

Regola del pollice: 1-2% modifica dell'ambito al mese durante un progetto.

Regola del pollice: 8% modifica annuale dell'ambito dopo l'implementazione.

 

Benchmarking del debito tecnico

Il debito tecnico è la rielaborazione che deriva dall'emergere di requisiti che non erano noti al momento della stesura del codice. Per quantificare e valutare il debito tecnico, è necessario prima classificare attentamente la rilavorazione causata da:

• Errori nel codice (non debito tecnico)
• Scorciatoie create per una rapida implementazione (non debito tecnico nel concetto originale ma comunemente ritenuto tale)
• Rielaborazione perché è stato svolto un lavoro insufficiente sui requisiti (incognite conoscibili che si verificano in seguito). Questo è un debito tecnico evitabile.
• Rielaborazione perché in seguito sono emersi requisiti che prima non erano conoscibili. (Questo è l’inevitabile vero debito tecnico.)

La maggior parte delle organizzazioni non sono coerenti con le classificazioni di cui sopra e quindi troveranno difficile il benchmarking del debito tecnico.

 

Costo totale della proprietà

Oltre al costo iniziale di creazione di $1000, le aziende dovrebbero tenere conto del costo totale di proprietà per tutta la durata di vita del software. Nei primi due anni successivi alla costruzione iniziale è probabile che vengano apportati miglioramenti considerevoli, circa 20% nel primo anno e ulteriori 15% nel secondo e 8% all'anno successivamente. Oltre a ciò c'è la manutenzione annuale del software, sia per mantenerlo funzionante su un'infrastruttura in continua evoluzione sia per correggere i bug che compaiono. Capperi Jones

Regola del pollice: il costo a 5 anni è in genere 3 volte il costo iniziale.

Altri benchmark per il lavoro del software

Ingegneri per cliente/utente

Questo numero è spesso citato dai prodotti Saas di consumo come Facebook e Twitter. Più frequentemente viene espresso come migliaia di utenti per ingegnere. Questa è una metrica utile per tali organizzazioni.

Entrate per ingegnere DevOps

Nelle aziende ad uso intensivo di software, dove il personale tecnico rappresenta un costo primario dell'azienda, il monitoraggio dei ricavi complessivi per ingegnere DevOps è un ampio indicatore di efficienza tecnica.

Metriche DORA

Frequenza di distribuzione

È una misura del numero di volte in cui il nuovo codice (di qualsiasi quantità) viene rilasciato alla produzione. È un utile indicatore una tantum della ripetibilità del ciclo di sviluppo/test. La frequenza di distribuzione dovrebbe essere misurata in ore o giorni, non in settimane.

Tempo medio per il ripristino

Il tempo medio di ripristino tiene traccia del tempo trascorso necessario per ripristinare il servizio dopo un errore nella produzione. Questo è un indicatore della capacità di una squadra di riprendersi da un errore. Dovrebbe essere misurato in minuti o ore, non in giorni.

Tempi di consegna per le modifiche

Lead Time for Changes tiene traccia del tempo impiegato dal timecode per passare dal commit all'esecuzione corretta in produzione. Ciò non tiene conto dell’entità, del valore o della complessità del cambiamento. Si tratta più di efficienza di implementazione che di efficienza di sviluppo.

Modifica tasso di fallimento

Il tasso di errore di modifica è un indicatore della qualità del codice distribuito.

Vantaggi delle metriche DORA

Sono facili da monitorare

Sono focalizzati sulle attività DevOps.

Svantaggi delle metriche DORA

Si concentrano sui tassi di cambiamento indipendentemente dalle dimensioni o dal valore del cliente.

Sono per lo più inadatti alla pianificazione, al dimensionamento e al monitoraggio dei progetti

Sono adatti solo per il benchmarking delle attività DevOps o DevSecOps,

Benchmark dannosi per il lavoro del software

Le organizzazioni possono spesso acquisire erroneamente parametri che possono portare a conseguenze indesiderate, questi dovrebbero essere usati con grande cautela o evitati del tutto e inoltre non dovrebbero essere usati come base per il benchmarking.

Righe di codici prodotte per ingegnere

Ciò può indurre gli sviluppatori a scrivere codice dettagliato, anziché codice efficiente o riutilizzato. Usa invece CFP prodotta per ingegnere

• Difetti prodotti al mese per ingegnere
  • Il numero di difetti prodotti dovrebbe essere considerato nel contesto dell'output. Uno sviluppatore che produce 1 difetto al mese e solo 1 CFP, è meno capace di uno che produce 2 difetti al mese in 10 CFP. Usa invece difetti per CFP prodotto per ingegnere.
• Costo per rilevare un difetto
  • Maggiore è la qualità del software, più costoso sarà individuare un difetto. Un costo elevato per la scoperta di difetti può significare che il software ha già un valore elevato.

Suggerimenti per il benchmarking interno

1. Divulgare i nomi dei progetti su benchmark comparativi interni
2. Mostra le metriche dei componenti e non solo i valori complessivi.
3. Includere attività non di codifica.
4. Includere gli aspetti umani.
5. Utilizza metriche di dimensione funzionale.
6. Non utilizzare i dati per fissare obiettivi astratti.

Riassunto da Capers Jones presentazione sul benchmarking