Metodologie di sviluppo Agile

Panoramica generale sulle metodologie Agile principali.

Approccio Agile nello sviluppo software

Sviluppo agile è un termine che deriva dall’Agile Manifesto, che fu scritto nel 2001 da un gruppo di esperti per riuscire a formalizzare i valori e principi che muovono lo sviluppo software. In prima istanza all’interno del manifesto si eleggono quattro valori principali per permettere ai gruppi di lavoro di raggiungere il massimo delle loro prestazioni:

  • Individui e loro interazioni (aumentando la frequenza e la qualità delle comunicazioni e dei feedback)
  • Consegnare software funzionante
  • Collaborare col cliente
  • Rispondere al cambiamento

 

Questi valori sono supportati da 12 principi, che sono riportati in appendice per motivi di spazio.

Metodologie di sviluppo agile

Di per sé “Agile” rappresenta soltanto un insieme di valori e principi. All’atto pratico occorre convertire tali principi in metodologie e tecniche di gestione del team.  Il termine “Agile umbrella”, coniato per descrivere metaforicamente il concetto, indica come sotto la stessa visione siano presenti diverse metodologie di lavoro.

 

L’interpretazione del concetto di “Agile” come “ombrello” di tecnologie”

Ciascuna implementazione presenta peculiarità significative e consistenti rispetto alle altre, che in molti casi possono portare a risultati equivalenti, mentre in altri no. La scelta della metodologia di lavoro risulta quindi molto importante e presenta una delle principali difficoltà nell’applicare in contesti quotidiani l’approccio agile. Da un punto di vista statistico la metodologia più diffusa secondo recenti sondaggi è scrum ed include circa il cinquanta per cento dei casi.

 

# Percentuale utilizzo Tecnologia
1 50 Scrum
2 20 Scrum+XP
3 12 XP
4 8 Altro (Crystal,FDD,DSDM,etc.)

Scrum

Con il termine Scrum si fa riferimento ad un framework, che consente a chi ne fa uso di risolvere problemi di tipo adattivo, e al tempo stesso di gestire progetti in modo efficace e produttivo. All’interno del framework possono essere usate più tecniche e processi che servono per lo sviluppo del software e dei sistemi nel loro complesso.

Il framework Scrum è costruito da team e da ruoli, e da eventi, artefatti e regole ad essi associati. Ogni parte dello Scrum ha uno specifico ruolo dal quale dipende il successo e l’utilizzo dello Scrum stesso. La teoria sulla quale il framework si basa è l’empirismo, il quale afferma che la conoscenza deriva dall’esperienza e quindi le decisioni si basano su ciò che si conosce. Seguendo tale logica, Scrum usa un metodo iterativo ed un approccio incrementale per ottimizzare la predicibilità e il controllo del rischio. I principi cardine sui quali si fonda l’implementazione del controllo empirico di processo sono: trasparenza, ispezione ed adattamento.

Le componenti del modello di Team in Scrum sono:

  • Product owner
  • Team di sviluppo
  • Scrum master

Tale modello è progettato per ottimizzare  la flessibilità, la creatività e la produttività.

Gli artefatti degli Scrum Team sono rilasciati in modo iterativo ed incrementale.

Il Product owner ha il compito di massimizzare il valore del prodotto e del lavoro svolto dal Team di sviluppo, del quale sarà responsabile soltanto il Product owner. In ambito anziendale, spesso il product owner è interno all’azienda che commissiona il progetto, anche nel caso in cui il progetto sia dato in outsourcing.

I team di sviluppo sono composti da professionisti che lavorano per produrre un incremento “Fatto” di prodotto potenzialmente rilasciabile alla fine di ogni Sprint. Il team deve essere sinergico per ottimizzare la propria efficienza ed efficacia, autoorganizzato e crossfunzionale. Lo Scrum Master ha il compito di assicurare che Scrum sia compreso ed approvato; per questo deve controllare che i valori, le pratiche e le regole dello Scrum siano rispettati dallo Scrum Team.

Sprint

