Come portare le metriche oggettive nelle prestazioni del team di sviluppo delle applicazioni (e perché lo vorresti)

Molti senior manager che hanno attraversato una trasformazione da un'organizzazione di sviluppo software tradizionale a un'organizzazione con team Agile auto-organizzati, comprendere che questo è stato un esercizio necessario per garantire che il valore venga fornito più rapidamente al loro ambiente aziendale in continua evoluzione. Dove la sopravvivenza delle aziende è spesso il risultato diretto della fornitura di funzionalità ai nuovi utenti più velocemente della concorrenza, questi manager di solito sono contenti di aver affrontato questo, ma riconoscono anche che l'adozione di un modo di lavorare agile non è un proiettile d'argento o una garanzia di successo.

”Anche se il concetto di squadre di auto-organizzazione suona alla grande, devono ancora essere gestiti nel contesto dell'intera organizzazione, la sua missione, visione e strategia.”

L'alta dirigenza deve prendere decisioni in merito ai budget, investimenti, personale, Cosa fare, e cosa non fare. Devono decidere le direzioni strategiche, gli obiettivi e gli obiettivi, il modello operativo, ma anche monitorare i progressi e apportare correzioni quando necessario.

Quello che vediamo nel mercato è che le organizzazioni lottano con quest'ultimo, e ciò è in gran parte dovuto alla mancanza di informazioni obiettive sulla gestione. Molti team Agile utilizzano metriche di avanzamento che hanno senso nel loro team, ma che non possono essere aggregati in utili informazioni gestionali. tuttavia, è importante capire le prestazioni dei team Agile, in quanto forniscono valore all'azienda e ai suoi clienti. Vediamo che le aziende operano a diversi livelli di maturità quando si tratta del controllo che hanno sui team di sviluppo delle applicazioni. La domanda è: a quale livello di maturità è la tua azienda?

Un noto modello per esaminare la maturità dei processi è l'integrazione del modello di maturità delle capacità (CMM) modello. Questo modello valuta i processi di sviluppo su 5 diversi livelli (Guarda la figura).

Livelli di maturità CMMi
Fonte: https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration

Questo è un buon principio e può essere utilizzato anche per valutare il controllo sui team di sviluppo Agile. Il modello di maturità del controllo agile (ACMM), in base ai livelli CMMi, consente al senior management di comprendere il livello di controllo dei propri team agili e il valore che offrono. La tabella seguente mostra il modo in cui IDC Metri esamina i diversi livelli di maturità del controllo Agile.

Bassi livelli di maturità (0, 1 e 2)

La maggior parte delle organizzazioni attualmente sono a livello 0 o 1. Hanno attraversato la trasformazione, e i CIO e altri dirigenti senior hanno ricevuto consigli da coach Agile e altri consulenti su come gestire la nuova organizzazione in cui i team che si auto-organizzano hanno molto potere di decidere, e l'azienda sta lavorando a stretto contatto con i team per creare valore. tuttavia, a livello 0 o 1, non hai idea di quanto valore viene creato per il budget speso, e come questo si collega alla concorrenza. inoltre, la prevedibilità è bassa ed è difficile gestire le interdipendenze tra i team e prevedere quando alcuni software saranno pronti. Le squadre esterne vengono contrattate in base al tempo e ai materiali (tariffe orarie) e non basato sull'output (massimo rapporto qualità prezzo).

Elevati livelli di maturità (3, 4 e 5)

Come un'organizzazione raggiunge un livello di maturità più elevato, l'alta dirigenza ottiene sempre più il controllo. Le metriche degli obiettivi vengono visualizzate in dashboard aggiornati, consentendo loro di prendere decisioni basate sui fatti. Questo porta con sé molti vantaggi, come per esempio:

  • La capacità di dimostrare agli stakeholder che tu (il CIO e il Senior Manager) ha il controllo delle prestazioni e della creazione di valore dei team Agile.
  • Concentrati sulla creazione di valore effettivo migliorando la produttività e la velocità di consegna, migliorando al contempo la qualità del prodotto.
  • Le misurazioni obiettive vengono utilizzate per capire quali sono le squadre con le prestazioni migliori e quali quelle con le prestazioni basse. Quindi si possono indagare le ragioni di ciò e si possono intraprendere azioni di miglioramento.
  • L'accuratezza della stima dei costi del software migliora enormemente, poiché i dati dell'organizzazione e dei team possono essere utilizzati per calibrare i modelli parametrici.
  • Gli indicatori principali determinano una maggiore prevedibilità delle squadre, eliminando gli slittamenti di programma o di costo.
  • Basato su misurazioni oggettive e rimozione mirata di violazioni critiche, il rischio nel portafoglio di applicazioni si riduce significativamente mentre la qualità, migliorano la manutenibilità e i livelli di costo.
  • Le metriche basate sull'output possono essere utilizzate nella contrattazione di team Agile, consentendo alle organizzazioni di selezionare il team che offre il miglior rapporto qualità-prezzo (produttività volte tasso medio) invece di quello più economico che potrebbe non essere affatto produttivo.

E ci sono molti altri vantaggi.

Nella figura successiva, vengono mostrati i miglioramenti tipici della produttività che abbiamo osservato, dove 0% è la media di mercato per squadre/applicazioni comparabili.

Essendo una funzione costosa, I team di sviluppo agile dovrebbero essere gestiti per garantire che il valore sia ottimizzato per l'investimento. Ma, come si misura il valore? Quando i leader IT sono alle prese con questa sfida comune, IDC Metri ha preparato una checklist per aiutarti a gestire e misurare le prestazioni dei tuoi team. Clicca qui per scaricare la checklist.

 

Harold van Heeringen – consulente principaleHarold van Heeringen

Harold van Heeringen si è laureato all'università di Groningen (Paesi Bassi) in economia aziendale in 1997 dopodiché ha lavorato per il fornitore di servizi IT Sogeti 17 anni come consulente senior di metriche software/stima dei costi del software. Nel 2015, è passato al fornitore di servizi di consulenza e benchmarking Metri, dove lavora come consulente principale e responsabile pratica per i servizi di IT Intelligence, compresa la stima & Servizi di misurazione delle prestazioni e gestione agile del valore. Oltre a lavorare in IDC Metri, è attivo in diverse organizzazioni no-profit attive in questo spazio. Harold è stato presidente dell'International Software Benchmarking Standards Group senza fini di lucro (ISBSG) a partire dal 2011 Fino a 2019 ed è ancora un amministratore attivo nel consiglio. Harold è anche membro del consiglio di Nesma, l'organizzazione internazionale focalizzata sulla misurazione delle dimensioni funzionali e sulla stima dei costi. In Nesma, è responsabile dei partenariati e della cooperazione internazionale. Harold è uno dei delegati di Nesma nel team che ha creato il Software Cost Estimation Body of Knowledge (SCEBoK). Harold pubblica regolarmente white paper, blog e articoli sulle metriche del software, stima dei costi, gestione agile del valore, valutazione della prestazione, benchmarking e argomenti correlati.