La nostra esperienza nell’utilizzo delle metriche Agile più comuni

La nostra esperienza nell’utilizzo delle metriche Agile più comuni

L’utilizzo delle metriche Agile per misurare la produttività del team è la parte fondamentale della filosofia di Agile. I team manager e tutti i membri dovrebbero vedere le conseguenze del loro lavoro e utilizzare questi dati per migliorare il flusso di lavoro e aumentare l’efficienza.

Gli utenti finali e i clienti possono anche beneficiare dell’uso di metriche di progetto Agile che si concentrano sulla valutazione del risultato del prodotto. Le metriche consentono a scrum master, sviluppatori, designer e tester di misurare le prestazioni dell’applicazione e tenere traccia se le attività correnti e precedenti rendono il prodotto migliore.

In questo articolo, esamineremo le metriche Agili che contano e condivideremo la nostra esperienza nell’applicazione di questa dashboard di metriche Agili a un progetto di vita reale. Si scopre, per guidare un team con successo e fornire risultati, non solo è necessario sapere quali metriche da applicare, ma come farlo-condivideremo come abbiamo capito.

Tipi di metriche Agili comuni

La classificazione delle metriche agili non è scolpita nella pietra: è in continua evoluzione e ristrutturazione. Tuttavia, nel corso degli anni, abbiamo visto l’aumento di tre tipi principali di metriche Agili in vari framework Agili.

1. Metriche Kanban: queste metriche si basano sulla misurazione del tempo investito (tempi di ciclo) e dei risultati consegnati (throughput) e sul loro rapporto.
2. Scrum metrics-metriche focalizzate sulla pianificazione e comprensione del flusso di lavoro e sulla dimostrazione di quanto lavoro è stato eseguito in un determinato periodo;
3. Lean metrics-la misurazione continua dell’efficienza produttiva e della qualità del prodotto con valutazione tecnica testando le funzionalità, verificando eventuali errori e prevedendo effetti negativi.

Utilizziamo tutti e tre i tipi di metriche per valutare gli aspetti principali del processo di sviluppo del software e i risultati: qualità del prodotto, produttività del team e salute.

Metriche di qualità agile

Prima di iniziare a misurare la velocità e l’efficienza del team, è necessario sapere se si sta generalmente muovendo nella giusta direzione. Qual è l’uso nella pronta consegna di tutte le attività di sviluppo, se le attività stesse sono formate nel modo sbagliato? La priorità per ogni team di sviluppo software e manager è assicurarsi che tutte le attività siano correlate al miglioramento del prodotto — questo viene fatto misurando la sua qualità e rilevando tendenze negative.

Difetti sfuggiti

Ogni progetto Agile ha sprint o cicli di lavoro, al termine dei quali viene consegnata una determinata attività. Dopo che il lavoro è stato completato, il manager del team deve valutare la qualità dei risultati trasformati. Tutte le modifiche, le modifiche e i bug non corretti sono difetti sfuggiti-problemi che gli sviluppatori potrebbero aver risolto ma non l’hanno fatto. Registra il loro numero preciso e la loro natura per sapere quali errori di solito sfuggono agli occhi degli sviluppatori.

Dopo aver fatto un rapporto sui difetti sfuggiti e raccolto statistiche tangibili, devi discutere i risultati con il tuo team. Assicurati che ogni membro del team sappia quali tipi di errori in genere manca al team. Se hai suggerimenti individuali, discutili con i membri del team uno contro uno.

Distribuzioni non riuscite

Se il prodotto è stato distribuito ma non rilasciato o non è riuscito ad attirare gli utenti, questo viene registrato come distribuzione non riuscita. A volte, una distribuzione non riuscita accade alle decisioni di uno degli stakeholder, o il modello di business si rivela inaffidabile. Qualunque sia stata la causa del problema, è necessario registrare tutte le distribuzioni non riuscite insieme ai motivi del loro errore.

Prima di rilasciare una nuova distribuzione, il team può sempre dare un’occhiata all’elenco delle distribuzioni precedentemente fallite ed esaminare se questa non può essere sottoposta allo stesso processo. L’analisi dei motivi del fallimento delle versioni precedenti consente di evitare problemi futuri.

Release Net Promoter Score (NPS)

