Approccio agile
Per superare i limiti del modello a cascata è stato adottato un approccio, definito agile, che modifica in maniera piuttosto radicale la progettazione di software.
Questa modalità si basa sullo sviluppo iterativo ed è fondata su di una serie di linee guida (l’agile manifesto).
Recenti statistiche riportano che l'approccio agile nello sviluppo software è stato adottato - in forme pure o ibride - dalla maggioranza delle aziende software. Secondo il 13th Annual State Of Agile Report nel 2018 il 97% delle 1300 persone intervistate ha dichiarato che la loro azienda pratica metodi di sviluppo agile. Statista riporta numeri simili: il 91% degli sviluppatori hanno adottato un approccio agile.
Sviluppo iterativo e incrementale
Lo sviluppo agile assume un approccio iterativo e incrementale allo sviluppo.
L’idea di base di questo approccio è quella di sviluppare un sistema in maniera incrementale, per permettere al team di sviluppo di avvantaggiarsi di quello che si apprende durante lo sviluppo delle fasi precedenti.
Il team può fare tesoro dei feedback degli utenti che usano la versione implementata del prodotto, o quantomeno dei risultati dei test con utenti.
Minimum viable product
L’idea è quella di iniziare con una implementazione di base, semplice, di un sottogruppo di funzioni e iterativamente far evolvere il progetto versione dopo versione. Il MVP è una versione 0 del prodotto da distribuire ad un ristretto numero di utenti, al fine di avere dei feedback. Ad ogni iterazione - a partire dal MVP - è possibile apportare delle modifiche al design e aggiornare la lista dei requisiti.
La procedura
Il procedimento consiste in una fase di inizializzazione, di una serie di passaggi di iterazione e l’aggiornamento della lista di backlog, la lista delle user stories che il team di sviluppo deve implementare.
La fase di inizializzazione crea una versione di base del sistema, per creare un prodotto con cui l’utente può interagire e che servirà per raccogliere feedback ed indicazioni. Dovrebbe offrire un esempio degli aspetti chiave del servizio, e fornire una soluzione abbastanza semplice da essere compresa ed implementata facilmente.
Nei progetti di piccole dimensioni l’implementazione costituisce la base della documentazione, e a volte la sostituisce. In progetti più grandi, o mission-critical, è comunque necessario utilizzare dei processi più formali di sviluppo.
Manifesto agile
Gli autori che hanno elaborato l’approccio agile hanno scritto un manifesto, che è costituito da un decalogo di principi da rispettare nello sviluppo agile [@Cockburn2000].
1. Satisfy the customer
Our highest priority is to satisfy the customer through early and frequent delivery of valuable software.
La priorità più alta è quella di soddisfare il committente, attraverso la distribuzione frequente e tempestiva di prodotti di valore (che funzionino).
Lo sviluppo agile è focalizzato allo sviluppo e distribuzione del software. Distribuire presto permette di ottenere velocemente dei feedback sui requisiti, sul team, sul processo, sul progetto.
Permette inoltre di ottenere da subito dei piccoli risultati concreti.
2. Frequent delivery
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
Distribuisci prodotti funzionanti con una frequenza che va da una volta ogni 2 settimane ad una volta ogni 2 mesi, con una preferenza per il calendario più breve.
La frequenza di rilascio va decisa in base a due fattori:
- la capacità del team di rilasciare versioni migliorate del prodotto in tempi brevi;
- la tempistica dei clienti e degli utenti di testare il nuovo prodotto.
La regola è: fai cicli di distribuzione i più brevi possibili, tenendo conto di questi due vincoli.
Frequent delivery: vantaggi
Distribuire frequentemente piccoli miglioramenti permette di ottenere continuamente feedback e di migliorare costantemente il prodotto.
Permette inoltre di cambiare strada in fretta qualora alcune scelte progettuali si dimostrino fallimentari.
Un vantaggio collaterale di questo approccio è che, in caso di cambiamento del contesto economico (ad esempio il committente cambia idea o non ha più soldi) quello che si è realizzato è comunque qualcosa di funzionante, sebbene soltanto in una forma preliminare.
3. Working software
Working software is the primary measure of progress
Il prodotto funzionante è la principale misura dello stato di avanzamento.
Questo principio affronta il problema di come misurare il progresso di un processo di sviluppo. Secondo questo principio, è più importante misurare lo stato di avanzamento dei lavori in base ad un prodotto funzionante che attraverso altri indicatori: piani, progetti e documenti.
4. Changing requirements
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
Accetta i cambiamenti di requisiti, anche quando arrivano tardi nella fase di sviluppo. I processi agili gestiscono il cambiamento, in modo da aumentare la capacità competitiva del cliente.
La progettazione tradizionale presuppone uno scenario stabile, dove il contesto non cambia. In un simile ecosistema è plausibile progettare in modo che non vi siano cambiamenti in corso di implementazione.
Nella realtà, però, spesso le condizioni cambiano velocemente; questi cambiamenti possono essere letali per un progetto classico, in quanto possono rendere necessari cambiamenti nei requisiti che implicano la necessità di ripartire da capo. Questo porta ad una dilatazione a volte inaccettabile dei tempi o dei costi.
Il processo agile può gestire i cambiamenti tardivi di requisiti proprio grazie all’uso di tecniche iterative e brevi (early and frequent delivery).
5. Work together
Business people and developers work together daily throughout the project.
I committenti e gli sviluppatori devono collaborare costantemente durante tutto il processo.
Vi è una forte correlazione fra il livello di collaborazione fra committente e progettista e la probabilità di successo di un prodotto. Una stretta collaborazione minimizza il rischio che il progettista sviluppi un prodotto che non è quello che il committente si aspettava.
Il confronto fra committente e progettista dev’essere il più frequente possibile, poiché più tempo passa nello scambio di informazioni più vi è rischio di allungare la tempistica o sviluppare aspetti inutili del progetto.
6. Motivated individuals
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
Crea i progetti attorno a persone motivate, dai loro l’ambiente ed il supporto di cui hanno bisogno, e fidati di loro per la realizzazione del lavoro.
Le persone, la loro motivazione, la loro capacità di collaborare e di comunicare sono più importanti della metodologia adottata.
7. Face-to-face conversation
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
Sebbene la documentazione sia molto importante, è essenziale permettere ed incoraggiare la comunicazione all’interno del team.
8. Self-organizing teams
The best architectures, requirements, and designs emerge from self-organizing teams
I progetti migliori emergono quando vi è la possibilità di contare su forme di auto-organizzazione.
Il principio sottostante questo punto è che è necessario trovare un buon equilibrio fra programmazione e creatività: un eccesso di programmazione tende a mortificare la creatività e la capacità di innovazione e problem solving del team; un eccesso di creatività, privo di vincoli, porta al fallimento del progetto.
Approccio creativo - innovativo
L’approccio agile basa i suoi vincoli non su regole specifiche ma su principi generali: sviluppare e distribuire, presto e frequentemente, prodotti funzionanti, in stretto contatto con il committente e tenendo conto di eventuali mutamenti di contesto.
Nel rispetto di questi vincoli è possibile adottare un approccio più creativo alla progettazione e allo sviluppo. Un approccio creativo è tendenzialmente più rischioso, perché meno noto e meno testato. In un approccio classico, a cascata, assumere dei rischi significa mettere a repentaglio l’intero progetto. In un approccio agile, al contrario, è possibile prendersi qualche rischio in più, in quanto è possibile avere in tempi brevi dei feedback. Se l’idea creativa funziona si continua su quella strada, altrimenti la si abbandona, senza però aver speso troppe risorse e troppo tempo.
9. Excellence and good design
Continuous attention to technical excellence and good design enhances agility
Sebbene l’approccio agile insista su cicli di sviluppo brevi, vi è una attenzione centrale sulla qualità dello sviluppo, sia per quanto concerne il design che gli aspetti più tecnici dello sviluppo.
In alcuni cicli iterativi è più importante sviluppare velocemente delle nuove idee, in modo da avere un feedback tempestivo sulla loro efficacia ed utilità.
Una volta ottenuti i feedback ed aggiornato il piano progettuale, è però importante tornare ad un lavoro di pulizia, sia a livello progettuale (ad esempio aggiornando la documentazione) che a livello di implementazione.
10. Sustainable development
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
L’approccio agile promuove uno sviluppo sostenibile. Attraverso lo sviluppo agile è possibile immaginare un processo continuo, che non termina con il rilascio del prodotto.
Un approccio a cascata tende ad avere tempistiche lunghe e budget alti. Questo aumenta il rischio di non sostenibilità, ovvero la possibilità che il progetto non veda una fine.
11. Simplicity
Simplicity - the art of maximizing the amount of work not done - is essential
La semplicità è essenziale. La semplicità è l’arte di non fare le cose inutili. Fare le cose semplici è difficile, ma essenziale.
"Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior."
12. become more effective
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Ad intervalli regolari, il team cerca di capire come diventare più efficace, e cerca di aggiustare la propria metodologia.
La metodologia si impara facendo. Se si assume un approccio agile, iterativo, è più facile adattare la metodologia, valutandone l’efficacia ad ogni giro.
In questo modo si riesce, iterativamente, a migliorare non solo il prodotto ma anche il metodo.
Vantaggi dell'approccio agile
Attraverso l’approccio agile il committente può ottenere dei risultati, seppur parziali, piuttosto precocemente. Questo aspetto ha numerosi vantaggi.
- Offre delle gratificazioni intermedie: il committente, i team di design sviluppo e gli utenti vedono da subito qualche risultato.
- In caso di sopraggiunte difficoltà (ad esempio un periodo di difficoltà finanziaria del committente) vi è comunque un prodotto che funziona.
- In caso di cambiamento di condizioni in termini più favorevoli (maggior budget, oppure la disponibilità di nuove risorse tecniche, umane o di altro genere) è possibile non solo rendere più veloce lo sviluppo, ma soprattutto modificare il progetto implementando delle idee più ambiziose che prima erano rimaste nel cassetto in quanto non sostenibili.
- L’approccio iterativo permette un continuo miglioramento del prodotto, magari con delle tempistiche di distribuzioni più lente (una volta ogni sei mesi, ad esempio) e con un budget più ristretto.
Limiti dell’approccio agile
Nonostante i suoi vantaggi, anche lo sviluppo agile ha dei limiti, come evidenziati da @Bohem2002.
Sviluppo e documentazione
Una delle differenze maggiori della metodologia agile sta nel fatto che si basa sulle conoscenze tacite del team di sviluppo, più che nelle conoscenze esplicite documentate nella fase di progettazione.
Se le conoscenze implicite del gruppo di lavoro non sono sufficienti, l’approccio agile rischia però di fallire.
L’approccio waterfall riduce questo rischio attraverso una documentazione che rende esplicita la conoscenza e permette una revisione da parte di esperti esterni.
Coinvolgimento dei committenti
L’approccio agile implica il coinvolgimento dei committenti, che devono essere coinvolti, informati, collaborativi. Se questo non accade, non vi è garanzia che un prodotto, anche se rispetta i requisiti, venga alla fine adottato ed utilizzato.
Quando questo tipo di coinvolgimento non è possibile, l’approccio agile aumenta il rischio di incomprensione con il cliente, in quanto manca sia la comunicazione informale implicita nel metodo, che la documentazione più formale prevista dall’approccio tradizionale.
Requisiti
Secondo i fautori dell’approccio agile le organizzazioni sono sistemi adattativi complessi, in cui i requisiti emergono durante il corso dello sviluppo e non sono facilmente pre-specificabili.
L’approccio tradizionale funziona meglio quando i requisiti possono essere determinati a priori, anche attraverso la prototipazione, e rimangono stabili.
Se, al contrario, i requisiti cambiano spesso e molto, l’enfasi tradizionale verso una pianificazione precisa, completa, consistente, testabile e tracciabile diventa fortemente controproducente.
Prodotti safety-critical
Nello sviluppo di prodotti in cui la sicurezza è fondamentale, i criteri cambiano: non è possibile rilasciare un MVP di un aereo o di una centrale atomica. Questo non significa che alcune tecniche agili non possano essere adottate, ma la progettazione, la documentazione e la verifica dei requisiti di sicurezza devono rispettare degli standard estremamente alti.
Architettura di sistema
Nel progettare l’architettura software del sistema l’approccio agile tende a privilegiare la semplicità, focalizzandosi su una dimensione che sia adatta ai requisiti attuali.
Se però vi sono dei requisiti futuri prevedibili e probabili, un approccio troppo minimalista può portare alla necessità di riscrivere l’architettura di sistema nel momento in cui questi requisiti dovranno essere implementati.
Anche in questo caso, un approccio troppo minimalista rischia di risultare controproducente.
Una pianificazione dell’architettura software capace di scalare in maniera morbida i cambi di requisiti sul lungo termine può dimostrarsi vincente.
Refactoring (riprogettazione)
Quando i progetti sono piccoli, la riprogettazione può avere dei costi minimi, e rientra nel processo di sviluppo incrementale dell’approccio iterativo.
Quando però i progetti superano una certa dimensione, gli oneri di riprogettazione possono esplodere se l’architettura corrente è mal progettata.
Per prevenire questo rischio l’approccio waterfall si basa su di una attenta pianificazione.
L’approccio agile fa leva sul principio numero 9, ovvero sulla necessità di periodiche revisioni del processo, finalizzate a mantenere degli alti standard di progettazione ed implementazione.
Dimensioni del progetto
Lo sviluppo agile appare vincente in team piccoli, mentre un approccio più pianificato e più strutturato diventa essenziale in gruppi di lavoro di grandi dimensioni.
Bilanciare agilità e disciplina
Un eccesso di pianificazione porta ad un aumento dei tempi e dei costi. Troppo poca pianificazione porta ad un aumento dei rischi di errore. A seconda del contesto diventa essenziale trovare un buon rapporto fra agilità e disciplina.
Agile e UX
Il rapporto fra metodo agile ed UX non è banale. Vi sono alcuni punti di convergenza ed aspetti in cui l'integrazione è più difficile.
Aspetti convergenti
Semplicità, buon design ed eccellenza, funzionalità sono obiettivi sia dell'agile che dell'ux team.
Lavorare in team co-locati, motivati, capaci di auto-organizzarsi, di adattarsi ai cambiamenti, di imparare dall'esperienza, sono pratiche che ben si adattano sia allo sviluppo agile che all'UX design, entrambi interessati ad uno sviluppo sostenibile.
Le divergenze
Il customer non è lo user
Vi sono principalmente due aspetti che rendono problematico il rapporto fra ux e sviluppo agile.
Il primo è che il customer nella letteratura Agile è una figura diversa dal customer dell'ux.
Agile è un approccio di sviluppo centrato su sviluppatori e committenti. Il primo comandamento dell'Agile Manifesto recita che
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
In questa accezione, customer è generalmente il committente, e se a volte si intende anche l'utente finale questa distinzione non è concettualmente chiara.
Ad esempio, secondo lo Scaled Agile Framework il Customer è l'ultimate buyer: può essere il Business Owner, e fra le altre cose gestisce il perimetro, i tempi, i vincoli, contribuisce a definire la roadmap, le milestone, i rilasci, definisce e comunica gli aspetti di business. Dunque sicuramente quando si parla di customer si pensa al committente e non all'utente finale.
Ora, né il customer né il product owner possono sostituirsi agli utenti finali, in base al fatto che tu non sei il tuo utente: committente ed utente hanno motivazioni diverse, e diversi modelli mentali. Il committente e l'utente sono due figure completamente diverse.
Le fasi dello UX
Lo user experience design si occupa di identificare le motivazioni degli utenti, di far emergere i modelli concettuali di utenti ed esperti di dominio, di progettare delle interfacce che permettano agli utenti di utilizzare i prodotti e servizi sviluppati in maniera efficace, efficiente, e con soddisfazione. Per fare questo, devono intraprendere delle attività di esplorazione (benchmark, analisi dei prodotti esistenti ...), di ricerca (osservazione e interviste con utenti, esperti di dominio e committenti), di sintesi, di progettazione, di test.
Queste attività vanno fatte prima che gli sviluppatori inizino a scrivere codice. E se non è pensabile che queste attività durino anni, non si possono nemmeno comprimere nello spazio di uno sprint o due.
Discovery e creazione
Sul rapporto fra l'approccio di sviluppo agile e l'UX (o il design centrato sull'utente) sono stati pubblicati numerosi lavori. Una recente rassegna [@Brhel2015] ha analizzato 83 articoli che hanno affrontato il problema dell'integrazione fra UXD e Agile.
The valuation of up-front analysis and design was recognized as one of the main tension points between UCD and ASD early on. While the former promotes the extensive upfront analysis of user requirements and the design of the users’ interaction with the system, the latter focuses on delivering a working code at the expense of an exhaustive planning and design phase.
Moreover, there is no common definition of what constitutes sufficient preparation, and the effort put into initial analysis and design activities ranges from days to weeks.
La soluzione concettuale proposta dagli autori è quella di distinguere le attività dello ux finalizzate alla product discovery a quelle finalizzate alla product creation. La progettazione e il test dell'interfaccia può essere integrata nel processo agile, immaginando degli sprint di progettazione e test, con una tempistica di due sprint di vantaggio per il design ed uno per il test.
La fase di discovery - ovvero esplorazione, ricerca e sintesi - dovrebbe essere fatta prima, e ad essa dovrebbe essere dedicato uno spazio maggiore di uno o due sprint.
Conclusioni
Il rapporto fra UX/UCD e Agile non è semplice. Il fine dell'approccio Agile è soddisfare il customer/committente, il fine dell'UCD è di soddisfare scopi e bisogni dell'utente. Affinché un prodotto abbia successo, è necessario che soddisfi sia le motivazioni degli utenti che gli scopi di business del committente. Integrare la progettazione orientata all'utente nello sviluppo agile non è banale, in quanto i vincoli di quest'ultimo (sprint brevi, little design up front) impediscono di fare una seria attività di ricerca e sintesi con utenti, esperti di dominio e committenti. Saltare la ricerca, o comprimerla in sprint di poche settimane, aumenta di molto il rischio che il prodotto non soddisfi i bisogni degli utenti.
La soluzione proposta da Brhel e colleghi, che io sottoscrivo, è di dividere - concettualmente ed empiricamente - la fase che loro definiscono di product discovery (esplorazione, ricerca, sintesi) da quella di design, test di usabilità, sviluppo, test di conformità.
La seconda fase, con la giusta calibrazione, può essere organizzata adottando i processi e i metodi dell'approccio Agile. La prima parte dovrebbe avere un respiro più ampio, per permettere a ricercatori, designer, esperti di dominio e committenti di mappare motivazioni e modelli concettuali che guideranno il design, il test e l'implementazione del prodotto.