agile

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.

"In other engineering disciplines, the need to produce design documentation is considered de rigeur, a sometimes unpleasant but necessary chore for the sake of higher good. [...]

The primary consumers of design documentation are those who are responsible for maintaining and evolving the system.

[...] we need design documentation at a higher level of abstraction, stripped of unnecessary technological detail and closely coupled to application concepts and requirements. These should incorporate design rationale, including descriptions
of rejected design alternatives. These are, in fact, architectural specifications: technology-independent descriptions of the higher-level structure and behavior of systems along with key design principles."

Bran Selic, Agile Documentation, Anyone?, in IEEE Software, nov/dec 2009.