Dopo aver presentato la filosofia alla base delle metodologie agili e aver preso in considerazione una serie di metodiche e sistemi meno conosciuti, in questo articolo conclusivo affrontiamo il Lean Software Development e Scrum, certamente due tra i più conosciuti metodi agili. Forniamo inoltre una serie di considerazioni sul valore aggiunto che tali metodologie possono dare a un’azienda o a un gruppo di lavoro se adottate in maniera coerente.

Lean Software Development

Il Lean Software Development rappresenta la traduzione in ambito IT di concetti provenienti dal mondo industriale. Nelle attività industriali esiste una corrente di organizzazione del lavoro e dei processi aziendali denominata produzione snella (in inglese lean manufacturing o lean production): questo orientamento organizzativo della produzione si ispira al cosiddetto Sistema di produzione Toyota, nato in Giappone nella omonima fabbrica, negli anni seguenti la Seconda Guerra Mondiale, e successivamente sviluppatosi in altri contesti. Il principio fondamentale del Toyota Production System è quello di “fare di più con meno”, evitando gli sprechi e massimizzando la produzione anche con risorse limitate (che era poi la situazione reale della disastrata economia nipponica all’inizio degli anni Cinquanta del secolo scorso).

In seguito, certi concetti tipici di questo modello, si sono tradotti in principi e pratiche del Lean IT nel dominio dello sviluppo software. Il termine Lean Software Development ha avuto origine in un libro omonimo, scritto da Mary Poppendieck e Tom Poppendieck [4]. Questo libro presenta i tradizionali principi snelli in forma modificata, così come un insieme di 22 strumenti che vengono confrontati e comparati con le pratiche agili. Il coinvolgimento di Mary e Tom nelle community legate all’Agile software, inclusa la loro presenza come relatori a numerose conferenze, ha fatto sì che tali concetti fossero più ampiamente accettati e condivisi all’interno della comunità agile, fino a far emergere rapidamente una vera e propria sottocultura pro-lean.

I principi del Lean

Lo sviluppo lean può essere riassunto dai seguenti 7 principi, concettualmente affini a quelli della produzione snella.

1. Eliminare gli sprechi

Questo principio afferma che tutto ciò che non aggiunge valore al cliente va considerato come uno spreco (muda in giapponese). Esso include:

• codice e funzionalità non necessarie;
• ritardi nel processo di sviluppo del software;
• requisiti incerti;
• burocrazia;
• lenta comunicazione interna.

2. Amplificare l’apprendimento

Lo sviluppo del software è un processo di apprendimento continuo con la sfida aggiuntiva dei team di sviluppo e delle dimensioni del prodotto finale. L’approccio migliore per migliorare un ambiente di sviluppo software è dunque quello di massimizzare l’apprendimento.

3. Decidere il più tardi possibile

Dato che lo sviluppo del software è sempre associato con qualche incertezza, i risultati migliori dovrebbero essere raggiunti con un approccio basato sulle opzioni, rinviando le decisioni il più possibile fino a che essa non può essere effettuata sulla base di fatti e non su previsioni e ipotesi incerte.

4. Consegnare il più velocemente possibile

Nell’era della rapida evoluzione tecnologica, non è il più grande che sopravvive, ma il più veloce. Quanto prima il prodotto finale viene fornito senza difetti considerevoli, tanto prima possono essere ricevuti i feedback, che saranno inseriti nella successiva iterazione. Quanto più corte sono le iterazioni, tanto migliore sarà la formazione e la comunicazione all’interno del team.

5. Autorizzare il team (mantenendo la gente motivata)

Per lungo tempo c’è stata un’opinione diffusa, nella maggior parte delle aziende, riguardo al processo decisionale per l’organizzazione: i dirigenti erano abituati a dire ai lavoratori come svolgere il proprio lavoro. Nella tecnica work-out, i ruoli si trasformano: ai manager si insegna ad ascoltare gli sviluppatori, in modo da poter essere in grado di spiegare meglio le azioni che possono essere adottate, e di fornire proposte di miglioramento.

6. Integrità nella costruzione

