Elaborato Traiola Marcello N46000127

Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Elaborato finale in Ingegneria del Software
Le storie utente ed altre tecniche per la
specifica dei requisiti negli approcci Agili
per lo sviluppo software
Anno Accademico 2011/2012
Candidato:
Marcello Traiola
matr. N46000127
I
II
Sommario Introduzione ...................................................................................................................................................................................... 4 Capitolo 1 -­‐ La nascita dei metodi agili .................................................................................................................................. 6 1.1 I principi dei metodi agili ................................................................................................................................................... 7 1.2 Attenzione ai requisiti! ........................................................................................................................................................ 8 1.3 Scriviamo i requisiti .............................................................................................................................................................. 9 Capitolo 2 -­‐ Tre metodi a confronto ...................................................................................................................................... 14 2.1 SCRUM Flow ........................................................................................................................................................................... 14 2.1.1 La specifica dei requisiti in SCRUM ...................................................................................................................... 17 2.1.2 È “fatto”? .......................................................................................................................................................................... 18 2.1.3 Persone, non processi! ................................................................................................................................................ 19 2.2 Uno sguardo al processo di XP ....................................................................................................................................... 20 2.2.1 La specifica dei requisiti in XP ................................................................................................................................ 21 2.2.2 “The Planning Game” ................................................................................................................................................. 22 2.2.3 L’anima di XP ................................................................................................................................................................. 24 2.3 L’approccio di Crystal ........................................................................................................................................................ 25 2.3.1 Crystal Clear ................................................................................................................................................................... 27 2.3.2 Crystal Orange ............................................................................................................................................................... 28 2.3.3 Crystal Orange/Web ................................................................................................................................................... 29 Capitolo 3 -­‐ Confronti e conclusioni ...................................................................................................................................... 31 3.1 Un’analisi trasversale ........................................................................................................................................................ 31 3.1.1 Supporto alla gestione del processo .................................................................................................................... 31 3.1.2 Guida pratica o concetti astratti? ......................................................................................................................... 33 3.1.3 Approccio standard o adattivo? ............................................................................................................................ 34 3.1.4 Quanta innovazione? .................................................................................................................................................. 35 3.2 Conclusioni ............................................................................................................................................................................. 37 Bibliografia ....................................................................................................................................................................................... 39 Articoli scientifici ........................................................................................................................................................................... 40 Sitografia ........................................................................................................................................................................................... 41 III
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Introduzione
Il rapido progresso tecnologico che ha caratterizzato gli ultimi decenni ha portato
all’introduzione dell’informatica nella quasi totalità dei settori, che riguardano sia
prodotti sia servizi. Un software avanzato che assista la produzione è, ormai, requisito
fondamentale per ogni azienda che voglia creare prodotti di qualità con tempi e costi
ridotti.
Come sono sviluppati i software in grado di supportare in maniera adeguata la
produzione?
Le varie fasi del cosiddetto ciclo di vita del software sono oggetto di studio da molti
anni e, secondo il contesto in cui vengono analizzate, presentano diverse peculiarità.
La progettazione di un sistema critico per il controllo della stabilità di un velivolo, ad
esempio, necessita che tutti i requisiti siano meticolosamente analizzati per verificare
che le varie interazioni non compromettano la sicurezza; ciò richiede una lunga fase
di analisi dei requisiti alla fine della quale si avrà un’idea chiara e definitiva dei
requisiti del sistema. «Quando questo approccio “pesante” […] [è] applicato a
sistemi aziendali di piccole e medie dimensioni, l’overhead richiesto [è] così alto che
a volte [domina] il processo di sviluppo del sistema» [Sommerville 2007].
4
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Si comprende facilmente, infatti, come un’azienda, influenzata dall’andamento dei
mercati e vincolata al rispetto di specifiche norme giuridiche, debba operare repentini
“cambi di rotta” e prendere decisioni spesso in contrasto fra loro. Tutto ciò si riflette
sul software. Un approccio come quello citato in precedenza necessita che i requisiti
siano completamente definiti, cosa che avviene raramente in contesti del genere.
Adottare soluzioni di sviluppo “pesanti” può portare a sviluppare software di qualità
nei tempi stabiliti ma non garantisce che siano ancora utili. Nascono, quindi, i metodi
agili.
In questo testo ci si propone di esaminare il processo di analisi dei requisiti per alcuni
fra i metodi agili più conosciuti e utilizzati. S’introdurrà il concetto di metodo agile
per poi proseguire con la presentazione di tre fra i metodi più famosi (SCRUM,
eXtreme Programming e Crystal) ponendo l’attenzione su come avviene la specifica
dei requisiti. Infine si metteranno in luce pregi e difetti dei metodi descritti e si
concluderà con un confronto.
5
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Capitolo 1
La nascita dei metodi agili
Negli anni ’90 alcuni sviluppatori software proposero nuovi metodi di sviluppo che
presero il nome di metodi agili.
Il motivo principale per cui divenne necessario trovare un nuovo modo di “fare
software” fu che, con i metodi tradizionali, «si impiegava più tempo per decidere
come il sistema sarebbe stato sviluppato piuttosto che per lo sviluppo e il test del
programma» [ Sommerville 2007].
L’idea comune che
unisce tutti i metodi
agili
è
quella
di
sviluppo e consegna
incrementale per cui
durante la produzione
si attraversano più di
una volta tutte le fasi del ciclo di vita del software (“sviluppo ciclico”). Il software
sarà sviluppato e consegnato per incrementi, ognuno dei quali implementerà una
nuova funzionalità testata e pronta per essere commercializzata. In questo modo si
6
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
guadagna il feedback degli utenti così da comprendere più a fondo pregi e difetti del
prodotto realizzato.
1.1 I principi dei metodi agili
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
Questi quattro punti rispecchiano ciò che i firmatari del manifesto agile
(www.agilemanifesto.org) considerano importante nella creazione del software.
Gli individui e le interazioni fra essi sono più importanti dei processi e degli
strumenti poiché i progetti sono fondati sulle persone: queste devono essere motivate
e devono lavorare in un ambiente che garantisca adeguato supporto.
Si deve preferire un software funzionante a una documentazione esaustiva: quale
metro migliore per misurare il progresso del rilascio frequente di software
funzionante!
Meglio collaborare col cliente piuttosto che negoziare un contratto: una
conversazione “face to face” elimina fraintendimenti e rende tutti uniti per
raggiungere gli obiettivi.
Seguire un rigido piano rende meno flessibili, pertanto anche a stadi di sviluppo
avanzati i cambiamenti vanno accolti per favorire la competitività del cliente.
7
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
1.2 Attenzione ai requisiti!
Mentre in passato si dava molta importanza alla specifica minuziosa dei requisiti,
l’avvento dei metodi agili propone di prestare maggiore attenzione al fare piuttosto
che al progettare. Questa proposta, nata per venire incontro a esigenze di sviluppo
veloce del software, è stata fraintesa. La continua richiesta di programmi avanzati ed
evoluti ha portato all’eccesso opposto: «doing requirements takes time — time that
could be spent writing code — and users often feel better if they think that people are
“working” […] on their problems» [Ken Orr IEEE software 2004] ovvero:
“Analizzare requisiti prende tempo – tempo che potrebbe essere speso scrivendo
codice – e gli utenti spesso si sentono più sereni pensando che le persone ‘lavorino’
sui loro problemi”.
Si è giunti, dunque, a considerare quasi superflua l’analisi dei requisiti sacrificando la
comprensione del progetto cui si lavora in favore della sua rapida creazione. Ken Orr,
nell’articolo “Agile Requirements: Opportunity or Oxymoron?” pubblicato sulla
rivista “IEEE Software” nel 2004, osserva come un analista, invece di assumere il
ruolo passivo di scrivere ciò che gli utenti chiedono, dovrebbe aiutarli a inventare i
requisiti. Infatti – dice – obiettivi e vincoli che il sistema deve rispettare spesso non
sono chiari agli utenti, per cui c’è bisogno che qualcuno li guidi attraverso il processo
di analisi.
Neil Maiden e Alexis Gizikis (Centre for HCI Design, City University, London)
insieme a Suzanne Robertson (The Atlantic Systems Guild) nell’articolo “Provoking
Creativity: Imagine What Your Requirements Could Be Like” (IEEE Software, vol.
21, no. 5, 2004, pp. 68–75) riportano i risultati dell’esperienza fatta lavorando con
EUROCONTROL (European Organisation for the Safety of Air Navigation).
L’obiettivo
era
di
progettare
e
implementare
RESCUE
(Requirements
Engineeringwith Scenarios for User-centered Engineering), un processo per
determinare i requisiti di interesse per gli utenti, applicandolo ad un sistema che
fornisce assistenza computerizzata ai controllori di traffico aereo per risolvere
potenziali conflitti tra velivoli (CORA-2).
8
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Per stimolare la creatività i progettisti hanno coinvolto membri del team e
stakeholders in quelli che chiamano “workshop”. Durante il primo di questi sono stati
invitati esperti di design tessile e compositori musicali per incoraggiare confronti e
analogie tra i due settori e CORA-2. Durante il secondo un esperto fabbricante di
giochi Lego ha introdotto oggetti a caso durante discussioni su scenari di risoluzione
dei conflitti tra velivoli allo scopo di provocare pensiero creativo. Per il terzo, infine,
è stato invitato un fusion chef a discutere il legame fra ingredienti non convenzionali
facendoli assaggiare; lo chef ha inoltre dato dimostrazione della cucina fusion
preparando un pranzo che ha messo in luce le differenze tra gli ingredienti ma anche
la loro complementarietà.
Ogni workshop, inoltre, partiva con attività mirate a creare il giusto ambiente per
sviluppare pensiero creativo; tra queste le più singolari: palloncini per incoraggiare al
gioco e all’interazione, shouting sessions per contrastare inibizioni e incoraggiare il
lavoro di gruppo, ascolto di musica rilassante.
Da questo studio sono emerse le grandi difficoltà degli utenti nel definire i requisiti
per i propri software e il ruolo centrale che gli analisti dovrebbero avere nel guidarli
attraverso il processo.
1.3 Scriviamo i requisiti
Come abbiamo finora descritto, le tecniche agili hanno avuto un impatto molto forte
sul
processo
requisiti.
Ora
di
definizione
dei
occupiamoci
di
comprendere le novità che sono state
introdotte nella documentazione dei
requisiti.
Gli stakeholder scrivono le cosiddette
storie utente e ciò spesso accade
durante i workshop. Ogni storia utente
Storie Utente [Maiden and Jones, IEEE Software,
vol.27 no.3, 2010, pp. 87-88]
è
scritta
su
una
“cartolina”
di
9
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
dimensioni contenute (3x5 pollici) poiché semplicità e brevità sono caratteristiche
precipue delle storie utente. Ognuna descrive un requisito in maniera semplice dal
punto di vista dell’utente senza specificare troppi particolari. Ciò lascia spazio alla
comunicazione “faccia a faccia” durante la quale si definiscono meglio gli obiettivi di
ogni requisito. Ogni progetto genera molte storie utente in modo che sia semplice
selezionarle e gestire i requisiti da implementare.
Lan Cao e Balasubramaniam Ramesh nello studio condotto sull’utilizzo dei metodi
agili nella specifica dei requisiti (RE, “requirements engineering”), hanno identificato
sette pratiche di RE utilizzate dalle 16 organizzazioni prese in esame [IEEE Software
vol.25 no.1 January/February 2008, pp. 60-67, “Agile Requirements Engineering
Practices: An Empirical Study”]. Ognuna di queste presenta lati positivi e negativi:
•
Comunicazione “faccia a faccia” invece di specifiche scritte
o Benefits: I clienti guidano il progetto in direzioni inaspettate quando le
loro richieste mutano in seguito a cambi di “environment”. Il tempo
sprecato per consultare la documentazione, ora superflua a causa dei
cambiamenti ricorrenti, è utilizzato in maniera più produttiva.
o Challenges: È difficile che il cliente sia sempre disponibile per un
incontro e ciò pone dei rischi come la possibilità di avere requisiti non ben
sviluppati o, addirittura, sbagliati. L’effettiva comunicazione dipende,
oltre che dalla disponibilità, anche della fiducia reciproca tra team e
cliente. Infine se i clienti interessati al prodotto sono più di uno non è
facile raggiungere compromessi che mettano tutti d’accordo in cicli di
sviluppo brevi.
•
Specifica dei requisiti iterativa
o
Benefits: «I think the difference for me came in the quality of the software
[and] the stability of the software. […] I think the agile [RE] lent itself to
[…] a very robust rich implementation of features […] [for] the first
time»: le parole di un cliente, che confronta l’esperienza agile con quella
10
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
tradizionale, mettono in luce il rapporto di fiducia tra team e cliente che
nasce dai continui incontri e il conseguente piacere di quest’ultimo nel
vedere soddisfatte le proprie aspettative. I requisiti diventano più chiari e
comprensibili grazie all’immediato coinvolgimento del cliente quando
necessario.
o
Challenges: Complessità nello stimare costi e tempi: ottenere supporto
“manageriale” in progetti di questo tipo non è semplice. La poca
documentazione prodotta può causare vari problemi come la difficoltà di
migliorare il software e coinvolgere nuovi membri nel team. Requisiti non
funzionali sono spesso mal definiti poiché l’attenzione è focalizzata sulle
funzionalità principali e requisiti come scalabilità, manutenibilità,
portabilità, sicurezza o performance sono ignorati.
•
Frequenti cambi di priorità dei requisiti
o Benefits: Siccome nella RE agile la priorità dei requisiti è scelta in base
alle esigenze di mercato come sono intese dal cliente, la partecipazione di
quest’ultimo alla realizzazione fornisce in ogni ciclo di sviluppo
motivazioni, di tipo economico, per l’implementazione di un requisito
piuttosto che di un altro.
o Challenges: D’altro canto gestire la priorità dei requisiti guardando al
mercato come unico obiettivo può causare problemi riguardanti requisiti
non funzionali come stabilità, sicurezza, efficienza, scalabilità, etc.
•
La continua pianificazione cambia il modo di gestire i requisiti
o
Benefits: Il continuo confronto tra team e cliente fornisce maggior
consapevolezza riguardo al lavoro svolto poiché in ogni incontro l’attività
di pianificazione assume ruolo fondamentale. Per questo motivo la
maggior parte dei cambiamenti richiesti sono «usually more a case of
tweaks … spelling, little graphical things … for example, color,
positioning».
11
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
o
Challenges: Siccome l’architettura scelta durante le prime fasi del
processo produttivo diventa inadeguata in alcuni casi con il cambiare dei
requisiti, progettarne una nuova aggiunge costi al progetto. Spesso
neanche il refactoring, che semplifica il codice senza compromettere le
funzionalità, riesce a porre rimedio a problemi di architettura.
•
Uso di prototipi
o
Benefits: Invece di perdere tempo a scrivere documentazione dettagliata si
mostra al cliente il lavoro svolto per discuterne la validità.
o
Challenges: È complicato manutenere e aggiornare i prototipi e causa
problemi con requisiti come scalabilità, sicurezza e robustezza.
•
Sviluppo guidato dai test (TDD).
o
Benefits: Creare dei test prima di creare il codice che li supererà «allows
you to be more adventurous in terms of making changes and trying out
ideas» poiché si ha un feedback immediato del lavoro svolto.
o Challenges: Gli sviluppatori non sono abituati a scrivere i test prima del
codice. Sono necessarie una profonda comprensione dei requisiti e una
collaborazione intensiva tra sviluppatori e clienti.
•
Utilizzo review meetings e acceptance tests
o
Benefits: I review meeting riportano prima di tutto i progressi del progetto
al cliente e agli stakeholder e danno la possibilità di capire se il progetto
procede verso l’obiettivo desiderato. Inoltre fiducia e confidenza tra
cliente e team si fortificano.
o
Challenges: Spesso è difficile implementare gli acceptance test a causa
della difficoltà di far riferimento ai clienti che li hanno sviluppati.
Emerge, dunque, che la differenza fondamentale tra RE tradizionale e RE agile è che
quest’ultima sfrutta un approccio iterativo per scoprire i requisiti e non segue un
rigido piano di sviluppo. Ciò è dovuto al fatto che, in alcuni ambienti, ottenere
12
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
specifiche molto precise è praticamente impossibile oppure addirittura inutile in
quanto è probabile che cambino. Osservando i risultati dello studio di Cao e Ramesh
si capisce come la novità più “apprezzata” in ambienti del genere sia l’intensiva
comunicazione che porta il team a comprendere i desideri del cliente e rende lo
sviluppo più dinamico e adattabile.
13
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Capitolo 2
Tre metodi a confronto
In questo capitolo si cercherà di analizzare, per ogni metodologia agile proposta, il
processo di specifica dei requisiti al fine di fornire un punto di vista utile, nel capitolo
successivo, ad analizzare differenze e somiglianze e a comprendere in quali situazioni
una metodologia possa essere più utile rispetto a un’altra.
2.1 SCRUM Flow
Prima di parlare del processo di specifica dei requisiti in SCRUM occupiamoci di
dare un quadro generale del processo e delle persone che portano al rilascio del
software. Partiamo analizzando lo SCRUM Team composto da Product Owner, Team
e SCRUM Master.
o Il Product Owner è una persona che rappresenta il committente. È responsabile
della gestione del Product Backlog e ha il compito di massimizzare il valore
del lavoro svolto dal team. Le sue decisioni devono essere rispettate affinché il
suo lavoro sia efficace.
o Il Team è composto di più persone (in genere tra 3 e 9) che lavorano per
produrre un incremento del prodotto da consegnare alla fine di uno sprint. Il
14
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
team è organizzato in maniera autonoma ed è cross-funzionale. Ogni membro
ha le stesse responsabilità degli altri a prescindere dal ruolo svolto.
o Lo SCRUM Master ha, da una parte, il ruolo di “leader” per il team e, dall’altra,
d’intermediario tra il team e coloro che non ne fanno parte. Ha il compito di
verificare che il team comprenda e applichi le regole di SCRUM e quello di
riconoscere quali interazioni tra il team e gli stakeholder sono utili e quali no.
Lo Sprint è considerato il cuore di SCRUM. È un periodo durante il quale il team
produce un incremento del prodotto secondo le priorità imposte dal Product Backlog
allo scopo di rilasciare sul mercato funzionalità complete e testate. Lo Sprint consta,
oltre che di quella di sviluppo, di più fasi:
o Sprint Planning Meeting: riunione durante la quale sono pianificate le attività
da svolgere durante lo Sprint. Partecipa l’intero SCRUM Team. La prima
delle due fasi dell’incontro è incentrata su “cosa” sarà fatto durante lo Sprint:
il Product Owner presenta i punti del Product Backlog partendo da quelli a
priorità maggiore e, in base anche all’ultimo incremento e alle performance
precedenti del Team, si definisce l’Obiettivo di Sprint (o Sprint Goal) che sarà
perseguito. Il numero di punti del Product Backlog che saranno considerati
nello Sprint Goal e, quindi, implementati è deciso esclusivamente dal Team
poiché nessuno conosce meglio le sue potenzialità.
La seconda fase della riunione è incentrata sul “come” si porterà a termine il
lavoro in programma. In questa fase nasce lo Sprint Backlog fatto dalle voci
selezionate dal Product Backlog e dal piano per la consegna. Si progetta il
lavoro necessario all’implementazione dei requisiti scelti e, se risulta troppo o
troppo poco, si possono ridiscutere con il Product Owner le voci selezionate
dal Product Backlog.
15
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
La durata di un Meeting è di otto ore per uno Sprint di un mese. Se lo Sprint
dura meno, si avrà una riduzione proporzionata della durata del Meeting.
o Daily Scrum: Riunione giornaliera di 15 minuti (ogni giorno nello stesso posto
e alla stessa ora) utile al Team di Sviluppo per definire e sincronizzare le
attività della giornata in base al lavoro svolto il giorno precedente. Durante la
riunione ci si accerta che il lavoro svolto sia sempre in linea con lo Sprint
Goal. Lo SCRUM Master assicura e disciplina lo svolgimento della riunione
che è condotta, però, esclusivamente dal Team. L’obiettivo principale della
riunione, in fondo, è quello di migliorare le comunicazioni all’interno del
team per eliminare ostacoli come incomprensioni o malintesi nel pieno
rispetto delle metodologie agili.
o Sprint Review: Incontro che avviene al termine di uno Sprint per esaminare
l’incremento prodotto e modificare, se necessario, il Product Backlog.
Prendono parte alla riunione anche gli stakeholder. Si tratta di un colloquio
informale atto a suscitare i commenti dei partecipanti e a spronare la
collaborazione. Durante lo svolgimento il Team riporta l’evoluzione dello
Sprint evidenziando i problemi incontrati e le soluzioni trovate. In base al
lavoro prodotto, il Product Owner fa delle stime sul tempo ancora necessario e
discute col Team di eventuali accorgimenti da fare. Il risultato è un Product
Backlog riesaminato e aggiornato.
La durata dell’incontro è di quattro ore per uno Sprint di un mese. Se lo Sprint
dura meno, si avrà una riduzione proporzionata della durata dell’incontro.
o Sprint Retrospective: È una riunione di tre ore (dopo uno Sprint di un mese) che
riguarda esclusivamente il Team SCRUM. Lo scopo di tale incontro è far si
che il Team guardi a se stesso in modo critico e adatti il proprio atteggiamento
secondo i problemi che emergono per trovare soluzioni in maniera più
16
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
semplice. Lo SCRUM Master incoraggia tale attività e invita il Team a
individuare pratiche per rendere più efficace e divertente lo Sprint successivo.
SCRUM Flow [Ken Schwaber, “Agile Project Management with Scrum”, Microsoft Press © 2004]
2.1.1 La specifica dei requisiti in SCRUM
Quello di “Product Backlog” è il concetto intorno a quale gira il processo di specifica
dei requisiti in un ambiente di sviluppo software che sfrutta l’utilizzo di SCRUM. Il
termine indica la lista di requisiti ottenuta a valle di una discussione tra il team di
sviluppo e il cosiddetto “Product Owner”, che rappresenta il soggetto committente
ed è l’unico responsabile del Product Backlog.
La caratteristica precipua del Product Backlog è di non essere mai completo ma,
piuttosto, sempre in continua evoluzione in base alle modifiche che i requisiti
subiscono con l’avanzare del progetto e alla priorità che essi assumono. Ciò che si
trova alla base di questa caratteristica è la consapevolezza che lo sviluppo del
software in sé porta alla luce problematiche non prevedibili nell’analisi iniziale, cosa
che compromette anche le stime dei tempi di sviluppo più accurate.
17
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Gli elementi presenti nel Product Backlog sono spesso ordinati per priorità, rischio,
valore, necessità; in cima alla lista, in genere, si trovano gli elementi più discussi dal
team, quindi più conosciuti e consolidati, che saranno trattati per primi.
Al concetto di Product Backlog è strettamente legato quello di “Sprint”. Questo
termine indica la finestra temporale alla fine della quale sarà rilasciato un incremento
del prodotto potenzialmente utilizzabile che implementa parte delle funzionalità. La
durata di uno Sprint è molto limitata (in genere massimo un mese) in accordo al
principio di rilascio graduale che contraddistingue le metodologie agili. In questo
modo ogni funzionalità realizzata è testata a fondo prima del rilascio per garantire che
soddisfi le specifiche richieste. Al termine di ogni Sprint ha luogo una riunione
(“Sprint review”) in cui si discute il lavoro fatto durante lo Sprint appena concluso e
si concorda il lavoro che sarà fatto durante il successivo. Il Product Backlog in questa
fase si evolve in accordo con quanto emerso durante lo Sprint. Alla fine di questa
fase, dunque, si ottiene una lista aggiornata dei requisiti che il software deve
soddisfare e si conosce quale sarà il lavoro da svolgere durante lo Sprint che sta per
cominciare.
2.1.2 È “fatto”?
Presupposto fondamentale per la buona riuscita dell’analisi dei requisiti e per un buon
test delle funzionalità implementate è la condivisione del concetto astratto di “fatto”
(cfr. “done” in inglese). Com’è naturale, la definizione di un concetto astratto è
difficilmente condivisa da tutti, motivo per il quale concetti espressi in poche parole,
magari scritte, spesso sono confusi con altri secondo la personale interpretazione.
Citando Mike Cohn: «Written words are misleading - they look more precise than
they are» [Cohn 2009] ovvero “Le parole scritte sono fuorvianti – sembrano più
precise di quanto non lo siano.”
Definire, dunque, un’interpretazione comune del concetto di fatto giova enormemente
al processo di sviluppo giacché porta i membri del team a perseguire un obiettivo
comune e a lavorare in armonia giovandosi ognuno del lavoro degli altri.
18
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Si può facilmente capire, quindi, come diverse interpretazioni del concetto di
completezza incidano sulla stima dei tempi necessari allo sviluppo di una funzionalità
e, di conseguenza, sulla scelta di quanti e quali elementi del Product Backlog trattare
in uno Sprint.
2.1.3 Persone, non processi!
Il processo di produzione tradizionale è diviso in fasi ben distinte sulle quali è
difficile ritornare una volta concluse. Per quanto riguarda la specifica dei requisiti
quest’approccio produce un documento preciso e puntuale in cui le richieste del
cliente hanno una forma ben definita e vanno a tutti i costi rispettate. Ciò porta gli
sviluppatori a sentirsi “costretti” a implementare ciò che il documento prescrive e non
a condividere gli obiettivi che tale documento hanno prodotto.
SCRUM pone l’attenzione più sulle persone che sul processo di produzione giacché
quest’ultimo dipende dalle persone che lo intraprendono. Prendere in considerazione
un processo produttivo in maniera assoluta porta inevitabilmente a un calo della
qualità del prodotto o, quantomeno, ad avere tempi di produzione più lunghi.
Riportiamo le parole di Mike Cohn per comprendere meglio il concetto appena
espresso:
One of the goals of shifting to Scrum is to get the whole team working together
toward the goal of delivering a great product. We want to strip our development
process of bad habits that work against this goal. Written documents create
sequential hand-offs, which deprive the team of a unity of purpose. One person (or
group) defines the product; another group builds it. Two-way communication is
discouraged. Through the written document, one team member is saying, "Here's
what to do," and others are expected to do it. This type of master-and-servant
relationship is unlikely to create strong feelings of engagement on the part of the
servants. Rather than feeling responsible for the success of the product, they feel
responsible for doing what is described in the document. Discussions have the
19
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
opposite effect: Whole team discussions lead to greater buy-in by all team members
[Cohn 2009].
2.2 Uno sguardo al processo di XP
Diamo ora un rapido sguardo all’intero processo produttivo di eXtreme Programming
(XP d’ora in poi) in cui la specifica dei requisiti s’innesta. Oltre alle fasi di
Esplorazione e Pianificazione racchiuse nel Planning Game che vedremo nei
prossimi paragrafi, il processo XP consta di altre quattro fasi:
o Iterazioni verso il primo rilascio: fase caratterizzata da più iterazioni che portano alla prima versione del software pronta per essere utilizzata. Sono selezionate le storie e sono prodotti test funzionali per ogni iterazione. o Fase di produzione: durante la produzione potrebbe presentarsi la necessità di ridurre il tempo dedicato a ogni iterazione, di creare test prestazionali e di cambiare storie (dopo una discussione col Cliente). o Manutenzione: fase in cui il processo si trova per la maggior parte della sua vita; mentre il sistema è in esecuzione, si sviluppano nuove funzioni in modo da non interrompere l’erogazione dei servizi implementati e aggiungerne di nuovi. o Morte: questa fase “terminale” sopraggiunge quando i clienti non sono più
in grado di produrre storie oppure quando il sistema non è più in grado di
soddisfare le necessità del cliente. È la fase in cui bisogna necessariamente
produrre documentazione.
20
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
2.2.1 La specifica dei requisiti in XP
«We will plan by quickly making an overall plan, then refining it further and further
on shorter and shorter time horizons—years, months, weeks, days. We will make the
plan quickly and cheaply, so there will be little inertia when we must change it» [Beck
1999].
La specifica dei requisiti in XP è un processo che avviene durante la fase individuata
dal termine “The Planning Game”.
Questa pratica si basa su alcuni principi cardine:
• Pianificare in modo dettagliato esclusivamente il prossimo rilascio: si può pensare alle iterazioni successive ma assolutamente non nei dettagli. • Assumere responsabilità, non darle: il manager non può assegnare il lavoro, è ogni membro del team che deve decidere cosa può fare. • La stima dei tempi di realizzazione deve essere fatta da chi realizza. • Ignorare le dipendenze tra le parti del progetto: progettare come se le parti potessero cambiare in ogni istante. • Pianificazione orientata alle priorità: il cliente non ha bisogno di molti dettagli per fissare le priorità. 21
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
2.2.2 “The Planning Game”
L’obiettivo della pianificazione in XP è di eliminare imbarazzi e screzi tra clienti e
sviluppatori e incoraggiare la comunicazione. Ciò è conseguenza del fatto che non
esistono regole, per quanto flessibili, che possano eliminare le emozioni dalle
persone. È importante che esistano regole al fine di ricordare come ci si dovrebbe
comportare e di fornire un riferimento comune nel caso in cui le cose non procedano
per il giusto verso. Ognuna delle due parti, clienti e sviluppatori, deve rispettare
l’altra e solo in un ambiente di fiducia si può lavorare in maniera serena.
È necessario, quindi, avere delle regole che suggeriscano come impostare i rapporti,
ma è essenziale che rimangano dei suggerimenti in modo che, se il rapporto diventa
ben saldo, si possano anche modificare o rimuovere.
o Obiettivo: obiettivo del “gioco” è massimizzare il valore del software
prodotto. Dal valore del software si deve stimare il costo dello sviluppo e i
rischi che si corrono.
o Strategia: Il team tende a investire meno possibile per mettere in produzione
le funzionalità principali il più velocemente possibile con strategie atte a
ridurre i rischi. Quando al cliente diviene chiaro quali sono le funzionalità
più importanti il team può immediatamente metterle in produzione.
o I “pezzi” del gioco: I pezzi del plannig game sono le story card (in figura).
Ogni “storia” descrive, nel modo più semplice possibile, una funzionalità
che il sistema dovrebbe implementare. Seguendo questa pratica si avrà un
inquadramento generale della questione e non si creeranno rigidi schemi
da seguire.
22
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Story Card [Kent Beck, 1999, “Extreme Programming Explained: Embrace Change”] o I giocatori: Come si è già intuito, devono esserci due giocatori, il Cliente
(decide come il sistema deve essere) e lo Sviluppo (realizza il sistema).
o Le mosse: il gioco ha fondamentalmente tre fasi
§
Esplorazione: in questa fase i partecipanti si rendono conto di ciò
che il sistema dovrebbe fare. Il Cliente scrive una storia
descrivendo cosa dovrebbe fare il sistema, lo Sviluppo stima il
tempo d’implementazione. Nel caso la stima non sia possibile o ci
siano parti più importanti rispetto a altre, si divide la storia in più
parti.
§
Impegno: il Cliente propone una data di rilascio e lo Sviluppo
s’impegna a rispettarla. In questa fase il Cliente organizza le card
per valore, lo Sviluppo le organizza per rischio e comunica il
tempo necessario per realizzarle. Alla luce dei risultati, poi, il
Cliente sceglie le card da includere nell’iterazione.
§
Aggiornamento: all’inizio di ogni iterazione il Cliente sceglie le
storie da implementare che formino un sistema funzionante. Se lo
Sviluppo si accorge di essersi sopravvalutato può chiedere al
Cliente di rivedere le storie da implementare alla luce delle nuove
23
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
stime. Qualora il Cliente si renda conto di aver bisogno di una
nuova storia più urgente da implementare, la scrive e, dopo che lo
Sviluppo ne ha stimato i tempi di implementazione, la sostituisce
ad una meno urgente che richieda gli stessi tempi.
2.2.3 L’anima di XP
Ma cos’è realmente XP?
La risposta non è semplice come si può pensare. XP, dal punto di vista pratico, è solo
un mucchio di pratiche preesistenti unite sotto un unico nome. Il punto forte di tale
unione sta nel fatto che ogni pratica compensa i difetti delle altre al fine di risolvere
tutti i problemi che si presentano durante lo sviluppo. Questo non basta.
Ciò che fa funzionare l’intero meccanismo sono le persone! Ogni individuo ha un
bagaglio diverso di conoscenze ed esperienze. Come fare a sfruttarle a pieno? XP
propone una serie di valori da rispettare per raggiungere completa sinergia all’interno
del team.
o Comunicazione: «Problems with projects can invariably be traced back to
somebody not talking to somebody else about something important» [Beck
1999]. XP adotta molte pratiche che portano necessariamente le persone a
comunicare (testing, programmazione di coppia e stime portano sviluppatori e
clienti a confrontarsi).
o Semplicità: Fare le cose semplici spesso risulta molto complicato; è difficile
non pensare “in avanti” e agire solo in relazione al problema presente. XP,
dunque, preferisce fare cose più semplici oggi, eventualmente pagando
domani per cambiarle, rispetto a fare cose complicate che potrebbero non
servire mai.
24
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
o Feedback: «Don't ask me, ask the system» [Beck 1999]. Non c’è nulla di
meglio che conoscere in ogni momento lo stato del sistema. L’unico modo per
sapere se un’unità logica o un’intera funzionalità sono state ben implementate
è l’attività di test.
o Coraggio: Questo aspetto, unito ai precedenti, può portare grandi benefici allo
sviluppo del sistema. Osare, sapendo di avere l’appoggio dei colleghi e di
avere un sistema semplice e testabile in ogni sua parte, diventa fondamentale
per uscire da eventuali situazioni di stallo del progetto. Bisogna avere
coraggio, ad esempio, per buttar via codice scritto durante un’intera giornata e
ricominciare da zero con un approccio diverso.
o Rispetto: È molto importante rispettare il proprio e l’altrui operato. Ognuno
deve puntare a un lavoro di qualità senza interferire con quello degli altri.
Ogni compente del team deve sentirsi accettato: ciò assicura motivazione e
lealtà all’interno del gruppo e conduce verso l’obiettivo con unità e serenità.
[Beck 2004]
2.3 L’approccio di Crystal
Qual è l’approccio migliore da utilizzare nell’ambito dello sviluppo Software?
Alistair
Cockburn
l'ideazione
di
risponde
una
famiglia
con
di
metodologie che va sotto il nome di
“Crystal”.
L’idea
è
nata
dalla
convinzione che non è possibile
adottare la stessa metodologia per tutti
i progetti a prescindere dal numero di
25
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
persone che vi prendono parte e dalla criticità del progetto.
Nel grafico in figura spostandosi lungo le ascisse varia il numero di persone coinvolte
nel progetto e spostandosi lungo le ordinate è la delicatezza del sistema a variare
attraverso quattro livelli di criticità:
o Life: Un guasto nel sistema può causare perdita di vite umane.
o Essential money: Un guasto nel sistema può causare perdite ingenti di denaro.
o Discretionary money: Un guasto nel sistema può causare perdita di denaro ma
si può correggere consultando il manuale utente.
o Comfort: Un guasto nel sistema può causare perdita di comfort per l’utente.
Secondo l’entità del progetto, dunque, bisogna adottare una metodologia più o meno
pesante.
«As with geological crystals, each has a different color and hardness, corresponding
to the project size and criticality: Clear,
Yellow, Orange, Orange / WebStream,
Red, Magenta, Blue and so on» [Cockburn
2001].
L’obiettivo di Crystal non è di garantire
“compatibilità” tra le sue varie versioni
ma di offrire la possibilità a persone che
lavorano a un piccolo progetto di potersi
chiedere, qualora il progetto dovesse
aumentare di dimensione e richiedere risorse umane maggiori, “quale sia il modo
migliore di far lavorare in armonia più persone” e non “come preservare le precedenti
condizioni di lavoro”.
«Software development is usefully viewed as a cooperative game of invention and
communication, with the primary goal of delivering useful, working software, and the
secondary goal of setting up for the next game» [Cockburn 2001]: la filosofia di
Crystal riflette quella precipua dei metodi agili per cui l’obiettivo principale è di
26
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
consegnare software utilizzabile in maniera incrementale e che soddisfi le specifiche;
ciò deve avvenire attraverso cooperazione e comunicazione tra cliente e team. È
necessario, poi, tenere traccia dei progressi per gettare le basi per le successive
iterazioni.
Crystal ha due valori fondamentali:
• È basata sulle persone e sulla comunicazione tra queste.
• Ha una grande tolleranza verso i diversi modi di lavorare dei membri del team.
Nei paragrafi successivi descriveremo tre delle metodologie della famiglia Crystal.
2.3.1 Crystal Clear
Crystal Clear è una metodologia pensata per progetti di categoria D6. È possibile
allargarne l’uso a progetti di dimensioni leggermente maggiori ma si può andare
incontro a problemi di comunicazione quando troppe persone prendono parte al
progetto e diventa un problema condividere gli spazi. Gli sviluppatori, infatti, hanno
la piena libertà di scegliere il metodo che più ritengono opportuno per lo sviluppo del
progetto ma devono rispettare il vincolo di condividere lo spazio di lavoro in modo da
poter comunicare liberamente.
I ruoli presenti in Crystal Clear sono i seguenti:
o Sponsor
o Senior Designer-Programmer
o Designer-Programmer
o User (presente almeno part-time)
Una di queste figure deve assumere il ruolo di coordinatore, un'altra quello di
Business Expert e qualcuno deve occuparsi dei requisiti.
I requisiti sono espressi utilizzando UML e raccolti sotto forma di casi d’uso.
Le regole standard sono:
• Il software è rilasciato regolarmente ogni due-tre settimane sotto forma di
incrementi.
27
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
• Si tiene traccia dei progressi attraverso rilasci di software invece che con
documentazione scritta.
• Si realizzano test di regressione automatici per assicurarsi che l’aggiunta o la
modifica di funzionalità non interferisca con quelle già realizzate.
• Ci deve essere coinvolgimento diretto del cliente nel progetto.
• Un’attività può partire solo quando la precedente è “sufficientemente stabile”.
• All’inizio e a metà dell’incremento hanno luogo i workshop per discutere del
prodotto e della metodologia de seguire.
Durante un’iterazione è possibile utilizzare la metodologia che si desidera (SCRUM,
XP, etc)
2.3.2 Crystal Orange
Crystal Orange è una metodologia ideata per un progetto di categoria D40. Tali
progetti hanno una durata di uno-due anni.
Per progetti di media-bassa portata, che richiedono più di 10 persone, il team è diviso
in più gruppi cross-funzionali ognuno dei quali deve avere un Business AnalystDesigner, un UI Designer, uno-tre Designer-Programmers, un Database Designer, un
Tester e persone che conoscano le altre tecnologie usate nel progetto.
Il numero dei rilasci è minore poiché sarebbe troppo costoso per un progetto così
lungo avere la stessa frequenza di rilasci di un progetto più piccolo. L’obiettivo di
avere gruppi cross-funzionali è proprio quello di abbassare il numero dei rilasci e
favorire la comunicazione “locale”. I vari gruppi sono considerati le unità
fondamentali del progetto per cui ogni persona all’interno del gruppo può essere utile
ogni volta che serve e non per un unico tipo di lavoro.
Rispetto alla versione Clear, Orange richiede maggior documentazione. I requisiti
dovrebbero essere definiti in linguaggio naturale, i documenti riguardanti la
28
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
progettazione dovrebbero essere chiari sia per gli sviluppatori sia per gli stakeholder e
definiti con specifiche formali come diagrammi di stato.
Come accade per Crystal Clear, infine, anche Crystal Orange lascia decidere al team
quali metodologie adottare come standard (SCRUM, XP, etc.) e anche decisioni come
stile di programmazione, standard per interfacce utente, dettagli dei test sono lasciate
al team.
2.3.3 Crystal Orange/Web
Crystal Orange / Web è una metodologia classificata idonea per situazioni di tipo E50
poiché è stata ideata ad hoc per una compagnia che annovera 50 persone e si occupa
di situazioni classificate con criticità Essential money. La compagnia in questione è la
Ebucks.com, che si occupa di fornire codice per il web con flusso continuo
[Cockburn 2001]. La grande differenza tra questa versione di Crystal e le precedenti è
che in questo caso si parla di continue richieste di codice che afferiscono non più ad
uno, ma a più progetti diversi.
Ciò che più interessa di questa “nuova versione” di Crystal Orange è che è stata
disegnata per una compagnia che ha già un ruolo definito sul mercato. Non ha,
quindi, requisiti stringenti in termini di time-to-market, quanto piuttosto in termini di
cost of defects. In altre parole, l’obiettivo più importante è che ci siano meno errori
possibile.
Il focus si sposta, quindi, dalla produttività alla assenza di difetti.
Da interviste a persone operanti in ruoli diversi, si evince che la comunicazione
all’interno del team – i cui membri lavorano fianco a fianco in postazioni di lavoro
ubicate allo stesso piano dell’edificio – risulta già buona. L’organizzazione delle
postazioni, però, divide gli sviluppatori dai manager, fatto che potrebbe separare i due
gruppi negli obiettivi e negli interessi. Inoltre, poiché ognuno lavora a molti progetti
29
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
diversi, le interruzioni sono molte e non favoriscono la concentrazione necessaria a
portare a termine un buon lavoro. D’altro canto, però, essendo la compagnia
abbastanza giovane, le abitudini non sono ancora consolidate ed è facile intervenire.
Alla luce di queste notizie prende forma Crystal Orange/Web come insieme di
convenzioni divise in cinque categorie.
o Regular Heartbeat, with Learning: ci si propone di scegliere un modo di procedere che garantisca la possibilità di analizzare il lavoro svolto e riflettere su come migliorarlo. o Basic Process: si assegnano dei ruoli in modo da organizzare meglio il lavoro ed evitare sforzi inutili. o Maximum progress, minimum distractions: ci si deve concentrare su ciò che porta maggior profitto alla compagnia. Questo avviene tramite assegnazione di priorità e divisione del lavoro in modo che quel che si realizza possa essere testato a fondo alla fine di ogni ciclo. o Maximally defect-­‐free: “kill bugs here!”. Si prova a eliminare gli errori prima possibile testando il codice realizzato e facendolo valutare ad altre persone. o A community, aligned in conversation: la compagnia deve far si che ogni individuo conosca l’obiettivo a lungo termine a cui si sta puntando in modo che possa condividerlo e sentirsi partecipe. Si possono organizzare riunioni in cui ognuno avanzi proposte, anche non relative al proprio campo, che contribuiscano a far progredire il progetto. 30
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Capitolo 3
Confronti e conclusioni
3.1 Un’analisi trasversale
Abbiamo analizzato i tre metodi agili proposti sotto diversi aspetti. Cerchiamo ora di
evidenziare i punti di contatto e le differenze riguardo alla specifica dei requisiti.
Puntiamo quindi il fuoco su:
1. quanto ogni metodologia fornisca supporto alla gestione del processo di specifica dei requisiti; 2. se i metodi offrano una guida concreta alla definizione dei requisiti in termini di tecniche oppure un insieme di principi astratti; 3. quanto ogni metodo sia disegnato per adattarsi a diverse situazioni piuttosto che fornire una guida rigida e poco flessibile. 4. l’innovazione introdotta da ogni metodo. 3.1.1 Supporto alla gestione del processo
Sviluppiamo il primo punto (ausilio alla gestione del progetto) analizzando come ogni
metodo affronta la gestione della fase di specifica dei requisiti.
31
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
o SCRUM è la metodologia che è maggiormente orientata alla descrizione
del processo di specifica dei requisiti poiché propone di attraversare fasi
di durata ben precisata entro le quali determinate attività devono essere
svolte. Se pensiamo allo Sprint Planning Meeting, ad esempio,
possiamo notare che, durante questa riunione, tutte le attività da
svolgere durante uno Sprint sono attentamente pianificate. Se, poi,
diamo uno sguardo anche agli altri incontri che avvengono con cadenza
periodica, come Daily Scrum e Sprint Review, notiamo come essi
abbiano come obiettivo principale quello di aggiornare, attraverso
continui feedback, il Product Backlog, fonte scritta dei requisiti in
SCRUM. [cfr. par. 2.1 - 2.1.1]
o XP, di contro, non offre determinate strategie atte a gestire il processo di
definizione dei requisiti. Non c’è una divisione sistematica del tempo
come avviene in SCRUM, sono solo raggruppate tecniche preesistenti
che in passato hanno aiutato a organizzazione la specifica dei requisiti.
Come abbiamo già visto, il cliente scrive una storia e gli sviluppatori ne
stimano il tempo d’implementazione. Qualora la stima sia impossibile,
oppure ci siano parti più importanti di altre, la storia può essere divisa
in più parti [cfr. par. 2.2.2]. Troviamo ciò che operativamente va fatto,
dunque, ma non un’organizzazione in step che aiuti il management.
o La famiglia delle metodologie Crystal, poiché non offre un vero e
proprio contributo alla fase di definizione dei requisiti, non fornisce una
descrizione di come affrontare tale fase. Si concentra di più sul
32
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
potenziamento della capacità di scegliere il giusto approccio in base
all’entità del progetto (quindi il giusto colore) [cfr. par. 2.3].
3.1.2 Guida pratica o concetti astratti?
Occupiamoci ora di capire se i metodi proposti forniscano una guida pratica alla
definizione dei requisiti, oppure diano solo una serie di consigli astratti volti a guidare
i membri del team attraverso il processo senza imporre alcuna regola pratica e
lasciando spazio alla creatività.
o SCRUM cerca di non imporre tecniche ben precise, piuttosto cerca di
essere un punto di riferimento per il team per quanto riguarda
l’organizzazione e lo stato d’animo da assumere durante il lavoro di
specifica dei requisiti. Il concetto di Product Backlog evidenzia proprio
quest’aspetto: essendo un artefatto mai completo, deve sempre essere
aggiornato e ciò spinge il team a riunirsi molto spesso per discutere dei
problemi che emergono durante il progetto, delle modifiche da
apportare ai requisiti e, soprattutto, del modo di lavorare al fine di
portare a termine un obiettivo comune [cfr. par. 2.1.1]
o XP, dal canto suo, è invece un metodo che fornisce indicazioni specifiche
su “come” procedere operativamente nella definizione di un requisito.
Si è visto come le storie utente (o story card) giochino un ruolo centrale
nel processo. Il cliente descrive in maniera semplice ciò che il sistema
dovrebbe fare tramite una “storia”, il team valuta i tempi di sviluppo e
si concordano le priorità in base all’urgenza e ai rischi stimati [cfr. par.
2.2.1 – 2.2.2]
33
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
o Ancora una volta troviamo la famiglia delle metodologie Crystal senza
proposte particolari: non è fornita nessuna linea guida, né pratica né
teorica, per definire i requisiti. Crystal, in ogni variante analizzata,
impone solo di seguire degli standard senza specificare esattamente
quali. Lascia la possibilità, dunque, di scegliere le regole che si
reputano più adatte citando come scelte possibili anche gli altri due
metodi che abbiamo analizzato, SCRUM e XP.
3.1.3 Approccio standard o adattivo?
Evidenziamo adesso come ogni metodo si comporta di fronte a situazioni fra loro
diverse, se adotta una soluzione “universale” oppure cerca di adattarsi alle diverse
situazioni studiando il miglior modo per sfruttare i punti di forza e ridurre i problemi.
o SCRUM si può definire senz’altro una metodologia che cerca di adattarsi
a ogni situazione. Basti pensare alle continue riunioni organizzate per
controllare se il lavoro stia perseguendo l’obiettivo proposto (Sprint
Goal). Durante il Daily Scrum, ad esempio, una delle attività principali
è controllare che il lavoro svolto sia in linea con quanto deciso.
Un’ulteriore osservazione che porta a definire SCRUM una
metodologia adattiva si può fare riguardo lo Sprint Retrospective:
durante questa riunione il team cerca di analizzare criticamente il
proprio operato non solo in termini di risultati ma anche di approccio, al
fine di adattare il proprio atteggiamento ai problemi che emergono per
risolverli con semplicità e, magari, anche in modo divertente e
motivante [cfr. par. 2.1].
34
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
o XP è una metodologia nata dall’unione di tecniche che in passato hanno
contribuito in maniera incisiva alla buona riuscita di determinati
progetti. Per questa sua natura si presta molto bene ad adattarsi a ogni
situazione grazie all’idea che tecniche diverse usate insieme possano
coprire i difetti l’una dell’altra. Se a ciò, poi, si uniscono persone che
condividono un obiettivo e possono mettere in campo conoscenze
diverse derivanti dalle più disparate esperienze, si può facilmente capire
come XP sia effettivamente una metodologia adattiva [cfr. 2.3.3].
o Osservando la famiglia Crystal, a primo impatto si nota come questa
suggerisca diverse metodologie secondo l’entità del progetto. Verrebbe,
quindi, da concludere che anche Crystal sia una metodologia orientata
alla flessibilità. Dobbiamo, però, fare attenzione: Crystal non permette
di adattare effettivamente il processo produttivo al caso specifico, ma si
occupa solo di scegliere uno dei possibili processi in base all’entità del
progetto. Una volta compresa l’entità del progetto e, quindi, scelto il
“colore” di Crystal da utilizzare, il processo da seguire è già definito.
All’interno di ogni processo, poi, Crystal lascia al team la possibilità di
scegliere uno standard (che può anche essere orientato all’adattamento)
ma non propone effettivamente soluzioni adattive [cfr. par. 2.3 – 2.3.3].
3.1.4 Quanta innovazione?
Cerchiamo ora di individuare le innovazioni introdotte dai tre metodi analizzati
provando a fornire un quadro generale e semplificato di ciò che è emerso dalle
considerazioni fatte.
35
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
o Per quanto riguarda SCRUM, abbiamo visto come questo metodo introduca un modo nuovo di intendere il processo produttivo e la specifica dei requisiti. Le pratiche introdotte sono innovative nella loro struttura in quanto, a differenza dei metodi classici in cui ha luogo un’unica riunione in cui si definiscono i requisiti una volta per tutte, SCRUM prescrive incontri periodici, tra i membri del team e con il cliente, al fine di raggiungere l’obiettivo desiderato, anche se questo cambia in itinere. L’atteggiamento proposto da questa metodologia ha il chiaro intento di spingere le persone a condividere un obiettivo e a portarlo a termine in modo sereno e, perché no?, anche divertente. o Le considerazioni fatte su XP, invece, portano a inquadrarlo come un metodo che ha raggruppato molte pratiche in uso già nei metodi classici al fine di sfruttare le proprietà utili di ognuno. Non propone, dunque, grandi innovazioni, né dal punto di vista tecnico, né da quello organizzativo, se si escludono i principi che caratterizzano tutti i metodi agili (es. consegna incrementale, coinvolgimento del cliente, etc.). È una metodologia che cerca di usare al meglio ciò che già esiste imponendo di preferire le soluzioni più semplici ed efficaci: la variabilità dei requisiti potrebbe rendere vano lo sforzo impiegato a produrre qualcosa che forse non servirà mai. o La famiglia di metodologie Crystal prende in esame i principi dei metodi agili e cerca di riportarli a ogni tipo di progetto, tenendo conto del fatto che non tutti i progetti possono essere affrontati allo 36
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
stesso modo. L’innovazione introdotta da questo metodo è frutto di esperienza maturata osservando progetti di natura ed entità diverse. Cercare di utilizzare gli stessi principi in ogni progetto, senza considerare le proprietà intrinseche di ognuno, ha portato fallimenti e necessità di cambiamento. In base al numero di persone coinvolte e alla criticità, avviene una classificazione che incide sulla scelta dell’approccio. Ogni approccio è indicato da un colore cui corrisponde un processo definito. La vera innovazione, dunque, è data dall’intento di fornire una guida che aiuti a riconoscere e classificare i progetti. Per ogni colore, Crystal si occupa di fornire linee guida che aiutino la realizzazione. Crystal lascia i compiti più specifici agli altri metodi e si occupa di gettare le basi necessarie per comprendere a fondo situazioni di qualsiasi entità. Tabella riassuntiva Supporto alla gestione del processo Guida concreta vs. principi astratti Rigido vs. adattivo Innovazione introdotta SCRUM Presente Principi astratti Adattivo Incontri periodici XP Assente Guida concreta Adattivo Semplicità CRYSTAL Assente — Rigido Classificazione progetti 3.2 Conclusioni
A conclusione dell’analisi condotta, possiamo affermare che ognuno dei
metodi agili considerati per diversi aspetti introduce innovazioni atte ad
assistere il processo di specifica dei requisiti e, più in generale, l’intero
37
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
processo di sviluppo software. È interessante osservare come ogni
metodologia vada a incidere su diversi aspetti del processo secondo le diverse
esperienze degli ideatori. Abbiamo più volte rimarcato come XP sia stato
concepito per sfruttare al meglio le tecniche più utili dei metodi tradizionali e
come abbia cercato di rendere il processo più agile imponendo la semplicità
come principio cardine di sviluppo. Abbiamo visto come SCRUM
schematizzi meticolosamente ogni fase del processo di sviluppo introducendo
incontri periodici atti a favorire la comunicazione tra le persone. Abbiamo
notato come Crystal sia riuscito a trovare il modo di applicare i principi agili a
qualsiasi progetto senza trascurare l’entità di ognuno e abbia concepito una
guida per migliorare la produttività in ogni ambito e sotto diversi punti di
vista.
Ciò che ancora non abbiamo evidenziato è la grande passione che unisce tutte
le metodologie agili e i loro creatori: una passione profonda per il proprio
lavoro, talmente forte da concepirlo come un divertimento e come
un’occasione di crescita per ogni individuo. “Dobbiamo essere una grande
famiglia, in grado di comunicare in maniera efficace e di provare ogni giorno
la stessa eccitazione lavorando insieme per raggiungere il nostro obiettivo”:
ecco ciò che, in primis, vogliono comunicare gli ideatori di queste
metodologie.
38
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Bibliografia
[1] Beck Kent, 1999, “Extreme Programming Explained: Embrace Change” – 2nd
edition: 2004
[2] Cockburn Alistair, 2001, “Agile Software Development”
[3] Cockburn Alistair, 2004, “Crystal Clear: A Human-Powered Methodology for
Small Teams: A Human-Powered Methodology for Small Teams”
[4] Cohn Mike, 2005, “Agile Estimating and Planning”
[5] Cohn Mike, 2009, “Succeeding with Agile: Software Development Using Scrum”
[6] Highsmith James A., 2002, “Agile Software Development Ecosystems”
[7] Highsmith James A., 2009, “Agile Project Management: Creating Innovative
Products”
[8] Jeffries Ron, 2004, “Extreme Programming Adventures in C#”
[9] Martin Robert C., 2002, “Agile Software Development, Principles, Patterns, and
Practices”
[10] Martin Robert C., 2006, “Agile Principles, Patterns, and Practices in C#”
[11] Martin Robert C., 2008, “Clean Code: A Handbook of Agile Software
Craftsmanship”
[12] Paetsch
Frauke,
2003,
“Requirements
Engineering
in
Agile
Software
Development”, Diploma Thesis
[13] Pham Andrew, 2011, “Scrum in Action”
[14] Pichler Roman, 2010, “Agile Product Management with Scrum: Creating
Products that Customers Love”
[15] Schwaber Ken, 2004, “Agile Project Management with Scrum”
[16] Sommerville Ian, 2007, “Ingegneria del Software (ottava edizione)”
39
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Articoli scientifici
[1] Abrahamssona Pekka, Warstab Juhani, Siponenb Mikko T. and Ronkainena Jussi,
Proceedings of the 25th International Conference on Software Engineering
(ICSE’03), “New Directions on Agile Methods: A Comparative Analysis”
[2] Cao
Lan,
Ramesh
Balasubramaniam,
IEEE
Software
vol.25
no.1
January/February 2008, pp. 60-67, “Agile Requirements Engineering Practices:
An Empirical Study”
[3] Haugen Nils C., Proceedings of AGILE 2006 Conference, “An Empirical Study
of Using Planning Poker for User Story Estimation”
[4] Maiden Neil and Jones Sara, IEEE Software vol.27 no.3 May/June 2010, pp. 8788 “Agile Requirements - Can We Have Our Cake and Eat It Too?”
[5] Maiden Neil, Gizikis Alexis and Robertson Suzanne, IEEE Software vol.21 no.5
2004, pp. 68–75, “Provoking Creativity: Imagine What Your Requirements Could
Be Like”
[6] Orr Ken, IEEE Software vol.21 no.3 May/June 2004, pp. 71-73, “Agile
Requirements: Opportunity or Oxymoron?“
[7] Qasaimeh Malik, Mehrfard Hossein, Hamou-Lhadj Abdelwahab, Computational
Intelligence for Modelling Control & Automation, 2008 International Conference,
“Comparing Agile Software Processes Based on the Software Development
Project Requirements”
40
Le storie utente ed altre tecniche per la specifica di requisiti negli approcci Agili per lo
sviluppo software
Sitografia
[1]
http://alistair.cockburn.us/Articles , “Articoli online di Alistar Cockburn” [2]
http://www.agilealliance.org/ , “Agile alliance” [3]
http://www.agilemanifesto.org/ , “Manifesto Agile” [4]
http://www.scrum.org/scrumguides/ “Guida di SCRUM” 41