Archivi categoria: project management

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.

Perché i grandi progetti IT falliscono

Un articolo del settimanale inglese The Observer cita alcuni casi famosi in cui progetti informatici di grandi dimensioni hanno portato a rischi ingestibili e a fallimenti.

A scopo preventivo, l’articolo raccomanda di rendere obbligatoria per i manager IT la lettura del classico “The Mythical Man-Month” (il mitico mese-uomo), libro di Fred Brooks pubblicato nel 1975 dopo che Brooks aveva guidato il complesso progetto di sviluppo del sistema operativo IBM OS/360.

“The Mythical Man-Month” è in effetti un testo ricco di insegnamenti utili, tra cui il fatto che aggiungere ulteriori sviluppatori ad un progetto in ritardo provoca ritardi ulteriori. Per la sua utilità, nota l’autore dell’articolo di The Observer, il libro di Brooks continua ad essere pubblicato regolarmente dal 1975 ad oggi. Purtroppo, come accade per diversi altri testi fondamentali dell’IT (e non solo), non è mai stato tradotto in italiano.

I progetti sono come i dinosauri (sostiene McGovern)

I progetti sono come i dinosauri, nella vita delle organizzazioni, sostiene Gerry McGovern, esperto di content management.

Certo, si tratta di una generalizzazione molto forzata. In alcuni contesti, la logica progettuale è appropriata, in altri meno (ad esempio nelle continue evoluzioni di intranet e siti web, l’ambito di cui si occupa McGovern).
Ma quando un progetto sarebbe utile, farne a meno è davvero rischioso.

Punto di vista interessante, comunque.

Metriche e controllo

Lord Kelvin: “Se non si può misurare, non si può migliorare”.

Tom DeMarco, in Controlling Software Projects (1986): “Non si può tenere sotto controllo ciò che non si riesce a misurare”.

Phillip G. Armour, su Communications of the ACM, June 2012, rovescia il punto di vista: “Se non si migliorano le cose, è difficile misurarle bene; sotto alcuni aspetti, non possiamo misurare ciò che non controlliamo”.

Alcuni esempi illuminanti di misurazioni dubbie citate nell’articolo: durata, produttività, costo, qualità dei progetti software.

Chaos Report 2011

Dal 1994, ogni due anni, Standish Group comunica i risultati delle sue statistiche sull’andamento di migliaia di progetti di sviluppo software nel mondo: il Chaos Report.
I dati riferiti al 2010, riportati da Computerworld, mostrano un incremento dei casi di successo (37%), una diminuzione dei casi di successo parziale (42% di progetti conclusi con meno funzioni, maggiori tempi e costi di quanto stimato inizialmente), una sostanziale stabilità di casi di fallimento (21%).

Precisare tutto all’inizio

Come sarebbe bello se all’inizio di un progetto software tutto fosse ben definito: cosa fare, per quando farlo, a che costo…

Fissare tutto all’inizio, dal punto di vista manageriale, riduce i rischi di un progetto. Quindi conviene sforzarsi in tutti i modi per definire progetti in cui tutto è precisato al più presto, per poi affidarne la realizzazione a qualcuno (fornitore esterno o gruppo di sviluppo interno) che sia tenuto a rispettare quanto concordato.

Purtroppo, sostiene Scott Ambler, la riduzione del rischio è una pura illusione. La lezione più certa che arriva dal project management è l’impossibilità di bloccare, all’inizio e contemporaneamente, le tre variabili fondamentali di un progetto software: le cose da fare, i tempi, il budget.