Archivi categoria: project management

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.

Fasi dell’approccio agile

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.

Chaos Report 2009

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.

Self-Management dei gruppi di lavoro

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

Modello Metropoli

Proposto da Rick Kazman e Hong-Mei Chen, come modello di sviluppo software distinto rispetto ai modelli waterfall, evolutivo ed agile.

Il modello Metropoli è adatto a progetti di sviluppo di sistemi “crowdsourced”, cioè quelli in cui il ruolo del contributo di volontari è fondamentale. Due categorie principali:

  • prodotti open source, come Linux, Apache, Firefox, ecc.
  • “community-based service systems”, come Wikipedia, YouTube, Facebook, ecc.

Per entrambe queste categorie di sistemi, esiste una distinzione rigorosa tra l’evoluzione del kernel e l’evoluzione delle altre parti più periferiche, che si articola in gestioni dei requisiti e delle scelte architetturali da effettuare su due piani distinti.

The Metropolis Model. A New Logic for Development of Crowdsourced Systems“, in Communications of the ACM, 07/2009.

Evolutionary System Development

Un articolo di Peter Denning, Chris Gunderson e Rick Hayes-Roth, tre esperti IT di lungo corso che lavorano attualmente per la US Navy, la marina statunitense, segna a mio avviso una tappa importante nel percorso verso la piena affermazione dei processi agili.

“The software engineering community has hotly debated preplanned versus agile processes. After a while they reached a truce where they agreed that preplanning is best for large systems
where reliability and risk-avoidance are prime concerns, and agile is best for small to medium systems where adaptability and user friendliness are prime concerns.
We challenge that conclusion. Preplanning is ceasing to be a viable option for large systems. […]

Whereas preplanned development seeks to avoid risks, evolutionary development mimics nature and embraces risks. The developers purposely expose emerging systems to risks to see how they fail, and then they build better system variants. It is better to seek risk out
and learn how to survive it. […]
All the evidence says that that evolutionary processes works for systems large and small, and that risk seeking is the fastest route to fitness. There is too much at stake to continue to allow us to be locked into a process that does not work.”

L’articolo è stato pubblicato nel numero di dicembre 2008 di Communications of the ACM.

PMBOK 4

Nuova edizione del Project Management Book of Knowledge (PMBOK), la quarta, uscita il 31-12-2008.

Il Project Management Institute (PMI) ha pubblicato un contemporaneo aggiornamento anche di altri tre propri standard:

  • Organizational Project Management Maturity Model (OPM3)
  • Program Management
  • Portfolio Management

Un aspetto di cronaca: il prezzo praticato dal PMI ai propri soci per acquistare lo standard è superiore a quello praticato da Amazon.

Lo saprò quando lo vedrò

Barry Boehm – Making a Difference in the Software Century

Un eccellente articolo su IEEE Computer, marzo 2008 (in realtà, si tratta di un estratto della introduzione scritta da Boehm per l’antologia dei propri scritti, pubblicata nel 2007 da IEEE CS Press-John Wiley & Sons ).


Riporto un paio di passi.

Il primo, sulla difficoltà per gli utenti di chiarire i requisiti in anticipo :

“Spesso, quando si chiede agli utenti di specificare come vorrebbero interagire con una nuova applicazione, essi rispondono “Lo saprò quando la vedrò” (IKIWISI – I’ll Know It When I See It). In questi casi, usare un modello a cascata sequenziale, specificare-prima-i-requisiti, diventa di solito la ricetta per un sistema inefficace e per un mucchio di costosi rifacimenti”.


Il secondo, sul conflitto tra punti di vista ed interessi tra gli stakeholder di progetto:

“Il fatto che ci siano molti conflitti potenziali tra i principali stakeholder significa che il progetto può entrare in situazioni in cui uno vince e un altro perde. E una situazione del genere di solito diventa una situazione in cui perdono tutti.

In situazioni simili è importante gestire le aspettative degli stakeholder, lavorare di più per assicurare che la soluzione proposta sia fattibile e adeguata agli interessi di tutti, e negoziare un insieme globalmente soddisfacente e vantaggioso di specifiche, piani e risorse, prima di procedere con lo sviluppo. Quando si negoziano i requisiti, nei momenti iniziali è meglio sostituire termini che possono essere interpretati come non negoziabili, ad esempio il termine ‘requisiti’ (cose richieste con autorità e diritto) con parole come ‘obiettivi’ e ‘scopi’.”

Project Management – Ivo Andric

Da “Il ponte sulla Drina” di Ivo Andric, Meridiani Mondadori 2001, pag. 592:

La primavera dell’anno in cui il visir prese la decisione di costruire il ponte, arrivarono a Visegrad i suoi uomini con il seguito per i preparativi necessari. Erano in molti, con cavalli, carri, macchinari di tutti i generi e tende. […].
Il loro capo era Abid-aga, uomo di fiducia del visir e responsabile della costruzione del ponte insieme a Tosun-efendija, l’architetto. (Di Abid-aga già prima del suo arrivo si diceva che fosse un uomo crudele, senza scrupoli.) Non appena si furono sistemati nelle tende sotto Mejdan, Abid-aga convocò le autorità locali e i notabili musulmani per discutere con loro sul da farsi. In realtà non vi fu discussione, perché parlò uno solo, Abid-aga.

‘Sono certo che prima del mio arrivo vi sono giunte voci sul mio conto, e so che non sono belle né piacevoli. Vi avranno sicuramente detto che esigo lavoro e obbedienza assoluta e sono pronto a frustare o a uccidere chiunque non lavori come si deve e non obbedisca senza sollevare obiezioni, che non conosco il significato di frasi come “non è possibile” e “non c’è”, che con me una testa può cadere anche per una parola insignificante, insomma che sono un uomo sanguinario e malvagio.
Voglio confermarvi che queste voci non sono né inventate né esagerate. E’ vero che sotto il mio tiglio non si trova ombra. Mi sono conquistato questa reputazione nel corso di lunghi anni di servizio, eseguendo fedelmente gli ordini del gran visir. A Dio piacendo eseguirò altrettanto bene il lavoro per cui sono stato inviato qui e spero che, quando avrò portato a termine la mia missione e sarò ripartito, le voci che mi seguiranno saranno anche peggiori e più terribili di quelle che sono giunte alle vostre orecchie.’