Principi e valori di Agile di Jeff Sutherland

Jeff Sutherland ha inventato la metodologia Scrum nel 1993 e ha collaborato con Ken Schwaber per formalizzarla all'OOPSLA'95. Insieme hanno esteso e migliorato Scrum in molte società di software ed hanno contribuito alla scrittura del Manifesto Agile. Nel blog di Jeff Sutherland, all'indirizzo http://scrum.jeffsutherland.com, vengono esaminate le origini e le procedure consigliate della metodologia Scrum.

Lo sviluppo Agile è un termine derivato dall'Agile Manifesto, scritto nel 2001 da un gruppo di cui facevano parte gli autori di Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) e Crystal, un rappresentante dello sviluppo basato su funzionalità e molti altri guru nel settore del software. L'Agile Manifesto ha definito un set comune di valori e principi generali per tutte le singole metodologie Agile dell'epoca. Nel documento sono specificati i quattro valori fondamentali per la creazione di team ad alte prestazioni.

• Individui e reciproche interazioni

• Distribuzione di software funzionante

• Collaborazione del cliente

• Risposta al cambiamento

Questi valori fondamentali sono supportati da dodici principi che è possibile reperire presso il sito Web seguente: Manifesto for Agile Software Development (informazioni in lingua inglese).

Questi valori non sono stati semplicemente approvati a parole dagli autori dell'Agile Manifesto per essere subito dopo dimenticati. Si tratta di valori operanti. L'approccio di ogni singola metodologia Agile a questi valori è leggermente diverso, ma tutte le metodologie dispongono di processi e pratiche specifici per la promozione di uno o più di questi valori.

Individui e interazioni

Gli individui e le interazioni sono essenziali per la creazione di team ad alte prestazioni. Studi sulla "saturazione della comunicazione" durante un progetto hanno evidenziato che, quando non esistono problemi di comunicazione, i team sono 50 volte più produttivi rispetto alla media del settore. Per facilitare la comunicazione, i metodi Agile si basano su cicli frequenti di controllo e adattamento. La frequenza di questi cicli può variare da pochi minuti con programmazione di coppia, a poche ore con integrazione continua, fino ad ogni giorno con riunione giornaliera e a ogni iterazione con revisione e analisi retrospettiva.

Commenti e comunicazione più frequenti non sono tuttavia sufficienti per eliminare i problemi di comunicazione. Questi cicli di controllo e adattamento funzionano solo in presenza di diversi comportamenti principali da parte dei membri del team, quali:

• rispetto per il valore di ogni persona;

• sincerità nel corso delle comunicazioni;

• trasparenza di tutti i dati, azioni e decisioni;

• fiducia che ogni persona supporterà il team;

• impegno nei confronti del team e dei suoi obiettivi.

Perché questi tipi di comportamento possano svilupparsi, è necessario che la gestione Agile fornisca un ambiente d'appoggio, il responsabile del team faciliti la loro inclusione e i membri del team li esibiscano. Solo allora i team saranno in grado di realizzare il loro potenziale completo.

L'adozione di questi tipi di comportamento è più difficile di quanto possa sembrare. La maggior parte dei team evita di fare affidamento su sincerità, trasparenza e fiducia a causa di norme culturali o per esperienze negative pregresse di conflitto generato da comunicazioni oneste. Per contrastare queste tendenze è necessario che la leadership e i membri del team facilitino un conflitto positivo. Oltre a creare un comportamento produttivo, un approccio simile dispone di molti altri vantaggi:

• Il miglioramento del processo dipende dalla capacità del team di generare un elenco di impedimenti o problemi nell'organizzazione, affrontarli in modo diretto ed eliminarli sistematicamente in ordine di priorità.

• L'innovazione si realizza solo in presenza del libero scambio delle idee in conflitto, come hanno studiato e documentato Takeuchi e Nonaka, fondatori di Scrum.

• Per allineare il team verso un obiettivo comune, è necessario che il team faccia affiorare e risolva i programmi in conflitto.

• L'impegno collaborativo si verifica solo quando le persone sono d'accordo sugli obiettivi comuni e cercano di migliorare sia a livello personale che come team.

Questo ultimo punto in merito all'impegno è particolarmente importante. Solo quando sono impegnati, gli individui e i team coinvolti nello sviluppo del software si sentono responsabili del risultato finale, ovvero della distribuzione di valore elevato. Le metodologie Agile facilitano l'impegno incoraggiando i team a prelevare il lavoro da un elenco di operazioni classificate per ordine di priorità, gestire il proprio lavoro e concentrarsi sul miglioramento delle pratiche operative. Questa pratica è la base dell'auto-organizzazione che costituisce la forza propulsiva per la realizzazione di risultati in un team Agile.

