Misurazione della produttività

In altri settori oltre a quello del software, la misurazione della produttività è un'attività normale che guida il successo di un'azienda. Vediamo ad esempio un'azienda di pittura individuale. Per un pittore, sarebbe logico misurare la sua produttività in ore di sforzo per metro quadrato. Probabilmente vuole differenziare la misurazione in alcune categorie,come gli strumenti utilizzati (per esempio. rullo / spazzola / spray / ecc.) e dipingere le caratteristiche dell'oggetto (per esempio. muro / scale / porta / ecc.). Quando il pittore costruisce un database con i dati sulla produttività, può facilmente citare per nuovi lavori di pittura, semplicemente misurando la superficie della vernice in metri quadrati, moltiplicando per il giusto tasso di produttività e moltiplicando il risultato per il tasso orario che chiede. Se c'è un (internazionale) database disponibile con i tassi di produttività dei lavori di verniciatura eseguiti da altre aziende del settore, il pittore capisce come si comporta in media contro l'industria e nel caso in cui non sia già il migliore della categoria, capisce che per vincere nuovi lavori di verniciatura deve continuare a migliorare la sua produttività (poiché abbassare la tariffa oraria di solito non è una buona idea).

Può fare tutto questo, ma solo quando:

  • Usa un file unità di misura standard, per esempio. metro quadro. Solo utilizzando gli standard, i tassi di produttività possono essere confrontati (confrontato) e utilizzato per stima;
  • Usa un file modo standard per registrare le ore di sforzo. Per esempio, è la pausa pranzo inclusa o esclusa, è il momento di parlare con il cliente per capire le sue esigenze incluse / escluse?
  • Lui usa mcategorie significative che differenziano la produttività. Per un pittore, potrebbe non importare troppo se l'oggetto della pittura (diciamo un muro) è in una villa o in una casa di pescatori. Il tipo di casa potrebbe non essere una categoria significativa. tuttavia, lo strumento che utilizza è probabilmente uno dei principali driver di produttività.

Adesso, diamo uno sguardo all'industria del software.

L'industria del software e la misurazione della produttività

purtroppo, l'IT (e software) l'industria è ancora piuttosto immatura quando si tratta di utilizzare gli standard e quando si tratta di produttività (prestazione) misurazione, benchmarking e miglioramento continuo. L'industria se l'è cavata per molto tempo, perché:

  • È difficile da misurare produzione (il software non è una cosa fisica, non può essere toccato e misurato con strumenti di misura convenzionali).
  • I progetti software sono molto più simili a una R.&D progetto che fabbricare un prodotto. R&D è incredibilmente difficile da misurare. È relativamente facile misurare gli input, ma i risultati sono difficili da misurare e imprevedibili per natura.

Adesso, lentamente il settore sta diventando sempre più trasparente e le organizzazioni dei clienti chiedono sempre di più ai potenziali fornitori di quantificare le loro prestazioni sulla base di dati storici. Per di qua, diventa possibile selezionare il miglior fornitore per il lavoro. Si prega di notare che la scelta migliore di solito non è la scelta meno costosa (spesso con conseguenti fallimenti del progetto…o anche disastri).

Standard

Sebbene possa sembrare facile implementare un processo di misurazione della produttività in un'organizzazione, la realtà mostra che è più difficile di quanto si possa pensare. In linea di principio, proprio come il pittore, è sufficiente misurare gli input (di solito ore di sforzo) e uscite (Unità di misura, UM) per progetto software, mentre utilizzando categorie significative per differenziare i progetti, come la tecnologia (Java / .Net / Oracle / Etc.), Tipo di progetto (nuovo sviluppo / miglioramento) e / o implementazione (Implementazione / modifica del pacchetto / software personalizzato).

Essere in grado di costruire metriche di produttività significative e comparabili, è fondamentale che (internazionale) vengono utilizzati standard. È necessario fare una serie di scelte:

Ingressi di misura

Alcune decisioni che devono essere prese:

  • Sforzo ore dentro / fuori ambito di misurazione, per esempio
    • Disegno tecnico, codifica, test unitario, test dei sistemi, altri test del fornitore, overhead nel campo di applicazione;
    • Design funzionale, sostenere il test di accettazione, attività di implementazione fuori ambito.
  • Ambito di misurazione degli straordinari in / out;
  • Ore di viaggio, orari delle riunioni, ore di lavoro in / out scope;
  • In caso di pacchi, Portali / CMS o altro software configurabile, potrebbe essere necessario disporre di attività di registrazione dello sforzo separate per la personalizzazione, impostazione dei parametri e software personalizzato non compreso nel pacchetto.

Per essere in grado di analizzare la produttività di un fornitore, dipartimento o squadra, il sistema di registrazione dello sforzo dovrebbe essere implementato in modo standard. Se si sceglie che le ore di progettazione funzionale sono fuori portata, tutti i progetti dovrebbero registrare il loro sforzo di progettazione funzionale separatamente dalle altre ore di lavoro. Si raccomanda vivamente di redigere una "Struttura di suddivisione del lavoro" standard (WBS)’ per tipo di progetto e implementare questa WBS nel sistema di registrazione dello sforzo. Tutti coloro che registrano le ore di sforzo dovrebbero essere consapevoli dell'importanza di prenotare correttamente il proprio sforzo nel sistema.

Uscite di misura, metodi che dovrebbero essere evitati