Lo sprint è un’unità di base dello sviluppo in Scrum ed ha durata prestabilita, generalmente da una a quattro settimane.

Ogni Sprint è preceduto da una riunione di pianificazione in cui vengono identificati gli obiettivi e vengono stimati i tempi. Durante uno sprint non è permesso cambiare gli obiettivi, quindi le modifiche sono sospese fino alla successiva riunione di pianificazione, in cui potranno essere inserite nel prossimo sprint.

Al termine di ogni sprint il team di sviluppo consegna una versione potenzialmente completa e funzionante del prodotto, contenente gli avanzamenti decisi nella riunione di pianificazione dello sprint.

Lo Sprint è costituito da: lo Sprint planning (durante il quale vengono fissati gli obiettivi  e le strategie per mettere in opera il progetto), il Daily Scrum (che serve per sincronizzare le attività), il lavoro di sviluppo, la Sprint review (che ha il compito di ispezionare l’incremento e adattare se necessario il Product Backlog) e la Sprint  Retrospective che permette di  valutare lo Scrum Team e di creare eventuali  piani di miglioramento.

 
Fig. 3.2: Il processo di sviluppo in Scrum.

 

Artefatti

Gli artefatti di Scrum rappresentano il lavoro o il valore in diversi modi, tali comunque da essere utili a fornire trasparenza e opportunità di ispezione e adattamento. Gli artefatti definiti da Scrum sono specificatamente progettati per massimizzare la trasparenza delle informazioni, chiavi necessarie ad assicurare ai Team Scrum il successo nella realizzazione di un Incremento “Fatto”.

Xp

Extreme Programming (XP) deve il suo successo al proposito di rendere prioritaria la soddisfazione del cliente. Invece di consegnare il lavoro completo in qualche data imprecisata nel futuro, questo processo fornisce il software man mano che l’utente ne necessita. XP autorizza gli sviluppatori a rispondere con certezza alle mutevoli esigenze del cliente, anche alla fine del ciclo di vita. Come avviene per altre metodologie agili, XP enfatizza il lavoro di squadra, ponendo un focus particolare sull’individuo. I manager, i clienti e gli sviluppatori sono tutti partner alla pari in un team collaborativo. XP promuove un ambiente semplice, ma produttivo, consentendo al gruppo complessivo di essere altamente efficace nella risoluzione di problemi. Il team si autorganizza intorno al problema da risolvere, in modo da trovare la soluzione più efficiente possibile.

XP migliora un progetto software in cinque modi essenziali:

  • comunicazione,
  • semplicità,
  • feedback,
  • rispetto ,

Gli sviluppatori comunicano costantemente con clienti e colleghi, mantenendo il design applicativo semplice e pulito. Attraverso la formalizzazione di test funzionali, essi ottengono feedback fin dal primo giorno di sviluppo.

Alla base di XP, si pone il principio per cui ogni piccolo successo raggiunto dal team, accresce il rispetto da parte del managment per i contributi unici che ogni membro del team riesce a dare.

Tra gli aspetti caratteristici dell’extreme programming vi sono la programmazione a più mani (generalmente in coppia, per permettere di far fronte in maniera pulita al presentarsi di problemi complessi), la verifica continua del programma durante lo sviluppo per mezzo di programmi di test e la frequente reingegnerizzazione del software, di solito in piccoli passi incrementali, senza dover rispettare fasi di sviluppo particolari.

In Figura 3.5 si illustra come si lavora insieme secondo le regole di Extreme Programming. Ai clienti piace essere consapevoli e partecipi all’interno del processo di sviluppo del software, o almeno così dovrebbe essere per progetti critici, mentre gli sviluppatori contribuiscono attivamente, indipendentemente dal livello di esperienza, e i project manager si concentrano sulla comunicazione e le relazioni. Le attività improduttive o non più necessarie sono state tagliate per ridurre i costi e la frustrazione di tutti i soggetti coinvolti.

 

 Il ciclo di vita dello sviluppo software adottando la metodologia Agile XP
Fig. 3.5: Ciclo di lavoro all’interno della metodologia XP

 

