Ostacoli all'agilità

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.

Architettura e agile

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.

Bob Martin sulle certificazioni agili

http://blog.objectmentor.com/articles/2010/04/21/the-r-e-a-l-i-t-y-principles-of-agile-software-certification

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.

Documentazione agile

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

Lean Primer

Una introduzione sintetica ed efficace al pensiero "lean", di Craig Larman e Bas Vodde.

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.

Usabilità, requisiti e progetti agili

Jakob Nielsen è un esperto di usabilità. Nella sua newsletter Alertbox parla del rapporto tra usabilità e approcci agili. L'argomentazione di Nielsen prende l'avvio dai requisiti:

"Requirement specifications are always wrong.

At best — when derived with care — the requirements might reflect what
users want. More commonly, however, they reflect the desires of user
'representatives' who are too far removed from the coalface to know the
details of the real work. In any case, what users want and what users need
are two different things, which is why it's long been a primary usability
guideline to watch what users do, rather than listen to what they say".

CMMI e Agile

Il Software Engineering Institute (SEI) è un'istituzione finanziata dal governo e da grandi aziende USA. Nei corsi che tengo sono solito raccomandare il sito del SEI come una delle fonti più autorevoli di documentazione sulle tematiche dello sviluppo software. Documenti di alta qualità, e gratuiti.

Tra le altre cose, il SEI è noto per aver creato il CMMI-SW (Capability Maturity Model Integration), un modello per la valutazione del grado di maturità delle organizzazioni che sviluppano software. Modello applicato dal governo americano e da molte organizzazioni internazionali per selezionare i propri fornitori nello sviluppo software.

Il CMMI-SW è spesso ritenuto, a torto, come un modello che porta a burocratizzare lo sviluppo, pesante e con effetti negativi sulla produttività e sulla flessibilità. Può essere applicato così, è vero. Ma pesantezza e burocrazia non sono affatto insite nel modello, bensì sono causate da chi lo interpreta in modo superficiale.

Una recente pubblicazione del SEI, "CMMI or Agile: Why Not Embrace Both!" evidenzia la compatibilità del CMMI con gli approcci agili.

Moscow e priorità

Il primo corso a cui partecipai sull'analisi dei sistemi - tanti anni fa - insegnava ad usare per i requisiti una classificazione MoSCoW.

MoSCoW è un acronimo che sta per:
* Must have - si deve avere
* Should have - si dovrebbe avere
* Could have - si potrebbe avere
* Won't have - non si deve avere

Non ho mai usato la classificazione MoSCoW, anche se suggestiva. E non l'ho mai insegnata nei miei corsi. Ho sempre usato la tecnica di classificare i requisiti in termini di priorità, che ritenevo più efficace.

In realtà, comunque, non mi sono mai messo a ragionare a fondo sulla classificazione MoSCoW. L'ha fatto invece James Shore, in un intervento che condivido.

Incremental Commitment Model

Barry Boehm e Jo Ann Lane: "Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering", in CrossTalk, October 2007

Many projects have difficulties in integrating their hardware, software, and human factor aspects.

In comparison to the software-intensive RUP, the ICM also addresses hardware and human factor integration. It extends the RUP phases to cover the full system life cycle: An Exploration phase precedes the RUP Inception phase, which is refocused on valuation and investment analysis. The RUP Elaboration phase is refocused on architecting (a term based on describing concurrent development of requirements, architecture, and plans),
which adds feasibility evidence; the RUP Construction and Transition phases are combined into the Development phase; and an additional Operation phase combines
operations, production, maintenance, and phase-out. Also, the names of the milestones
are changed to emphasize that their objectives are to ensure stakeholder commitment
to proceed to the next level of resource expenditure based on a thorough feasibility and risk analysis, and not just on the existence of a set of system objectives and a set of architecture diagrams. Thus, the RUP Life-Cycle Objectives (LCO) milestone is called the Architecture Commitment Review (ACR) in the ICM, and the RUP Life-Cycle Architecture (LCA) milestone is called the Development Commitment Review (DCR).

In comparison to the sequential waterfall and V-model, the ICM explicitly does the following:
• Emphasizes concurrent engineering of requirements and solutions.
• Establishes feasibility rationales as pass/ fail milestone criteria.
• Enables risk-driven avoidance of unnecessary documents, phases, and reviews.
• Provides support for a stabilized current-increment development concurrently with a separate change processing and rebaselining activity to prepare for appropriate and stabilized development of the next increment.

Agile è troppo rigido...

