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%).
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.
Non più di dieci
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”.
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’.”