Le dodici regole (o pratiche) che sono alla base di Extreme Programming possono essere raggruppate in quattro aree:

 

Feedback a scala fine

  • Pair Programming: due programmatori lavorano insieme su una sola workstation, uno sta alla tastiera e l’altro ragiona sull’approccio e pensa se può funzionare. Questo rende il codice prodotto di migliore qualità, perché tra le altre cose sottopone ad un controllo immediato quanto viene prodotto. I due programmatori devono avere la stessa esperienza ed alternarsi frequentemente per evitare polarizzazioni nel giudizio e nell’operato. Tale tecnica risulta particolarmente efficace nel risolvere problemi complessi o implementare funzionalità strategiche, o comunque che possano avere impatti importanti negli sviluppi futuri, oppure nelle applicazioni mission-critical.
  • Planning Game: è una riunione di pianificazione che avviene una volta per iterazione, tipicamente una volta a settimana.
  • Test Driven Development: i test automatici vengono pensati prima di scrivere il codice. Così le singole funzionalità nascono già certificate del loro funzionamento, e necessitano solo di essere integrate all’interno del progetto.
  • Whole Team: in XP, il “cliente” non è colui che finanzia il progetto, ma la persona che realmente utilizza il sistema, l’utente. Il cliente deve essere presente e disponibile a verificare e valutare il lavoro svolto, fornendo feedback sull’operato degli sviluppatori.

Processo continuo

  • Continuous Integration: Integrare continuamente i cambiamenti al codice anticipa i problemi di integrazione e permette di risolverli “passo-passo”
  • Refactoring o Design Improvement: riscrivere il codice senza alterarne le funzionalità esterne, cambiando l’architettura, in modo da renderlo più semplice e generico.
  • Small Releases: la consegna del software avviene tramite frequenti rilasci di funzionalità che creano del valore concreto

 

Comprensione condivisa

  • Coding Standards: si impone di scegliere ed utilizzare un preciso standard di scrittura del codice. Questo rappresenta un insieme di regole concordate, che l’intero team di sviluppo accetta di rispettare nel corso del progetto.
  • Collective Code Ownership: ognuno è responsabile di tutto il codice; quindi contribuisce alla stesura chiunque sia coinvolto nel progetto. A partire da questo approccio non è più possibile scaricare le responsabilità sul singolo individuo, mentre si responsabilizza il singolo a non commettere leggerezze nel pieno rispetto reciproco.
  • Simple Design: i programmatori dovrebbero utilizzare un approccio del tipo K.I.S.S. (keep It Simple but not Simplistic) alla progettazione software, ovvero, con il cliente, individuare la soluzione più semplice che risolva il problema. Su questo tema va dato risalto alla seconda “S” dell’acronimo K.I.S.S. che ricorda che oltre un certo grado di semplificazione si rischia di ottenere una soluzione che non soddisfa più i requisiti iniziali.
  • System Metaphor: descrivere il sistema con una metafora, anche per la descrizione formale. Le metafore sono una sovrastruttura, ma aiutano il dialogo specialmente tra interlocutori con una diversa formazione. È però opportuno che l’adozione delle metafore sia autocontenuta, per evitare che il gruppo si fossilizzi sulla metafora piuttosto che sul problema reale.

Benessere dei programmatori

  • Sustainable Pace: il concetto è che i programmatori o gli sviluppatori software non dovrebbero lavorare più di 40 ore a settimana. Ovviamente la cifra di ore di per sé costituisce un valore indicativo che non ha a che fare con le normative in merito alla regolamentazione del lavoro. L’idea di fondo è che lavorare troppo porti l’individuo a lavorare male e al deterioramento della soddisfazione e dei rapporti tra colleghi, di conseguenza poiché la collaborazione e la motivazioni stanno alla base delle metodologie agili, meglio che il team lavori meno ma che lo faccia in maniera efficiente.

 

Crystal Family