Kunal Mittal Executive Director, IT, Sony Pictures Entertainment: The software development life cycle for Web 2.0. Realize the benefits of agile development.

"You've probably read about extreme programming, Scrum, and other agile development processes. To me, those are also probably too rigid [...] User stories, iterative development and releases, and a simple planning game are the key elements of your new process. It's also a good idea to include a quality assurance and testing cycle, as well as user-acceptance testing."

Secondo me, esagera. Ma è indicativo del fatto che l'approccio agile è ritenuto ormai consolidato.

Lo sviluppo in team distribuiti a livello internazionale

Michael Cusumano: 'Managing Software Development in Globally Distributed Teams' in Communications of the ACM, February 2008.

Cusumano raccomanda uno sviluppo agile, basato su un contratto "iterativo" tra cliente e fornitore, con definizione progressiva dei requisiti e distribuzione guidata dalle scelte architetturali.

Nulla di nuovo e di rilevante, se non un segnale di quanto gli approcci agili siano ormai considerati come la base necessaria anche per lo sviluppo software distribuito.

Patterns of Agile Adoption

Un articolo di Mike Cohn su Agile Journal delinea alcuni possibili percorsi per modificare il processo di sviluppo di un'organizzazione verso una maggiore agilità.

Cohn descrive tre coppie di alternative:

• partire con progetti pilota o intervenire contemporaneamente su tutti i progetti ("Start Small or go All In?")
• iniziare dalle pratiche agili più "tecniche" o partire dall'approccio iterativo ("Technical Practices First or Iterative First?")
• partire di nascosto o pubblicizzare in anticipo il cambiamento ("Stealth Mode or a Public Display of Agility?")

Per ognuna delle alternative, vengono elencati vantaggi e svantaggi.

Scrum e pattern organizzativi

Un altro materiale interessante relativo a Scrum è stato prodotto da Jim Coplien. Coplien è, tra le altre cose, autore del testo fondamentale sui pattern organizzativi, cioè sui principi guida organizzativi per lo sviluppo software.
James Coplien, Neil Harrison: Organizational Patterns of Agile Software Development, Prentice-Hall 2005 (il titolo è purtroppo fuorviante, in quanto il testo non parla in specifico dei processi agili, ma dei pro e dei contro delle diverse modalità di organizzare lo sviluppo software).

A proposito di Scrum, è disponibile (sul sito di Jeff Sutherland, uno degli originatori di Scrum) una recente presentazione di Coplien che mappa Scrum ai pattern organizzativi, e ne evidenzia la necessità di un'adozione consapevole.

Scrum scalabile

Scrum è un processo agile nato per fare fronte in modo controllato a situazioni progettuali con requisiti poco determinati, e instabili. Dato che si tratta di situazioni progettuali comuni, Scrum si sta diffondendo.

Un articolo di Scott Ambler sottolinea la necessità di riflettere sulle modalità di adozione di Scrum nelle organizzazioni, sfruttandone i vantaggi ma senza dimenticare gli insegnamenti di decenni di storia dell'Information Technology e dello sviluppo software.

CMMI + altri metodi e standard

Se si cerca la soluzione unica e definitiva ai problemi dello sviluppo e della gestione dei sistemi informatici, può capitare di pensare che CMMI (Capability Maturity Model Integration), ISO, ITIL, CoBIT, Six Sigma, lean, processi agili, ecc. siano tra loro alternativi. Non è così, afferma Mike Phillips del Software Engineering Institute, che chiarisce le relazioni tra i diversi approcci al miglioramento dell'IT.

Per analisi più dettagliate delle relazioni tra CMMI e altri approcci, un buon punto di partenza è questo.

Software Quality Requirements

Il numero di IEEE Software di Marzo-Aprile 2008 ha come tema centrale la gestione dei requisiti di qualità.

Tra gli spunti, un confronto tra Tom Gilb e Alistair Cockburn sulla precisazione i requisiti. Gilb sostiene l'esigenza di quantificare, Cockburn ritiene che in un contesto agile non sia il caso di farlo, e che in alcuni casi possa risultare dannoso.
A differenza di quanto normalmente accade, l'esito del confronto non è per nulla conciliatorio, segno di un contrasto profondo tra i rispettivi punti di vista.

CMMI e processi agili

Un sondaggio curato da Scott Ambler per la Dr. Dobb's Agile Newsletter.

Inoltre, una serie di articoli sui processi adeguati per i progetti brevi sul numero di febbraio 2008 di CrossTalk, the Journal of Defense Software Engineering. Tra cui un articolo di Capers Jones che mette in rapporto CMMI e processi agili.

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