Tutti quelli che lavorano in ambito IT sanno quanto l’ingegneria dei requisiti sia un aspetto fondamentale per la riuscita di un progetto e per il successo di un prodotto software.Sempre maggiore è la consapevolezza che la corretta identificazione dei requisiti può essere più complessa della stessa realizzazione del software che li implementa. Il problema principale è che spesso i requisiti non sono chiari neanche a chi li deve scrivere. Capita, inoltre, che il cliente non sappia esprimere in maniera razionale i propri bisogni e non consenta al gruppo di sviluppo, di trasformarli nelle dovute funzionalità software.
Accade, inoltre, che sempre più spesso si senta parlare di Agile Requirements Engineering, Product Management e Product Owner ma quanti sono quelli che conoscono realmente di cosa si stia parlando?
Io non ero tra quelli e per questo motivo, lo scorso 23 Giugno, ho partecipato al tutorial “Il mistero del requisito Agile”. Il tutorial, creato nel contesto del Software Testing Forum 2014 , è stato tenuto da Salvatore Reale che vanta una ventennale esperienza in ambito R&D, in particolare nello sviluppo software per importanti società internazionali, nonché uno dei primi in Italia ad aver introdotto e utilizzato metodologie agili in questo contesto.
Il tutorial si è svolto durante l’intera giornata ed era rivolto a tutti gli interessati ad approfondire l’ingegneria dei requisiti in ambiente agile. Non richiedeva particolari prerequisiti, se non una conoscenza di base dei concetti di ingegneria dei requisiti, Agile Development e del metodo Scrum.
La giornata ha avuto inizio con un’interessante seduta di planning poker in cui a tutti i partecipanti è stato chiesto di esprimere “il requisito” principale che la giornata doveva soddisfare, nella forma di una “User Story”. Come spiegato da Reale, la “User story” rappresenta, in ambito agile, la base di partenza per la definizione del requisito ed è utilizzata come base per la definizione delle funzioni che un sistema deve fornire. La forma abituale è: “Come <utente> voglio <azione> in modo che <beneficio atteso>, al fine di catturare il “chi”, “cosa” e “perché” di un requisito, in modo semplice e sintetico.
La storia così individuata deve essere la base di partenza per una discussione all’interno del gruppo di lavoro che permetta di sviscerare i dettagli del caso. La stessa storia non è un monolitico pezzo di analisi non modificabile ma rappresenta una esigenza dell’utente che può essere arricchita, modificata oppure ripartita in storie più piccole.
Il tutorial è proseguito definendo il manifesto per lo sviluppo Agile ed i principi che lo compongono.
Quattro sono le considerazioni alla base:
1) Gli individui e le interazioni più che i processi e gli strumenti;
2) Il software funzionate più che la documentazione esaustiva;
3) La collaborazione col cliente più che la negoziazione dei contratti;
4) Rispondere al cambiamento più che seguire un piano.
Lo sviluppo agile si fonda sull’approccio iterativo e incrementale dello sviluppo software, con la novità che al termine di ogni iterazione il prodotto è potenzialmente rilasciabile al cliente. Il concetto di fasi di progetto non ha più senso: requisiti, analisi, codifica, test sono tutte incluse in un’iterazione, magari con peso diverso man mano che le iterazioni proseguono. Una volta che il lavoro per un’iterazione prende il via, non può essere modificato, al massimo può essere stoppato o cancellato qualora gli obiettivi siano cambiati e non raggiungibili. Si parla di time-box, di un periodo di tempo concordato che porta al raggiungimento di un obiettivo, al termine del quale può accadere anche di fermare il lavoro per valutare ciò che è stato parzialmente realizzato.
Il tempo non è più una variabile. S’inizia ad organizzare il progetto per feature team, non per funzione aziendale o disciplina: un team inter-funzionale che ha tutte le competenze specifiche necessarie per fornire una funzionalità completa.
Capite bene quanto tutto questo sia diverso dall’approccio classico, quello a cui la maggior parte di chi lavora in ambito IT è abituato.
Il trainer aveva ormai conquistato la mia piena attenzione, aveva scoperchiato il vaso di Pandora: in un attimo mi sono tornati in mente gli ultimi anni di lavoro i tentativi di andare in questa direzione, i successi e gli insuccessi dovuti al cambiamento e alla voglia di tendere al nuovo, insomma la sete di conoscere ancora più dettagli cresceva in me.
Dopo la pausa caffè è arrivato il momento di approfondire la metodologia Scrum.
Scrum è un framework incrementale iterativo per progetti e per lo sviluppo di prodotti. Lo sviluppo è strutturato in iterazioni chiamate Sprint. Queste iterazioni hanno lunghezza determinata che va da 1 a 4 settimane e time-box. All’inizio di ogni sprint un team inter-funzionale seleziona gli elementi (requisiti) da un elenco di priorità e si impegna a completare le attività entro la fine dello Sprint. Durante lo Sprint, gli elementi non cambiano e ogni giorno il team si incontra per riportare brevemente e reciprocamente i progressi/problemi. Scrum pone l’accento sul prodotto funzionante alla fine dello Sprint, definito come “fatto” che vuol dire codice integrato, testato e rilasciabile. Un tema importante per lo Scrum è ispezionare e adattare con la Retrospettiva. Lo sviluppo comporta inevitabilmente apprendimento, innovazione e imprevisti, quindi è importante ispezionare sia il prodotto risultante sia l’efficacia delle pratiche correnti.
Lo Scrum ha sicuramento il suo fascino, è chiaro che presuppone un cambiamento importante sia a livello organizzativo sia a livello di dinamiche prettamente progettuali.
La giornata entra nel vivo, il trainer ritorna sull’argomento principe: i requisiti. Si inizia a parlare di affinamento di una User Story e di soddisfacimento dell’acronimo INVEST (indipendente, negoziabile, valorizzabile, stimabile, appropriatamente dimensionata e testabile). Si passa, quindi, a descrivere il percorso che il requisito farebbe in un progetto Agile a livello Enterprise, dalla genesi a livello di Portfolio, all’evoluzione a livello di Program, fino ad arrivare al team. Particolare attenzione è stata data alle nuove figure professionali che stanno nascendo in questo contesto: il Product owner (colui che guida la definizione dei requisiti e scandisce i principali eventi in cui si realizza l’analisi e la specifica degli stessi) e lo Scrum Master (colui che facilita i progressi del team verso l’obiettivo e guida gli sforzi del team verso il continuo miglioramento).
Non basterebbero diverse pagine per raccontare i dettagli, per quello vi rimando alla letteratura, quello che è rimasto a me è una bella introduzione verso un mondo nuovo, un nuovo possibile modo di lavorare e nuove figure professionali da capire e forse a cui ambire.
Il tutorial è proseguito con ulteriori approfondimenti inframezzati da Workshop sui requisiti. Divisi in gruppi e partendo da casi reali abbiamo provato a mettere in pratica quanto sentito in precedenza.
Il pomeriggio è volato, con non poca fatica abbiamo cercato di immedesimarci in realtà agili e abbiamo provato a tirar fuori dei requisiti per ipotetiche applicazioni.
Il tutorial sicuramente mi ha aperto ad un mondo che conoscevo poco, mettendo in evidenza quali vantaggi possono derivare da un’efficace ingegneria e gestione dei requisiti in un contesto agile e quali problemi vanno affrontati nei cambiamenti da mettere necessariamente in atto affinchè l’Agile Requirements Engineering abbia successo. La voglia è quella di riuscire a mettere a frutto quanto sperimentato.
Gianfranco Netti