Il cliente deve avere una esperienza complessiva del sistema; si tratta della cosiddetta integrità percepita. In pratica, il cliende deve avere una conoscenza integrale del prodotto rispetto al modo in cui viene pubblicizzato, consegnato, diffuso, al modo in cui si accede ad esso, a quanto intuitivo è il suo utilizzo, a quale sia il prezzo e a quanto risolva dei problemi.

7. Vedere il tutto

I sistemi software al giorno d’oggi non sono semplicemente la somma delle loro parti, ma anche il prodotto delle loro interazioni.

Gli strumenti del Lean

Le pratiche di sviluppo software lean, o ciò che i Poppendieck chiamano “strumenti” sono espressi in modo leggermente diverso dai loro equivalenti nello sviluppo di software agile, ma ci sono degli evidenti paralleli. Esempi di tali pratiche includono:

• vedere gli sprechi;
• Value Stream Mapping;
• sviluppo basato sui set;
• sistemi pull;
• Lean Workcells;
• teoria delle code;
• motivazione;
• misure & metriche

Alcune di queste pratiche trovano facilmente riscontro nei metodi agili. Le Lean Workcells, per esempio, sono espresse nei metodi agili come team inter-funzionali.

Scrum

Scrum è un framework di management lightweight con una grande applicabilità sia per il management che il controllo di progetti iterativi e incrementali di qualunque tipo, ideato e sviluppato da Ken Schwaber e Mike Beedle e oggi distribuito da Advanced Development Methods. Schwaber, Beedle, Jeff Sutherland e altri hanno contribuito significativamente all’evoluzione di Scrum nell’ultimo decennio. Anche se Scrum è stato originariamente concepito per la gestione iterativa e incrementale di progetti di sviluppo software, esso può essere utilizzato per coordinare team di manutenzione del software, o come un più generale approccio di gestione di progetti anche al di fuori dell’ambito informatico.

Nel corso degli ultimi cinque anni, in particolare, Scrum ha guadagnato una popolarità crescente all’interno della comunità software grazie alla sua semplicità, alla comprovata produttività e alla sua capacità di agire come “involucro” per altre numerose pratiche di ingegneria software promosse dalle metodologie agili.

Successo di Scrum

Questa metodologia consiste in un insieme di pratiche e regole interrelate che ottimizzano l’ambiente di sviluppo, riducono l’overhead organizzativo, sincronizzando i requisiti emergenti dal mercato con prototipi iterativi. Basato su moderne teorie di controllo dei processi, Scrum consente la produzione del miglior software possibile, una volta fissato il numero di risorse disponibili, una qualità del sistema accettata e date di rilascio richieste contrattualmente. Un insieme di funzionalità del prodotto realmente utilizzabili vengono rilasciate e messe in produzione ogni quindici o trenta giorni man mano che i requisiti, l’architettura e il progetto stesso emergono, anche nel caso in cui vengano utilizzate tecnologie complesse o instabili.

Oltre cento grandi organizzazioni nel mondo hanno utilizzato con successo Scrum in migliaia di progetti per gestire e controllare il lavoro, sempre con significativi incrementi della produttività; tali progetti vengono raffinati e migliorati necessariamente mentre vengono rilasciati incrementi del prodotto all’utente o sul mercato finale. Scrum in pratica viene a definirsi come un insieme di valori, pratiche e regole all’interno di un unico framework di sviluppo che può essere rapidamente implementato e ripetuto.

I punti fondamentali di Scrum

Questa metodologia si basa su tre semplici punti: Sprint, Backlog e Scrum Meeting. Molto simile ad eXtreme Programming, prevede di dividere il progetto in blocchi rapidi di lavoro (sprint) alla fine dei quali consegnare una versione del sistema al cliente, indica come definire i dettagli del lavoro da fare nell’immediato futuro (backlog) per averne una definizione estesa, organizza riunioni giornaliere del team di sviluppo (daily scrum) per verificare cosa si è fatto e cosa si farà.

La parola Scrum è mutuata dal termine del rugby che indica la mischia ed è evidentemente una metafora del team di sviluppo che deve lavorare insieme, proprio come il pacchetto di mischia del rugby, in modo che tutti gli attori del progetto spingano nella stessa direzione, agendo come un’unica entità coordinata.

