agile

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

Il numero di September/October 2012 di IEEE Software ha come tema centrale lo sviluppo software Lean (in molti degli articoli della rivista Lean viene messo in relazione a Agile, per evidenziarne affinità e differenze).

L'articolo più interessante è Lean Software Development: a Tutorial di Mary Poppendieck e Michael Cusumano.

Poppendieck è l'autrice che ha pubblicato i testi probabilmente più interessanti sullo sviluppo Lean, come Lean Development Software: An Agile Toolkit for Software Development Managers e Implementing Lean Software Development: From Concept to Cash.

Michael Cusumano, del MIT, Massachussetts Institute of Technology, è da decenni uno degli osservatori più attenti dell'industria del software: il loro tutorial è probabilmente lo scritto più chiaro che sia stato pubblicato finora sull'approccio Lean allo sviluppo software.

Gli Story Points sono un metodo di stima dimensionale usato per misurare e tenere sotto controllo la produttività e la velocità di un gruppo di sviluppo software. Sono molto diffusi negli ambiti di sviluppo "agile".

Una riflessione critica sull'uso degli story points in questo intervento di Joshua Kerievsky, che per certi versi testimonia un'evoluzione verso l'approccio "lean".

In questi giorni è in corso la più importante conferenza internazionale sulle architetture software, Saturn (SEI Architecture Technology User Network), organizzata dal Software Engineering Institute.

Tra gli interventi, una keynote di Michael Stal: Win-Win With Agile Architecture.

"Manifesto for Software Craftsmanship. Raising the bar.

As aspiring Software Craftsmen, we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work, we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left, we have found the items on the right to be indispensable."

"Craftsmanship" si può tradurre con arte, maestria, perizia tecnica. Il manifesto, pubblicato nel 2009, si fonda sul manifesto agile del 2001, e lo reinterpreta spingendo sul fronte della qualità dei prodotti software e del processo di sviluppo.

"Raising the bar", cioè alzando il tiro: non si tratta solo di sviluppare in modo più efficiente e flessibile, ma soprattutto di elevare la qualità di ciò che si fa e di come lo si fa.

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.

Articolo breve e succoso di Johanna Rothman: "Barriers to Agility". Argomenti:

• Scegliere il giusto progetto pilota
• Scegliere il gruppo giusto per il progetto pilota

"Se non avete la possibilità di creare un piccolo gruppo di lavoro multifunzionale, che lavori su un unico progetto, non avete l'ambiente organizzativo giusto per iniziare a operare in modo agile."

L'articolo è apparso su PragPub, una rivista online mensile pubblicata dai Pragmatic Programmers.

Un numero di IEEE Software, March/April 2010, con articoli incentrati sul rapporto tra "agilità" e architettura.

Rilevante un testo di Roland Faber, "Architect as Service Providers", secondo cui gli architetti software devono assumere la responsabilità di soddisfare i requisiti non funzionali, mentre ai progettisti / sviluppatori compete quella di soddisfare i requisiti funzionali.

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