Archivi categoria: produttività

Misurare la produttività dello sviluppo software

Produttività = Output / Input . Bello, se fosse davvero così semplice.

Nel webinar Measuring Software Productivity, diffuso da ACM (Association for Computer Machinery, la maggiore organizzazione professionale di informatici), Steve McConnell enuncia questa semplice equazione per poi smontarla, pezzo a pezzo.

Come misurare l’output? Come misurare l’input? Quali sono le unità di misura? E qual è l’ambito di misurazione?

McConnell prende in esame tre ambiti possibili in cui misurare la produttività:

  • il singolo sviluppatore
  • il team
  • tutta l’organizzazione

e in una rapida analisi evidenzia i limiti di applicabilità delle diverse unità di misura.

Quanto costa ricevere feedback

Un concetto chiave della rivoluzione industriale è l’economia di scala: aumentando i volumi, riduco il costo della singola unità prodotta.

Ma quando l’obiettivo è di ottenere informazioni utili per migliorare i propri prodotti o servizi, l’economia di scala non serve – bisogna invece ridurre l’impegno necessario a ricevere il feedback, a imparare dall’esperienza.

Kent Beck (ideatore di eXtreme Programming, uno tra i principali processi agili) contrappone Economy of Scale a Economy of Scope, portando come esempio le pratiche di sperimentazione che Facebook usa per adattare e rendere più efficaci i servizi che offre.

La crisi del software è discutibile

Una ricerca spesso citata sullo sviluppo software è il Chaos Report, pubblicato periodicamente a partire dal 1994 dallo Standish Group. Il Chaos Report classifica i progetti in tre categorie: successo (risultati coerenti con i requisiti iniziali, forniti nei tempi e con le risorse previsti); discutibili (risultati inferiori alle attese e/o tempi e/o costi maggiori); fallimenti.

I dati del Chaos Report si possono interpretare in diversi modi: una critica ragionevole in questo articolo di Scott Ambler sul Dr. Dobb’s Journal: The Non-Existent Software Crisis:  Debunking the Chaos Report.

Più veloci o più lenti?

Negli anni ’70 e ’80, gli strumenti disponibili per gli sviluppatori software erano molto, molto, molto più lenti di quelli attuali. Per verificare la correttezza sintattica di un programma bisognava attendere il risultato della compilazione, che arrivava con un tabulato il giorno dopo, non dopo un nanosecondo.

La lentezza degli strumenti costringeva a pensare più a lungo, a controllare di più. Oggi il feedback è immediato, ma i risultati sono davvero migliori?
Phillip G. Armour, in When Faster is Slower (Communications of the ACM, 10/2013) lo mette in dubbio.

Use Case Points come metrica di business

Come misurare la produttività dello sviluppo software? McKinsey propone di ricorrere agli Use Case Points, con queste motivazioni:

  • comportano necessariamente l’adozione dei casi d’uso, con notevoli benefici per la gestione dei requisiti;
  • misurano i risultati dello sviluppo in termini di funzioni disponibili per gli utenti, non di altri aspetti (tecnici o manageriali) significativi solo per gli addetti ai lavori;
  • sono quindi una misura condivisibile sia dagli specialisti software che dalle persone del business;
  • possono essere usati efficacemente sia negli sviluppi a cascata che in quelli agili e iterativi;
  • la stima con gli Use Case Points è molto meno dispendiosa di quella effettuabile con i punti funzione (Function Points), ma è comunque altamente affidabile.