Il Net Promoter Score è la metrica che prevede la valutazione delle reazioni degli utenti in termini quantitativi (numeri, statistiche, valutazioni medie) e qualitativi (recensioni, feedback diretti, messaggi, e-mail, chiamate). Dopo che il team ha raccolto e analizzato il feedback, ogni membro del team suggerisce un punteggio che valuta quanto è probabile che l’utente raccomandi il prodotto (in genere, i punteggi sono impostati in limiti da 1 a 10).

Metriche di gestione del progetto agile

Dopo aver avuto una cronologia completa di fallimenti e successi precedenti, è possibile analizzare la direzione intrapresa per tutti i progetti incompleti attuali e fornire attività pertinenti, basandosi su esperienze precedenti. Dopo aver stabilito la direzione dello sviluppo – il” cosa fare” del prodotto, “è necessario valutare l’efficienza del team — è il fattore” come stiamo facendo”. Puoi utilizzare le metriche del progetto Agile per sapere se i membri del team soddisfano le tue aspettative, comprendere le loro attività, gestire le scadenze e se tutti i processi sono coordinati e sincronizzati.

Lead time

Lead time è una metrica che consente ai team di verificare quanto è necessario per la voce product backlog per arrivare alla fine dello sprint. Può essere utilizzato per monitorare i prodotti in qualsiasi fase di sviluppo, attività per attività o valutare le spese complessive di tempo, dall’ideazione al rilascio. È una metrica a lungo termine che gli sviluppatori possono utilizzare durante la pianificazione del loro lavoro futuro e la stima dei prezzi.

Assicurati di registrare il lead time per ciascuno dei tuoi progetti. È meglio mantenere sia le statistiche di immagini più grandi che coprono l’intero progetto, sia le metriche di sprint organizzate, in modo da poter esaminare ogni fase separatamente.

Tempo di ciclo

Se il tempo di consegna è tra le metriche di rendimento del team a lungo termine, il tempo di ciclo si concentra sulle singole attività. Questa metrica valuta la durata di un singolo ciclo, in cui un ciclo viene preso da un’attività, calcola il numero di cicli per progetto e misura i risultati raggiunti per l’utente finale se il prodotto è già beta-testato o rilasciato.

Con il tempo di ciclo, i team possono immediatamente verificare se un’attività richiede troppo tempo o se alcuni membri del team non stanno fornendo i loro risultati. Questa metrica a breve termine rende la gestione del progetto molto più semplice e aiuta a individuare rapidamente i problemi man mano che si presentano.

Sprint burndown

Questa metrica viene applicata sia a breve che a lungo termine. I manager possono creare sprint burndown Scrum report in tempo reale per monitorare i progressi del loro team sul progetto corrente — per questo, hanno bisogno di stimare il numero totale di sprint e prevedere le spese di tempo probabili. Può anche essere utilizzato a lungo termine: i manager possono analizzare i report sui progetti precedenti, individuare le fasi che hanno fallito i tempi previsti e analizzare le cause dei ritardi.

Soprattutto, sprint burndown consente di monitorare le dinamiche del flusso di lavoro dei team. Alcuni membri tendono a rallentare il lavoro nelle prime fasi, mentre altri si esauriscono verso la fine del progetto. Con sprint burndowns, i team leader possono rilevare queste tendenze, determinare le loro cause e aiutare i membri con la distribuzione del lavoro e la gestione del tempo.

Epic & Release burndown

Questa metrica è simile a Sprint Burndown — l’unica differenza fondamentale è che si concentra sulla produttività del team prima e dopo il rilascio. I manager possono aggiungere nuovi requisiti e incorporare attività basate sul feedback degli utenti finali. È una versione migliorata di sprint burndown, in quanto incorpora anche attività fornite dopo il rilascio del progetto.

Velocity

Questa metrica valuta il numero di punti storia completati in un determinato periodo. In base alla tua cronologia, puoi prevedere le spese di tempo per i punti storia futuri. La diminuzione della velocità della squadra su particolari sprint può indicare incomprensioni tra i membri del team o attività indicate che sono più difficili di quanto precedentemente previsto.

Ulteriori metriche Agile

Le metriche Agile aiutano il team a conoscere meglio il proprio progetto e a tenere traccia di molti aspetti significativi dello sviluppo del prodotto. Ci sono anche metriche Agili per i senior executive che consentono di vedere il quadro più ampio dello sviluppo e del benessere del team. Secondo la nostra esperienza, queste metriche aggiuntive aiutano a misurare qualsiasi aspetto del tuo lavoro. Tuttavia, abbiamo definito le caratteristiche chiave che raccontano al meglio il prodotto finale e aiutano a fornire un risultato completo.

