Archivi categoria: project management

Agilità vera e falsa

Agilità vera e falsa. Ora che essere agili è di moda, due riflessioni su cosa implica essere agili davvero.

La prima, stringata e acuta, su The Economist del 5 luglio 2018: The fashion for agile management is spreading, si diffonde la moda del management agile.

Con un commento arguto sull’uso del termine Scrum nel lavorare in gruppi:

Somehow, the teams concept acquired the name “scrum”. This moniker was clearly bestowed by someone who had never seen a real rugby game. An actual scrum involves 16 people pushing hard, getting nowhere and usually ending up collapsing or being penalised by the referee for foul play.

In qualche modo, il concetto di lavoro in gruppo ha acquisito il termine “scrum”. Questo termine è stato chiaramente conferito da qualcuno che non aveva mai visto una vera partita di rugby. Una mischia (scrum) vera coinvolge 16 persone che spingono forte, non arrivano da nessuna parte e di solito finiscono per cascare giù o essere penalizzate dall’arbitro per il gioco scorretto.

La seconda riflessione, più articolata e approfondita, viene da Martin Fowler, uno tra i firmatari del Manifesto Agile del 2001,  nell’intervento The State of Agile Software in 2018 (dove si può leggere la trascrizione di una presentazione effettuata nella conferenza Agile Australia).

On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile’s values and principles. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects). Despite the problems, the community’s great strength is its ability to learn and adapt, tackling problems that we original manifesto authors didn’t imagine.

In superficie, il mondo dello sviluppo agile del software è brillante, dal momento che è ormai accettato ovunque. Ma la realtà è preoccupante, perché gran parte di ciò che viene fatto è finto-agile, ed ignora i valori e i principi dell’agile.
Le tre principali sfide su cui dovremmo concentrarci sono: la lotta contro il Complesso Industriale Agile e l’abitudine di imporre dall’esterno i processi ai gruppi di lavoro; aumentare l’importanza dell’eccellenza tecnica; organizzare i nostri team in base ai prodotti (piuttosto che ai progetti).
Nonostante i problemi, la grande forza della comunità è la sua capacità di apprendere e adattarsi, affrontando problemi che noi autori del manifesto originale non immaginavamo.

Da leggere.

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