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.

Software Engineering sorpassato?

Software Engineering: An Idea Whose Time Has Come and Gone?
Tom DeMarco, IEEE Software, July/August 2009

Quanto è importante, quanto decisivo il ruolo delle metriche e dei sistemi di controllo per il successo di un progetto? DeMarco rianalizza uno dei suoi testi più influenti, Controlling Software Projects, del 1982, e ne critica l'impostazione globale.

"The book for me is a curious combination of generally true things written on every page but combined into an overall message that’s wrong.
It’s as though the book’s young author had never met a metric he didn’t like. The book’s deep message seems to be, metrics are good, more would be better, and most would be best. [...]

I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.
Consistency and predictability are still desirable, but they haven’t ever been the most important things."

Lo sviluppo sw è un fatto sociale, più che tecnologico

"As we realize that software development is often more about people - collaboration, communication, and coordination - than technology, developing 'soft skills' such as meeting-management techniques is becoming more important".

Nell'articolo "When Robert Rules", su IEEE Software Jan/Feb 2009, Philippe Krutchen segnala un metodo di gestione delle riunioni pubblicato nel 1896 da un generale USA, Henry M. Robert, e ancora utile oggi, le Robert's Rules of Order.

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'."

La partecipazione degli utenti ai progetti

Erica L. Wagner and Gabriele Piccoli:"Moving Beyond User Participation to Achieve Successful IS Design" in Communications of the ACM, december 2007

L'articolo mette in luce con estrema chiarezza uno dei nodi principali dello sviluppo software.

"We suggest that rather than fighting human nature by trying to force the participation of user groups throughout a project, we should broaden our thinking about development and implementation methodologies to reflect what happens in practice. We find that in practice user participation can be most powerful after ‘go live’ when users are truly engaged.

[...] we acknowledge it will be difficult to fully engage users before the software begins to affect their daily lives, which are generally at ‘go live.’ Yet, we are not suggesting there is no value in user involvement via prototyping or phased roll-out techniques. When properly implemented, these techniques can help increase communication, provide some valuable feedback in the design process, and generally improve goodwill on the user side. But it is critical to recognize that trying to force engagement of user groups throughout a project goes against human nature. We should therefore expand our thinking about the stages of the systems development life cycle, and incorporate this broadened perspective into whichever methodology is used.
We need to recognize that implementation extends beyond “flipping the switch.” Legitimizing the post-implementation activities that are often kept as a shameful secret — a sign of project failure — will help to manage expectations and avoid much of the conflict that erodes trust between the user community, project champions, and the development team by more naturally mimicking human behavior.

[...] It is time to speak honestly about the gap between our intentions to build working systems and our ability to do so in practice. This gap is typically not caused by a lack of effort on behalf of developers or users, but rather is the result of misdirected efforts. The systems development and implementation process will continue to be overly challenging if we work against the tide by trying to make users fit our theories of how and when they should participate in development initiatives."

Theoretical Reflections on Agile Development Methodologies

Sridhar Nerur e VenuGopal Balijepally, "Theoretical Reflections on Agile Development Methodologies", Comm ACM 03-2007 . Con una lista di riferimenti eccellente.

"The progression of thought in software development parallels the maturation of design ideas in architecture and strategic management. The traditional mechanistic worldview is today being challenged by a newer agile perspective that accords primacy to uniqueness, ambiguity,
complexity, and change, as opposed to prediction, verifiability, and control. The goal of optimization is being replaced by flexibility and responsiveness.
[...]

The tenets of agile methods depart from the traditional orthodoxy of software development. This shift in philosophy is not unusual, as similar patterns of intellectual evolution have emerged in other disciplines. A look at architecture and strategic management reveals that
the progression of ideas in them is remarkably similar to conceptual pattern shifts in software design."

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

Dilbert - project management

Dilbert su PMI Journal (3-11-06 Scott Adams.)

Boss: Yesterday I had a great meeting about project Wombat.
Dilbert: What?! I've been managing that project for six months! How can you have a meeting without inviting me? !!
Greta: Have you noticed that meetings go smoother without any knowledge or expertise?
Boss (very small font): Kinda.