Flusso cumulativo

Il nome della metrica comunica chiaramente il suo scopo: accumulare tutti i flussi di progetto e valutarli in un unico diagramma. Avere un grafico di questo tipo ti fornirà una vista su larga scala: può essere inviato agli stakeholder del progetto che non hanno il tempo di analizzare report Agili più dettagliati.

Il diagramma di solito descrive i seguenti processi:

• Compiti nel backlog: quante attività nei membri del team di backlog hanno nel periodo di tempo specificato;
• Lavoro approvato: quante attività tra quelle pianificate sono state completate — il team manager vede immediatamente le differenze tra attività pianificate e finalizzate;
• Attività buffer: tutto il lavoro in attesa di approvazione è definito come in una zona buffer;
• In corso: è necessario valutare il carico di lavoro corrente.

Code churn

Questa metrica mostra le tendenze delle modifiche alla base di codice prima del rilascio. I diagrammi Churn mostrano quanto codice è stato aggiunto, rimosso o modificato una volta alla volta. Agli sprint iniziali, ci saranno molti picchi e cadute sul grafico, perché il codice è ancora instabile, ma man mano che il progetto progredisce, il grafico del churn del codice dovrebbe diventare stabile, senza drastici alti e bassi.

Prima del rilascio, il churn dovrebbe ottenere un declino: aggiungere o modificare il codice prima del rilascio significa che non sarà sottoposto a test sufficienti. Nel complesso, ogni volta che c’è un’irregolarità sui grafici Agili, indagare le ragioni.

Grafico di controllo

Un grafico di controllo è un grafico in cui il team può visualizzare informazioni sulla durata dei propri tempi di ciclo. Il risultato ideale avrebbe la linea sul grafico costantemente scendendo con il tempo-significherebbe l’aumento della velocità della squadra-meno tempo è richiesto per singolo ciclo. Un altro aspetto importante è la coerenza – i tempi di ciclo devono rimanere anche indipendentemente dal tipo di attività — significa che hai una corretta distribuzione del lavoro.

Metriche di salute

I team di sviluppo software devono concentrarsi su priorità a lungo termine, come mantenere la comunicazione tra i membri liscia e verificare se tutti sono soddisfatti. Agile è una metodologia flessibile, il che significa che può adattarsi agli interessi dei diversi membri, non appena i manager sanno a cosa prestare attenzione. Ecco come scopriamo se tutti i membri del nostro team sono soddisfatti del flusso di lavoro.

Happiness

Se ti sei fidato di relazioni informali nel tuo team, è più facile iniziare con una finestra di dialogo aperta con ciascun membro. Chiedi a tutti di valutare la loro esperienza in azienda da 1 a 5. Puoi fare domande di assistenza: quali sono gli aspetti migliori e peggiori del loro lavoro, cosa potrebbe essere migliorato e cosa potrebbe aumentare la felicità? Se il team non ha abitudini di comunicazione amichevoli, l’utilizzo di sondaggi anonimi può portare a risultati più oggettivi.

Morale della squadra

Morale della squadra e felicità non sono le stesse cose. La felicità ha più a che fare con il comfort, mentre il morale della squadra è legato alla produttività, all’autostima, alla valutazione delle proprie qualità professionali. Ancora una volta, puoi chiedere ai dipendenti di valutare il loro morale da 1 a 5 e porre le seguenti domande;

• Lavorare in azienda ti ha aiutato a migliorare le tue abilità?
• Quanto viene esplorato il tuo pieno potenziale con il carico di lavoro attuale?
• Ti piace il tuo lavoro?
• Vedi i risultati chiari del tuo lavoro?
• Sei entusiasta dei nuovi progetti?

L’obiettivo qui è capire che la corrente di sviluppo del team va nella giusta direzione. A volte, il manager del team di sviluppo software prende compiti redditizi ma noiosi, ignorando gli interessi dei membri. Questo sondaggio ti aiuterà a vedere se i dipendenti sono eccitati e sfidati dal loro lavoro.

Fatturato dei membri del team

Se i team manager sostituiscono spesso i membri del team, significa che l’ambiente di lavoro è probabilmente malsano. Un certo tasso di turnover nel tempo è sano-in realtà, non si vuole avere alcuna aggiunta di persone per anni, come significherebbe stagnazione. Tuttavia, dovresti fare attenzione a improvvisi picchi di attività-mesi in cui diverse persone hanno lasciato la squadra o molte persone si sono unite. Se si ha un’improvvisa aggiunta di molti nuovi partecipanti, è necessario prestare attenzione al processo di onboarding prima di passare direttamente al lavoro relativo al progetto.