Per creare team ad alte prestazioni, le metodologie Agile valutano utenti e interazioni in relazione a processi e strumenti. Da un punto di vista pratico, tutte le metodologie Agile cercano di accrescere il livello di comunicazione e collaborazione tramite cicli frequenti di controllo e adattamento. Questi cicli sono tuttavia utili solo quando i leader Agile incoraggiano il conflitto positivo necessario per lo sviluppo di una base solida di sincerità, trasparenza, fiducia, rispetto e impegno nei team Agile.

Software funzionante rispetto alla documentazione completa

Il software funzionante costituisce una delle grandi differenze apportate dallo sviluppo Agile. Tutte le metodologie Agile rappresentate nell'Agile Manifesto enfatizzano la distribuzione al cliente di piccole parti di software funzionante a intervalli predefiniti.

Tutti i team Agile devono stabilire il loro significato di "software funzionante", spesso noto come "definizione di risultato". A un livello elevato, una parte di funzionalità può essere definita completa solo quando le sue caratteristiche superano tutti i test e possono essere utilizzate da un utente finale. A un livello minimo, è necessario che i team superino il livello degli unit test ed eseguano i test a livello di sistema. Nella definizione dello scopo da perseguire con una parte di funzionalità, i migliori team includono anche i test di integrazione, prestazioni e accettazione da parte del cliente.

Raccogliendo una serie di dati estesi su molti progetti, una società con certificazione CMMI di livello 5 ha dimostrato che definendo test di accettazione insieme alla funzionalità, implementando le funzionalità in serie e in ordine di priorità, eseguendo immediatamente i test di accettazione per ogni funzionalità e correggendo gli eventuali bug identificati come massima priorità, è in grado di raddoppiare sistematicamente la velocità di produzione e di ridurre gli errori del 40%. Il risultato viene ottenuto da una società che vanta già una delle percentuali di errore più basse nel mondo.

Nell'Agile Manifesto si consiglia ai team di distribuire software funzionante a intervalli predefiniti. L'accordo su una definizione di risultato rappresenta uno dei modi pratici con cui i team Agile producono le prestazioni e la qualità elevate necessarie per realizzare questo obiettivo.

Collaborazione del cliente rispetto alla negoziazione contrattuale

Negli ultimi venti anni, la percentuale di riuscita dei progetti è più che raddoppiata in tutto il mondo. Il risultato viene attribuito a progetti di dimensioni più ridotte e distribuzioni frequenti che consentono al cliente di fornire suggerimenti sul software funzionante a intervalli regolari. Gli autori del manifesto non sbagliavano quando enfatizzavano che il coinvolgimento del cliente nel processo di sviluppo del software è essenziale per la riuscita del progetto.

Le metodologie Agile promuovono questo valore consentendo ai clienti di sostenere il lavoro in collaborazione con il team di sviluppo. Il primo team Scrum aveva ad esempio migliaia di clienti. Poiché non era possibile coinvolgerli tutti nello sviluppo del prodotto, fu selezionato un procuratore dei clienti, denominato proprietario del prodotto, incaricato di rappresentare non solo tutti i clienti nel campo, ma anche i servizi di gestione, vendite, assistenza, clienti e le altre parti interessate. Il proprietario del prodotto era responsabile per l'aggiornamento dell'elenco di requisiti ogni quattro settimane quando il team rilasciava il software funzionante, in considerazione della realtà corrente e dei commenti effettivi dei clienti e delle parti interessate. In questo modo il cliente ha contribuito a forgiare il software in fase di creazione.

Il primo team XP fu avviato per un progetto IT interno e riuscì ad assicurarsi la collaborazione giornaliera nel team di un utente finale della società. Il 10% circa delle volte le consulenze e i team interni riescono a trovare un utente finale che può collaborare quotidianamente con il team. Nell'altro 90% dei casi devono nominare un procuratore. Questo procuratore del cliente, che i team XP definiscono "cliente", collabora con gli utenti finali per fornire un elenco chiaro, classificato in ordine di priorità, delle funzionalità che gli sviluppatori devono implementare.

La collaborazione giornaliera con il cliente o con il procuratore del cliente è uno dei motivi principali per cui i dati di settore mostrano che la percentuale di riuscita dei progetti Agile è mediamente più che raddoppiata rispetto a quella dei progetti tradizionali in tutto il mondo. Consapevoli di ciò, le metodologie Agile hanno pertanto creato nei team di sviluppo una posizione specifica per il rappresentante del cliente.

Risposta al cambiamento rispetto all'adesione a un piano