Esiste una comunità molto attiva, chiamata Scrum Alliance, che si occupa di Scrum e che sviluppa tutto quello che possa servire relativamente a questa metodologia, dalle basi ai casi di studio, dalla bibliografia agli esempi, ovviamente aggiornata per quanto più è possibile.

Il processo Scrum

Durante ogni sprint, in genere un periodo di 2-4 settimane (tale durata viene decisa dal team), la squadra crea un incremento di prodotto potenzialmente consegnabile (ad esempio, del software funzionante e testato). Il set di funzionalità che vengono inserite in uno sprint provengono dal product backlog, che è un insieme di requisiti, con priorità ad alto livello, di lavoro da compiere.

Figura 1 – I punti fondamentali di Scrum: Sprint, Backlog e Scrum Meeting.

 

Quali item del backlog debbano far parte dello sprint corrente viene determinato nel corso della riunione di Sprint Planning. Durante questa riunione, il Product Owner informa il team circa gli item del Product Backlog che vorrebbe veder completati nel corso dello sprint. La squadra determina quindi per quanti di questi può effettivamente impegnarsi a completarli del corso del prossimo sprint. È importante sottolineare che, durante uno sprint, non è permesso al PO di cambiare lo Sprint Backlog, il che significa che i requisiti sono congelati durante tale iterazione. Dopo che un sprint è stato completato, il team illustra agli stakeholder e al Product Owner il software realizzato, ovvero tutti gli item completati, e riceve da questi feedback su possibili miglioramenti.

Elementi di scrum

Scrum è un framework di processo che contiene un insieme di artefatti, pratiche e ruoli predefiniti.

Artefatti

I principali artefatti in Scrum sono:

• Il Product Backlog, un documento ad alto livello per l’intero progetto. Contiene i cosiddetti backlog item: descrizioni di tutte le caratteristiche richieste, lista dei desiderata e così via, con priorità assegnate in base al valore di business.

• Lo Sprint Backlog, un documento che contiene informazioni su come il team sta procedendo nell’implementare le funzioni per lo sprint a venire.
• Il Burn-down Chart, un grafico mostrato in pubblico che rappresenta il lavoro che deve essere ancora completato nello sprint backlog. Aggiornato ogni giorno, dà una visione semplice e immediata del modo in cui procede lo sprint.

Pratiche

Le principali pratiche (riunioni) in Scrum sono:

• Il Daily Scrum: ogni giorno durante lo Sprint, viene tenuta una riunione di verifica sullo stato del progetto. Questo meeting viene chiamato “daily scrum” o “daily standup”.
• Lo Scrum of Scrums o Post-scrum: consente a gruppi di team di discutere del loro lavoro,concentrandosi su aree di sovrapposizione e d’integrazione.

• Lo Sprint Planning meeting: è frequentato da Product Owner, Scrum Master, intero Scrum Team, e da tutti i manager del caso interessati o dai rappresentanti della clientela.
• Lo Sprint Review meeting: presenta agli stakeholder il lavoro completato (anche detto “la demo”). Il lavoro incompleto non può essere dimostrato.
• Lo Sprint Retrospective meeting: consente un continuo miglioramento del processo in base a un principio di “inspect & adapt”.

Ruoli

In Scrum vengono definiti un certo numero di ruoli. Tutti i ruoli rientrano in uno di due gruppi distinti: suini e polli. La suddivisione fra “maiali” e “polli” è fatta in base alla natura del loro coinvolgimento nel processo di sviluppo: i maiali sono molto più coinvolti, i polli lo sono in misura nettamente minore. Queste due categorie derivano il loro nome da una battuta su un maiale e un pollo che devono mettersi in società e aprire un ristorante (fig. 2).

Figura 2 – La storiella sul pollo e sul maiale che devono aprire un ristorante insieme: chiaramente è il povero suino a rischiare molto di più…

 