Misurare i vantaggi per gli utenti finali

I team Agile dovrebbero sapere quanto bene il prodotto si adatta alle esigenze di un utente finale e di un imprenditore. Questo viene fatto con un’analisi completa del codice che determina la qualità del codice e la sua usabilità per un utente finale, nonché le possibili complicazioni di manutenzione.

Analisi del codice statico

È il semplice tipo di analisi del codice quando il software è inattivo. Semplicemente monitorando automaticamente il codice con strumenti open source, è possibile identificare problemi di sicurezza, rilevare debito tecnico e bug e inviare frammenti di codice problematici al garbage collector.

Analisi dinamica del codice

L’analisi dinamica del codice richiede che il team esegua un software per valutare l’esperienza ricevuta dagli utenti finali. Incoraggiamo i nostri sviluppatori e tester a mettersi sempre nei panni degli utenti, esplorando gli scenari più comuni. Ad esempio, possono presentare i loro colleghi e familiari alla soluzione, richiedendo un feedback, a meno che non sia proibito dall’accordo. Ancora più importante, abbiamo un team di professionisti QA che sono pienamente responsabili per l’analisi dinamica del codice – anche se crediamo che più persone contribuiscono a testare le metriche in Agile, migliore è la qualità del prodotto finale.

Come applicare le migliori metriche Agili

Tra tutte le varietà di metriche Agili disponibili, è necessario selezionare quelle che saranno rilevanti per il team e i progetti a lungo termine. Tenere traccia di queste caratteristiche chiave dovrebbe essere un’abitudine, mentre non dovrebbe distrarti dal lavoro più urgente. Ecco come abbiamo integrato senza problemi metriche Agili nel nostro flusso di lavoro.

Focus su prestazioni, budget e qualità

È necessario assicurarsi che, dopo aver selezionato tutte le metriche, si sarà in grado di avere un quadro chiaro della qualità del vostro lavoro, carico, spese di tempo, e budget. In primo luogo, abbiamo impostato metriche a breve termine relative ai nostri progetti attivi: tempo di ciclo e velocità per la valutazione agile delle prestazioni, analisi del codice per la valutazione della qualità del codice e flusso cumulativo per tenere traccia di tutti i processi di sviluppo e dei loro costi.

Durante il primo sprint, ci assicuriamo di fare quanto segue:

• Definire il numero di scatti e dei cicli di progetto;
• Stimare il tempo di spese per l’intero progetto, tenendo in considerazione le esigenze del cliente;
• Valutare soluzioni competitive per capire il livello di complessità del prodotto finale;
• Raccogliere feedback da parte dei nostri membri del team sulle loro aspettative sul progetto più eccitante, stimolante, e gli aspetti difficili.

In questo modo, possiamo sapere quanto tempo impiegheremo per completare il progetto, impostare standard di qualità basati su soluzioni simili e se il nostro team è motivato a lavorare sui compiti o meno (ha un enorme impatto sulla produttività).

Metriche dopo il primo sprint

Qui, ci concentriamo sull’ottenere feedback dal cliente e da tutti i membri del team. Dopo il primo sprint, vogliamo sapere che tutte le parti coinvolte nel flusso di lavoro comprendono il processo e si sentono a proprio agio. Inoltre, sottolineiamo la valutazione della qualità del codice: pianifichiamo persino l’analisi del codice e la valutazione del debito tecnologico come parte di ciascuno dei nostri prossimi sprint. Non appena sono state scritte le prime righe di codice, il mantenimento della sua qualità è la nostra priorità.

Velocity viene dopo

Velocity è una delle metriche più importanti nei nostri progetti, ma non quella chiave. Ci asteniamo dal basare il nostro giudizio sui numeri di velocità nelle fasi iniziali. La strategia di ottenere rapidamente attraverso i primi passi è un disastro in attesa di accadere – il team potrebbe saltare la pianificazione, o dimenticare di porre un cliente diverse domande cruciali. Non affrettiamo le prime fasi del prodotto, lasciando che clienti e membri del team trovino il loro ritmo.