Crystal non è in sé e per sé una metodologia bensì una famiglia di metodologie che variano in base alla dimensione e alla complessità del progetto. Crystal è il nome dato dal suo creatore, Alistair Cockburn, all’intera famiglia di metodologie. Ogni metodologia specifica della famiglia prende il nome da un colore corrispondente alla durezza del cristallo geologico, che rappresenta la dimensione e la criticità del progetto.

I vari “colori” di Crystal condividono molti elementi comuni, ma non sono compatibili in alcuna direzione. Se un progetto viene avviato come progetto Crystal Clear non ci si può permettere poi di passare a Crystal Maroon.

Indipendentemente da quale implementazione di cristallo si sceglie, ciascuna racchiude sette principi chiave, che si ritrovano anche in altre metodologie agili:

 

  • Consegna frequente: il committente riceve risultati finali dal team ogni paio di mesi. In progetti più grandi o più critici, i risultati finali non possono entrare in produzione direttamente, ma è necessario che gli stakeholder vedano e giudichino le versioni intermedie, per fornire un feedback che permetta di aggiustare progressivamente il tiro.
  • Feedback continuo: la squadra dell’intero progetto si incontra regolarmente per discutere le attività del progetto. Il team incontra regolarmente anche le parti interessate, per assicurarsi che il progetto stia andando nella direzione prevista e per comunicare eventuali nuove scoperte che possono impattare sul progetto.
  • Comunicazione costante: piccoli progetti ipotizzano che l’intero team sia nella stessa stanza, mentre per i progetti più grandi si auspica almeno che siano situati nella stessa struttura. Tali requisiti nella conformazione moderna dei gruppi di lavoro informatici possono non essere banali, a causa dell’affermazione crescente di telelavoro, outsourcing, e gruppi di lavoro delocalizzati. Ad ogni modo, è requisito fondamentale che ciascun membro abbia la possibilità di interagire direttamente e personalmente con gli altri membri del team.
  • Sicurezza: Crystal è unico per quanto riguarda gli aspetti della sicurezza nello sviluppo software. Questa è raggiunta tramite due concetti. Uno è la zona sicura che i membri del team devono condividere, per essere efficaci e per comunicare in tutta sincerità nel corso del progetto senza timore di ritorsioni; Questo primo punto è comune più o meno a tutte le metodologie agili. L’altra forma di sicurezza, che riconosce solo Crystal, è che lo scopo di ogni progetto software è diverso dagli altri, e attraverso il riconoscimento delle sue peculiarità si conforma il team e la sovrastruttura necessaria a gestirlo in maniera ottimale.
  • Focus: I membri del Team sono tenuti a conoscere i due o tre elementi prioritari; ogni membro dovrebbe lavorare su questi e avere il tempo necessario per completarli senza interruzione.
  • Accesso agli utenti: Crystal si aspetta che il team di progetto avrà accesso diretto agli utenti.
  • Automated test e integrazione: Crystal prevede l’adozione di test automatici per prevenire i problemi di integrazione e garantire la qualità del prodotto.

 

I concetti chiave di Crystal sono dimensioni e criticità del progetto. La dimensione è definita come il numero di persone coinvolte in un progetto. La criticità è definita quantificando il potenziale danno che il software può causare. In altre parole, un sistema di controllo per la guida di un aereo è più critico rispetto ad un videogioco di simulazione di volo, perché nel primo caso un malfunzionamento produce danni maggiori.

 

L’unità di misura della criticità è rappresentata da una lettera:

  • C: Comfort
  • D: Discretionary Money
  • E: Essential Money
  • L: Life

 

Di seguito una rappresentazione grafica per indicare il funzionamento delle metodologie Crystal. Più grande è un progetto, più scuro è il colore. La complessità è crescente dall’alto verso il basso.

 
La matrice delle metodologie Crystal

 

 

I numeri nelle celle (lungo la parte inferiore della figura) rappresentano la dimensione del team di progetto. Ad esempio, si evince che per gruppi fino a sei, la metodologia di Crystal Clear funziona bene. Per un numero superiore di persone occorre adottare Crystal Yellow.

danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres

Lascia un commento