In questo modo i “maiali” sono impegnati a costruire software regolarmente e frequentemente, mentre tutti gli altri ricoprono il ruolo di “pollo”, sono cioè interessati al progetto, cui danno un contributo, ma sono anche in realtà coinvolti solo fino a un certo punto, perche’ anche se fallissero non sono loro i “maiali”, cioè quelli impegnati direttamente a realizzare il progetto. I bisogni, i desideri, le idee e le influenze dei ruoli di “pollo” vengono presi in debita considerazione, ma non è consentito loro di incidere, falsare o governare il vero e proprio processo Scrum, responabilità riservata solo ai ruoli della categoria “maiali”.

Ciò detto, i ruoli principali (maiali) in Scrum sono i seguenti:

• Lo ScrumMaster, che gestisce e garantisce il processo (tipicamente al posto del Project Manager standard), ma non gestisce il progetto o il team;
• il Product Owner, che rappresenta i committenti e il business;
• il Team, un gruppo inter-funzionale di circa 7 persone che effettua l’analisi, la progettazione l’implementazione, i test, auto-organizzandosi e modificando il proprio processo mediante gli incontri di retrospective.

È in corso una discussione sulle responsabilità e le dinamiche interne di un team, moderata da Jeff Sutherland e nata prendendo spunto dalla riflessione di Ken Schwaber sulla differenza fra l’essere interessati in un progetto o l’esservi pienamente coinvolti. Questa discussione, ad oggi, ha permesso di ottenere una lista di verifiche, riassumibili in tre domande, da effettuare per sapere se il proprio Scrum team è ben formato.

• C’è qualcuno di cui è difficile sbarazzarsi? Male, ne risentirà la produttività.
• Il team lavora per riorganizzarsi o per eliminare queste persone? Bene, allora si lavora nel verso giusto: il sistema immunitario del gruppo funziona.
• Se ci sono manager, hanno anche loro compiti assegnati dal team Scrum? Bene, il team funziona autonomamente.

Scrum ha inoltre dimostrato di poter scalare per team multipli anche attraverso grandi organizzazioni (1200+ persone).

Agile Software Development: una serie di considerazioni

Mentre è vero che molte delle pratiche associate con lo sviluppo Agile esistono da un discreto lasso di tempo, la media dei team di sviluppo software deve ancora abbracciare gran parte di tali principi e pratiche. Anche oggi, il software team medio non opera in modo iterativo, non rilascia software incrementalmente, e non pratica ne’ il planning continuo, ne’ i test automatici. Oggigiorno, che queste pratiche nelle metodologie Agile sono state combinate in modo da poter esser meglio comprese e adottate, il trend appare mutare rapidamente in modo positivo, in particolar modo nel corso degli ultimi anni.

Ovviamente, come qualsiasi nuovo processo che modifichi radicalmente il business, i metodi agili hanno generato una serie di controversie nella comunità software. Comunque, sin dalla loro nascita e propagazione, progetto dopo progetto, essi hanno continuato a produrre sistemi software di alta qualità in tempi più rapidi di quanto non facessero altri processi tradizionali.

Vorrei concludere questa serie di articoli cercando di rispondere, nei paragrafi successivi, sostanzialmente alle seguenti domande:

• Per quali ragioni dovrei scegliere l’Agile Software Development come metodologia di progetto?
• Quali sono i problemi principali nell’adottare l’Agile?
• Quando non è il caso di utilizzare le metodologie Agili?

Vediamo una serie di considerazioni che dovrebbero fornire delle risposte motivate.

Ragioni per cui scegliere le metodologie agili

A mio avviso, rispetto alle metodologie tradizionali, l’adozione di metodologie agili offre una serie di vantaggi, che possiamo suddividere in tre tipologie:

• vantaggi per il committente
• vantaggi per il team di progetto
• vantaggi per l’organizzazione

Vantaggi per il cliente

Alcuni dei vantaggi forniti al committente dalle metodologie agili possono essere così riassunte:

• Il cliente è coinvolto più attivamente, ottiene un controllo maggiore sulle priorità.
• Viene a sapere in modo regolare e frequentemente lo stato dell’applicazione.
• I requisiti sono accettati dopo ogni iterazione.
• Poiche’ la metodologia sottolinea consegne rapide, si ha un minor time-to-market. In questo modo le funzionalità chiave del sistema possono essere disponibili all’uso prima.
• La consegna è definita da un calendario fissato. Così il cliente è certo di ricevere alcune funzionalità a un determinato periodo di tempo fisso e regolare.
• Grazie all’enfasi sui test (sia automatici che manuali), la qualità del software fornito è decisamente migliore.

Vantaggi per i gruppi di progetto

• I team di progetto sono coinvolti più attivamente in tutte le fasi, e devono effettuare le domande giuste. Le squadre prendono le decisioni in maniera collaborativa e sono più responsabilizzati.
• Dal momento che lo sviluppo è incrementale, i team possono concentrarsi sulle esigenze specifiche in un qualsiasi momento.
• Viene posta una maggiore enfasi sullo sviluppo dell’applicazione, che non sulla documentazione.
• Vengono utilizzati documenti semplici e minimali allo scopo di scambiare le opinioni. Si dà particolare importanza alla comunicazione diretta.
• Dato che i team ricevono feedback frequenti grazie a test integrati e automatici, la rilavorazione è ridotta al minimo.

• Viene speso molto meno tempo nella raccolta di requisiti, in quanto non vengono più raccolti tutti i requisiti in anticipo, ma sono analizzati e implementati man mano che si presentano.
• Questo comporta anche un tempo minore per le attività di pianificazione. Che inoltre diventa molto meno incerta in quanto utilizza il concetto del just in time (JIT)
• Minori costi di sviluppo complessivo in quanto vengono drasticamente ridotti i costi relativi a rielaborazione, gestione, documentazione e ogni altra attività non direttamente di-sviluppo.
• I team sviluppano le applicazioni in modo collaborativo, in ambiente altamente cooperativo.

Confronto tra metodologia Agile e tradizionale

Nella tabella 1 viene confrontata la metodologia di sviluppo Agile con quella tradizionale considerando una serie di parametri:

Tabella 1 – Confronto tra le caratteristiche delle metodologie di sviluppo agile e quella tradizionale.

 

Sfide coinvolte nello sviluppo agile del software

Le metodologie agili richiedono essenzialmente un diverso approccio mentale oltre che l’acquisizione di nuove competenze e quindi lanciano una sfida al nostro approccio convenzionale.

Difficoltà

La metodologie Agili sono difficili in quanto richiedono ulteriori test e la partecipazione attiva dei committenti. Hanno inoltre un impatto maggiore sul management rispetto a quello sugli sviluppatori. Al management viene richiesta una maggiore apertura mentale, e di essere attivamente coinvolto nel processo di sviluppo e soprattutto di consentire ai team di prendere decisioni in modo indipendente.

Disciplina

L’Agile richiede molta più disciplina delle tecniche tradizionali. In primo luogo, durante lo sviluppo, il codice può essere integrato in modo continuo, a volte anche dopo ogni aggiornamento nel repository del codice sorgente. Inoltre, per garantire che l’applicazione sia sempre in uno stato rilasciabile, tutto il codice deve funzionare sempre in modo perfetto.

Occorre inoltre ammettere che nello sviluppo Agile sono richieste competenze tecniche e manageriali più elevate. In terzo luogo, ogni funzionalità deve essere completata prima di passare alla successiva. E, infine, sono necessari team cross-funzionali e maggiore autodisciplina.

Pianificazione

Contrariamente a quanto si possa credere, rispetto a quelle tradizionali, nelle metodologie agili è necessaria una maggiore e più raffinata forma di pianificazione. Poiche’ la pianificazione viene effettuata frequentemente (quanto meno per ogni iterazione), e il piano viene aggiornato come e quando necessario, deve essere fatta una pianificazione più mirata. È inoltre fondamentale che il piano sia adattabile per rispondere alle mutate esigenze.

Supporto

Infine per implementare le metodologie Agili sono necessari diversi tipi di supporto. Anzitutto un supporto organizzativo a diversi livelli:

• culturale: l’organizzazione deve essere aperta al cambiamento;
• gerarchico: il management deve essere pronto ad autorizzare i team;
• burocratico: viene richiesta una minore focalizzazione su processi e passi operativi.