Aumentare la velocità del nostro team diventa una delle nostre priorità quando siamo al punto di esecuzione. Non appena tutte le caratteristiche e il design sono disposti, ci sforziamo di ridurre al minimo le spese di tempo e completare tutte le attività il più rapidamente possibile.

Metriche individuali

Ciascuna delle metriche utilizzate dovrebbe essere disponibile per l’intero team e per i singoli membri. Sviluppatori, tester, designer dovrebbero essere in grado di vedere il ritmo e i risultati del loro lavoro, non solo un team nel suo complesso. Per realizzarlo, utilizziamo strumenti di produttività e time tracker, come Jira e Hubstaff. Tutti i rapporti generali sono sincronizzati con quelli individuali-i membri possono vedere quale percentuale di tempo produttivo complessivo fanno le loro ore.

Domande frequenti

Che cos’è il KPI in Agile?

Gli indicatori chiave di performance in Agile sono valori misurabili che mostrano l’efficienza del team nel raggiungimento degli obiettivi aziendali. I KPI di alto livello si concentrano su risultati a lungo termine che dipendono da molti fattori: quanti utenti sono stati attratti dal prodotto finale, dai tassi di conversione, dalla qualità del feedback. I KPI di basso livello sono valori a breve termine che non sono influenzati da molti fattori connessi: tempo trascorso sul progetto (solitamente calcolato in ore), budget del progetto (investimento per attività), ecc.

Agile è una metodologia di sviluppo basata sul miglioramento continuo: lo sviluppo di software analizza i dati e si adatta ad esso. Il team analizza i KPI agili sulle sue prestazioni e sulla qualità del lavoro e implementa le modifiche immediatamente, nel prossimo sprint.

Cosa sono le metriche Sprint?

Le metriche sprint sono metriche che valutano i risultati finali del team di sviluppo software, controllando quanto valore è stato consegnato al cliente finale entro la fine di ogni sprint . Questo valore può essere misurato con una nuova funzionalità, miglioramenti del design o eliminazione di bug.

Il prossimo obiettivo di sprint metrics è misurare l’efficacia del team in termini di business: quanto velocemente la soluzione è stata consegnata al mercato, qual è il feedback del cliente e i livelli di conversione. Infine, le metriche devono mostrare la soddisfazione degli sviluppatori per il loro progetto e per la direzione che il team sta prendendo in generale.

Perché le metriche sono importanti per i progetti Agile?

L’intero punto della metodologia Agile è che gli sviluppatori possono sempre apportare correzioni nel processo dopo ogni sprint. Avere dati tangibili, statistiche e grafici consente agli sviluppatori di capire quali cambiamenti apportare per il prossimo sprint e consente di valutare la qualità del prodotto finale, altrimenti sarebbe facile rimanere intrappolati nei dettagli tecnici e organizzativi.

Che cos’è uno sprint in Agile?

Uno sprint è un periodo chiaramente definito con la data di inizio e fine in cui la squadra è impostata per completare un certo numero di attività. Gli sprint sono la base di Scrum, Agile e DevOps: i team dividono il carico di lavoro in blocchi gestibili più piccoli e monitorano i risultati di ogni sprint. Ciascuno di questi periodi è trattato come un mini-progetto con una pianificazione preliminare, valutazione del rischio, assegnazioni di responsabilità e analisi post-sprint.

Ogni progetto è composto da una serie di sprint. Poiché ogni sprint viene valutato, è facile individuare i problemi nella fase iniziale e rimuoverli nello sprint successivo, in modo che il flusso di lavoro sia costantemente ottimizzato.

Quali sono le metriche per lo sviluppo del software?

Le metriche di sviluppo software sono valori quantitativi che consentono di misurare la qualità, le prestazioni e lo stato di salute del progetto di sviluppo software. Aiutano a migliorare il processo di sviluppo man mano che il progetto si muove e possono essere utilizzati per il lavoro futuro del team per migliorare l’organizzazione e la pianificazione.

Esistono sei tipi principali di metriche di sviluppo software:

• Metriche del codice formale: si tratta di valori qualitativi oggettivi che calcolano la quantità di lavoro eseguita determinando il numero delle righe di codice (LOC), la lunghezza del percorso delle istruzioni e altri.
• Metriche di efficienza degli sviluppatori: il team può calcolare il codice di assegnazione, i giorni attivi e il tempo dedicato all’attività.
• Metriche di processo agile — quando il progetto è suddiviso in sprint, il team può misurare l’efficienza di parti più piccole del progetto – lead time (quanto tempo è stato speso per una determinata fase di sviluppo, che può contenere diversi sprint), tempo di ciclo (uno sprint di solito rientra in un singolo ciclo) e velocità (quante attività sono state eseguite in un
• Metriche operative: queste metriche controllano le caratteristiche del software in esecuzione e determinano l’efficacia del personale aziendale nel mantenere lo strumento senza l’aiuto di terze parti. Mean Time Between Failures and Mean Time to Recover (MTTR) controllare come il software verrà eseguito in circostanze naturali e come attrezzata è il team interno nella gestione del carico.
• Metriche di test: queste metriche valutano la copertura del codice: quanto codice è stato testato, il numero di bug e la percentuale di debito tecnologico.
• Soddisfazione del cliente — il team ottiene informazioni sulle reazioni degli utenti finali al prodotto misurando il Net Promoter Score, il Customer Satisfaction Score e il Customer Effort Score. Queste metriche valutano, rispettivamente, se gli utenti raccomandano il prodotto e se sono soddisfatti del risultato.

Le metriche Agile fanno parte delle reti software e possono comprendere altre categorie, come puoi notare dalla nostra guida.

Cosa sono le metriche SDLC?

SDLC è un ciclo di vita di sviluppo software – un insieme di fasi che una tecnologia tipica subisce durante la sua concezione, esecuzione e finalizzazione. Un SDLC medio è costituito dalle seguenti fasi:

• Valutazione dei sistemi esistenti e definizione delle loro caratteristiche, vantaggi, problemi;
• Definizione dei requisiti per il nuovo progetto funzionalità, design, target di riferimento, ecc.;
• Progettare il sistema e delineare un percorso utente tipico;
• Sviluppare il software, che significa scrivere codice, preparare hardware e creare funzionalità;
• Test delle prestazioni del software, funzionalità, sicurezza, interfaccia, ecc.;
• Distribuire il software nel suo ambiente naturale, dove la tecnologia funzionerà a lungo termine;
• Mantenere il sistema aggiornando il codice, sostituendo o modificando alcuni frammenti e rimuovendo i bug.

Ogni stadio di SLDC può essere misurato dalle seguenti caratteristiche.

• Requisiti: il team deve raccogliere tutti i requisiti per il progetto e valutare l’implementazione di ciascuno di essi in termini di tempo e denaro;
• Software di qualità: tutti Agile metriche di qualità può essere utilizzato in fase di sviluppo di un SDLC;
• casi di Test: la squadra deve calcolare il numero di eseguita attività di test, la sua velocità, e la finale di copertura del codice;
• Difetti: per misurare l’efficienza del loro lavoro, gli sviluppatori e i tester devono essere a conoscenza del numero esatto di problemi che si presentano durante lo sviluppo;
• Attività: la misurazione del tempo trascorso e il denaro guadagnato per l’operazione che permette di valutare se tutti i membri del team sono produttivi o non.

Tutte le metriche, descritte nella nostra guida, possono essere utilizzate in diverse fasi del ciclo di vita dello sviluppo del software. Il progetto ha la massima necessità di monitorare più vicino al rilascio perché i problemi possono accumularsi ed è facile perdere un difetto critico nel prodotto.

Che cos’è il throughput nelle metriche Agile?

È la metrica che calcola il numero di storie completate per sprint. In Scrum, una metrica simile è indicata come Velocità di Sprint.

Conclusione

Metriche agili impostare una solida base per prendere decisioni informate in tutto un progetto di sviluppo software. Gli sviluppatori possono utilizzare queste informazioni per aumentare la loro efficienza nei prossimi sprint e migliorare costantemente la qualità del loro prodotto. Tuttavia, vale la pena notare che le metriche di sviluppo non dovrebbero diventare una priorità assoluta nel progetto di sviluppo software. Gli sviluppatori dovrebbero fare affidamento, prima di tutto, sulle esigenze del progetto e sulle preferenze del pubblico.

In Jelvix utilizziamo un approccio personalizzato per applicare le metriche al progetto. Innanzitutto, discutiamo l’MVP del progetto con il cliente, ricerchiamo il pubblico di destinazione, analizziamo le soluzioni competitive e solo dopo scegliamo le metriche che si adattano meglio al progetto. Non ci sforziamo di applicare ogni singolo KPI, ma selezioniamo quelli che riflettono maggiormente le esigenze del progetto.