project management

"Large Scale Agile" è il titolo del numero monografico di maggio / giugno 2013 di CrossTalk, la rivista sullo sviluppo software delle forze armate USA.
Articoli su come sviluppare in modo agile per progetti di grandi dimensioni e distribuiti in più centri; su come coniugare solidità architetturale e pratiche agili; sulle pratiche di stima di dimensioni e di impegno.

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, 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.

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.

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%).

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.

Jim Highsmith è uno tra i più maturi proponenti dell'approccio agile, essendosi occupato di software engineering dai tempi dell'approccio strutturato ed essendo tra i firmatari del Manifesto agile del 2001.

Highsmith ha pubblicato su Software Development Times un articolo breve ma utile in cui ripercorre le fasi di diffusione degli approcci agili: una fase di sperimentazione iniziale in cui in molti casi ci si focalizzava essenzialmente sulle pratiche di gestione iterativa dei progetti, senza curare in modo adeguato le pratiche tecniche (automazione dei test, integrazione, test driven development); una seconda fase più matura, in cui ci troviamo ancora, in cui le pratiche manageriali e tecniche si integrano; una terza fase, agli inizi, in cui il tema principale diventa come sfruttare la maggiore flessibilità e produttività dello sviluppo software a vantaggio delle finalità di business delle imprese - enterprise agility.

Un pattern sulla composizione dei gruppi di lavoro, formulato anni fa da Linda Rising, che ne parla in un articolo recente su IEEE Software, "The Benefit of Patterns".

Il Chaos Report è una fonte informativa molto citata sulle percentuali di successo dei progetti di sviluppo software. Ha una copertura di migliaia di progetti internazionali, in vari settori merceologici.

L'edizione 2009, pubblicata come sempre da Standish Group, indica un significativo peggioramento rispetto ai report precedenti.

32% di successo (progetti completati nei tempi e nei costi previsti, con le funzioni previste).
44% di successo o insuccesso parziale (progetti in ritardo, costi extra, meno funzioni di quanto richiesto).
24% di fallimento (progetti cancellati o che hanno prodotto sistemi mai usati).

"I risultati di quest'anno rappresentano il più alto tasso di fallimento nell'ultimo decennio", secondo lo Standish Group.

"The basic work unit in innovative software organizations is the team rather than the individual."

Uno studio relativo ai problemi che incontrano i gruppi di lavoro auto-organizzati nell'ambito dello sviluppo software, effettuato su 5 gruppi di lavoro in 3 organizzazioni, per la durata di tre anni, da un gruppo di ricercatori norvegesi.

Lo studio si è concentrato sia su problemi ingenerati all'interno dei gruppi di lavoro, sia su problemi derivanti dalla cultura e dai comportamenti organizzativi.

Alcune raccomandazioni conclusive:

• Formare le persone anche su temi non strettamente legati al loro ruolo
• Collocare il gruppo in un'unica stanza
• Valorizzare i generalisti
• Far crescere la fiducia e la responsabilizzaazione
• Assegnare le persone a un solo progetto per volta.

Overcoming Barriers to Self-Management in Software Team, in IEEE Software, nov/dec 2009.