È poi necessario un supporto di tipo infrastrutturale e logistico che sostanzialmente richiede le seguenti condizioni:

• preferibilmente il team e il committente dovrebbero essere collocati assieme;
• occorre il necessario supporto hardware per l’integrazione continua, il pair programming e altre pratiche tipiche di questi sistemi di sviluppo.

Infine, è decisivo un supporto a livello di team:

• dovrebbero essere coinvolte persone che abbiano passione, un elevato insieme di abilità e una mentalità aperta e flessibile;
• viene richiesto un maggiore e più frequente utilizzo di tecniche di test.

Roadmap per l’adozione dell’Agile

Le metodologie Agili stanno rapidamente diventando lo standard “de facto” del processo di sviluppo software per team con alte prestazioni; quindi la domanda reale che manager e dirigenti IT devono porsi non è più se adottare l’Agile, ma quando e come farlo. Benche’ adottare in modo soddisfacente l’Agile non sia un esercizio banale, questa metodologia, una volta realizzata correttamente, è altamente gratificante sia per le organizzazioni che per gli individui coinvolti.

I passi necessari per adottare l’Agile, benche’ non siano semplici, sono piuttosto chiari e consistono essenzialmente in:

• ricercare, indagare, e imparare quanto più possibile riguardo l’Agile;
• identificare un progetto o un team nella propria organizzazione in cui si ritiene che l’Agile possa prosperare;
• costruire il caso di un progetto pilota;
• educare il top management riguardo l’approccio, i vantaggi e le sfide che concernono l’Agile;
• effettuare il kick off (calcio d’inizio) del progetto pilota proteggendolo da oppositori e scettici;
• Investire negli elementi più giovani e rafforzare le proprie abilità tramite strumenti adeguati di formazione.

Una volta eseguiti questi passi, sarà presto evidente come i processi agili consentano di ottenere software di migliore qualità che viene consegnato in tempi più brevi rispetto al passato. Inoltre i team saranno più contenti grazie ad un ritmo di lavoro sostenibile garantito dal processo agile; stakeholder e azionisti dell’azienda, infine, saranno convinti del significativo impatto che l’agile ha avuto sulla bottom line.

Conclusioni

Vorrei concludere con la seguente osservazione: benche’ lo sviluppo software agile sia perfetto per piccoli progetti, molte grandi organizzazioni adottano tali metodiche. Ad esempio Boritisi Telecom ha realizzato con successo enormi progetti, coinvolgendo centinaia di sviluppatori situati in Gran Bretagna, Irlanda e India, e usando le metodologie agili. Questo mostra la potenza e la scalabilità di queste metodologie che, ci auguriamo, abbiamo contribuito a far conoscere in questa serie.

Riferimenti

[1] Manifesto for Agile Software Development, 2001
http://agilemanifesto.org

[2] P. Coad – J. De Luca – E. Lefebvre, “Java Modeling In Color With UML: Enterprise Components and Process”, Prentice Hall, 1999

[3] S. Khramtchenko, “Comparing eXtreme Programming and Feature Driven Development in academic and regulated environments”, Harvard University, CSCIE-275: Software Architecture and Engineering, 2004

[4] M.P. Poppendieck, “Lean Software Development: An Agile Toolkit”, Addison-Wesley Professional, 2003

[5] W.Royce, “Managing the Development of Large Software Systems”. Proc. Westcon, IEEE CS Press, 1970, pp. 328-339

[6] J. Stapleton, “DSDM Dynamic Systems Development Method: The Method in Practice”, Addison Wesley, 1997

[7] M. Fowler – K. Beck – J. Brant – W. Opdyke – D. Roberts, “Refactoring: Improving the Design of Existing Code”, Addison-Wesley Professional, 1999

[8] S.W. Ambler, “The object primer: the application developer’s guide to object-orientation”, SIGS Books, 1995

[9] A. Vermeulen – S.W. Ambler – G. Bumgardner – E. Metz – T. Misfeldt – J. Shur, “The Elements of Java Style”, SIGS Reference Library, 2000

[10] E. Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”, Addison-Wesley Professional, 2003