La risposta al cambiamento è essenziale per creare un prodotto in grado di soddisfare il cliente e fornire un valore aziendale. I dati di settore mostrano che durante lo sviluppo del software oltre il 60% di requisiti del prodotto o del progetto subiscono modifiche. Anche quando i progetti tradizionali vengono completati puntualmente all'interno del budget e contengono tutte le funzionalità pianificate, i clienti spesso non sono soddisfatti perché il risultato ottenuto non corrisponde esattamente a quanto desideravano. Come recita la " legge di Humphrey", i clienti non sanno mai cosa desiderano fin quando non vedono il software funzionante. Se i clienti non vedono il software funzionante fino alla fine di un progetto, sarà troppo tardi per incorporare i loro suggerimenti. Le metodologie Agile perseguono i commenti del cliente nel corso dell'intero progetto in modo da poter incorporare suggerimenti e nuove informazioni durante lo sviluppo del prodotto.

Tutte le metodologie Agile dispongono di processi incorporati per modificare i piani a intervalli regolari in base ai commenti forniti dal cliente o dal suo procuratore. I piani vengono progettati per fornire sempre innanzitutto il valore aziendale più elevato. Poiché l'80% del valore risiede nel 20% delle funzionalità, i progetti Agile eseguiti correttamente tendono a terminare velocemente, laddove la maggior parte dei progetti tradizionali vengono completati in ritardo. Di conseguenza, i clienti sono più soddisfatti e gli sviluppatori lavorano con maggiore piacere. Le metodologie Agile sono basate sulla consapevolezza che, per riuscire, è necessario pianificare il cambiamento. Per questo motivo, hanno stabilito processi, quali revisioni e analisi retrospettive, specificatamente progettati per modificare periodicamente le priorità in base ai commenti dei clienti e al valore aziendale.

Agile è l'ombrello, le metodologie sono le implementazioni

Lo sviluppo Agile non è di per sé una metodologia. Si tratta piuttosto di un termine generico che descrive diverse metodologie Agile. Al momento della sottoscrizione dell'Agile Manifesto nel 2001, tali metodologie includevano Scrum, XP, Crystal, FDD e DSDM. Da allora, come utile metodologia Agile sono emerse anche le pratiche Lean, che vengono pertanto incluse sotto il termine generico di sviluppo Agile nell'illustrazione riportata più avanti in questo argomento.

Come molti linguaggi di programmazione manifestano le funzionalità principali della programmazione orientata agli oggetti in modi diversi, ugualmente ogni metodologia Agile dispone di un approccio leggermente diverso per l'implementazione dei valori principali dell'Agile Manifesto. In base ai dati di un recente sondaggio, il 50% circa dei professionisti Agile si avvale della metodologia Scrum nei team. Un altro 20% utilizza Scrum con componenti XP e un ulteriore 12% utilizza solo XP. Poiché le implementazioni Agile sono Scrum o XP per oltre l'80% in tutto il mondo, MSF for Agile Software Development v5.0 si concentra sui processi e sulle pratiche principali di Scrum e XP.

Scrum è un framework per i processi di sviluppo Agile, che non include procedure di progettazione specifiche. Viceversa, XP si concentra sulle procedure di progettazione ma non include un framework generale dei processi di sviluppo. Ciò non vuol dire che Scrum non consigli determinate procedure di progettazione o che XP non disponga di processi. Nel primo progetto Scrum ad esempio erano implementate tutte le procedure di progettazione ora note come XP. Il framework Scrum per lo sviluppo del software era tuttavia progettato in modo che un team venisse avviato in due o tre giorni, laddove le procedure di progettazione spesso richiedono molti mesi per l'implementazione. La decisione di quando, e se, implementare procedure specifiche era pertanto demandata a ogni team. I creatori di Scrum, Jeff Sutherland e Ken Schwaber, consigliano di avviare i team Scrum immediatamente e di creare un elenco di impedimenti e un piano di miglioramento del processo. Quando procedure di progettazione vengono identificate come impedimenti, i team devono utilizzare le procedure XP come una modalità di miglioramento. I migliori team eseguono la metodologia Scrum integrata con le procedure XP. Scrum consente l'escalation a XP e XP consente l'esecuzione efficace di Scrum.

Nella tabella riportata di seguito viene illustrato come è possibile scambiare i termini principali nelle metodologia Scrum e XP.

Scrum	XP
proprietario del prodotto	cliente
scrum master	coach XP
team	team
sprint	iterazione
riunione pianificazione sprint	gioco di pianificazione

Vedere anche

Concetti

Pianificazione e rilevamento di progetti

Altre risorse

MSF for Agile Software Development v5.0