Misurare gli output è un po 'più difficile che misurare gli input, a causa della natura intangibile del software. Molte organizzazioni misurano le linee di codice sorgente fornite (slocs) del prodotto software consegnato dopo il completamento e utilizza metriche di produttività come le ore di lavoro per 1000 slocs. Questo sembra un buon modo per andare, ma in realtà ci sono molte ragioni per cui questa non è una pratica consigliata:

  • Non c'è (ISO o altro) standard per le linee di codice sorgente. Il risultato è che producono diversi strumenti di conteggio automatico del codice (molto) risultati diversi per lo stesso codice.
  • Non è chiaro se più codice sia "buono’ o "cattivo". Le righe di codice sorgente non sono utili per l'organizzazione del cliente. La funzionalità ha valore. I clienti non dicono mai:”Per favore dammi 100000 righe di codice sorgente”. No, è la funzionalità in termini di caratteristiche che richiedono. Più funzionalità è migliore e costa di più, più slocs forse non è migliore.
  • Diversi linguaggi di programmazione (e miscele di questi) si traducono in righe di codice sorgente molto diverse.

Guru americano delle metriche del software’ Capers Jones ha scritto in un documento "Origini dei difetti del software e metodi di rimozione (2013) che le misurazioni dello sloc sono così imprecise, che l'uso di slocs nella misurazione del software lo è "Negligenza professionale".

Altre misure di taglia che vengono spesso utilizzate nel settore, ma lo sono anche non consigliato da utilizzare nella misurazione della produttività:

  • Punti della storia (SP) in progetti agili: Una misura molto soggettiva che ha valore solo all'interno di una squadra. Confronto con altre squadre, dipartimenti e organizzazioni non è possibile. Tieni presente che gli SP sono utili per pianificare gli sprint e per monitorare la velocità di una squadra, ma per la misurazione della produttività gli SP sono quasi inutili.
  • Punti di utilizzo (UCP): Applicabile solo quando la documentazione è composta da casi d'uso. L'UCP è anche un metodo altamente soggettivo, soprattutto quando si tratta di stabilire il fattore di complessità tecnica e il fattore ambientale. Anche, non esiste un modo standard per scrivere casi d'uso, vedere ad esempio cinque possibili livelli di granularità come descritto Qui.
  • Punti di complessità: Metodo soggettivo e non standardizzato per misurare la complessità di un'applicazione.
  • Punti IBRA: Metodo non standardizzato per misurare le regole aziendali in un'applicazione. Se applicato secondo il manuale, il risultato è zero per tutte le applicazioni.
  • Punti funzione veloci (FFPA) (di Gartner): Un metodo di misurazione implementato da Gartner che non può essere paragonato ai metodi di analisi dei punti di funzione standardizzati ISO. L'FFPA è percepito come un metodo commerciale privo di basi teoriche ed è in parte soggettivo. Il metodo non si è dimostrato più veloce del metodo stimato da Nesma e non si è dimostrato più accurato. Sfortunatamente viene spesso spinto a un livello dirigenziale superiore senza il supporto degli specialisti che devono lavorarci.

Uscita di misurazione – metodi fortemente consigliati

È un pratica altamente raccomandata utilizzare un file Standard ISO / IEC per la misurazione della dimensione funzionale nella misurazione della produttività di progetti software. Esistono cinque metodi di misurazione delle dimensioni funzionali conformi allo standard ISO / IEC:

  • Punti funzione NESMA (ISO / IEC 24570);
  • IFPUG punti funzione (ISO / IEC 20926);
  • COSMICO punti funzione (ISO / IEC 19761);
  • Mark II punti funzione (ISO / IEC 20968);
  • FiSMA punti funzione (ISO / IEC 29881).

I vantaggi dell'utilizzo di uno di questi metodi di misurazione delle dimensioni funzionali per la misurazione della produttività sono:

  • Obbiettivo, ripetibile, verificabile, modo difendibile per determinare la dimensione del software;
  • Una chiara relazione tra dimensione funzionale e sforzo necessario per realizzare l'applicazione, è stata studiata e verificata più volte;
  • La misura è chiara sia per le organizzazioni dei clienti che per le organizzazioni dei fornitori. Più funzionalità significa più valore, è necessario uno sforzo maggiore e un prezzo più alto;
  • La dimensione funzionale è indipendente dalla soluzione tecnica e / o dai requisiti non funzionali. Un'applicazione di 500 I punti funzione NESMA realizzati in Java sono grandi quanto un sito Web Wordpress di 500 FP. Ciò consente il confronto e il benchmarking su domini tecnici e l'uso dei dati storici del progetto (se adeguatamente classificati) nella stima di nuovi progetti software.

Categorie utili per la raccolta dei dati

Per essere in grado di confrontare e valutare la tua produttività, è importante utilizzare categorie standard per raccogliere dati dai progetti. Nesma consiglia vivamente di utilizzare le definizioni e le categorie che l'International Software Benchmarking Standards Group (ISBSG) sta utilizzando nelle proprie attività di raccolta dati.

L'International Software Benchmarking Standards Group (ISBSG) è un "no profit’ organizzazione che raccoglie i dati del settore del software e che cresce, mantiene e sfrutta due repository: 'Nuovi sviluppi e miglioramenti’ e "Manutenzione & Supporto'. ISBSG può farlo solo quando i dati vengono raccolti in modo standard. I "Questionari per la raccolta dei dati’ può essere scaricato dal Sito ISBSG e mostrano già molte definizioni e categorie. Anche i glossari forniti con i repository sono utili.

Implementazione della misurazione della produttività del software

Così, proprio come il pittore dell'esempio sopra, è possibile misurare la produttività dei progetti software. Vedi questa pagina per alcuni esempi.

Per implementare con successo la misurazione della produttività del software, si consiglia vivamente di utilizzare il documento "Base delle misurazioni’ che è elencato nell'elenco di pubblicazioni.