requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.
Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.
5. Chi sono
– CEO di OpenWare
– Direttore artistico
dell’etichetta Different Lands
– Certified ScrumMaster &
Scrum Professional
– PMI-ACP Certified
– @fabioarmani
– www.open-ware.org
5
18. Fred
Brook’s
“The
most
difficult
part
of
building
a
so7ware
system
is
to
decide,
precisely,
what
must
be
built.
No
other
part
of
the
work
can
undermine
so
badly
the
resul>ng
so7ware
if
not
done
correctly.
No
other
part
is
so
difficult
to
fix
later.”
18
19. Fred
Brook’s
“The
most
difficult
part
of
building
a
so7ware
system
is
to
decide,
precisely,
what
must
be
built.
No
other
part
of
the
work
can
undermine
so
badly
the
resul>ng
so7ware
if
not
done
correctly.
No
other
part
is
so
difficult
to
fix
later.”
19
20. RequisiF
so?ware
• Stabilire
cosa
richiede
il
cliente
ad
un
sistema
so?ware
• (Non
stabilire
come
il
sistema
verrà̀
costruito)
20
21. RequisiF
so?ware
• (so?ware
requirements):
descrizione
dei
servizi
che
un
sistema
so?ware
deve
fornire,
insieme
ai
vincoli
da
rispeTare
sia
in
fase
di
sviluppo
che
durante
la
fase
di
operaFvità
del
so?ware
21
26. • Ci
sono
due
principali
finalità
del
processo
di
requisiF,
a
prescindere
se
si
uFlizza
un
approccio
tradizionale
o
uno
agile
per
le
metodologie
di
sviluppo.
26
32. • Anche
se
il
problema
di
base
rimane
lo
stesso,
molte
soluzioni
possono
esistere
ed
i
requisiF
si
andranno
a
collegare
ad
una
tra
queste
possibili
soluzioni.
32
47. 5 livelli della pianificazione agile
Vision
Roadmap
Release
IteraFon
Day
47
48. Stesso processo @ tutti I livelli
• Lo stesso processo agile agisce (come un
frattale) a differenti scale temporali,
differenti time-box e livelli di
pianificazione.
48
50. Strategic
Theme
IniFaFve
IniFaFve
Feature
Feature
Tac>c
Feature
Epic
T
Epic
Story
Story
Story
T
Epic
Story
Story
Story
Story
Story
Story
Story
T
T
T
T
T
T
T
Story
Story
T
T
T
T
50
54. Vision
» Backlog
• Come
possiamo
passare
dalla
Vision
al
Product
Backlog?
• Ad
esempio
uFlizzando
una
serie
di
canvas
così
come
proposto
da
Roman
Pichler
54
60. Product
Backlog
• Ecco
alcune
cose
da
tenere
presenF
riguardo
il
product
backlog:
– I
requisiF
sono
emergenF
– Il
product
backlog
richiede
“grooming”
–
ovvero
un
conFnuo
raffinamento
dei
suoi
requisiF
– Il
Product
Backlog
può
essere
visto
come
un
iceberg
60
63. Product
Backlog
• Il
Product
Backlog
deve
essere
DEEP
(acronimo
suggerito
da
Mike
Cohn).
• Detailed
Appropriately
• EsFmated
• Emergent
• PrioriFzed
63
64. Backlog
item
• Dai
requisiF
ai
backlog
item
Requirement
1…*
1…*
Backlog
Item
64
65. Backlog
item
• Il
Product
Backlog
può
contenere
molteplici
Fpologie
di
elemenF
(genericamente
chiamaF
Backlog
item):
– Feature
– Epic
– Story
(user
story,
tech
story)
– Bug
– …
65
70. Feature
• Indipendentemente
dalla
forma,
il
contenuto
primario
della
Vision
è
un
insieme
di
feature
che
descrivono
quali
nuove
funzionalità
il
sistema
dovrà
fare
per
i
propri
utenF
e
quali
benefici
quesF
ulFmi
ne
trarranno.
Leffingwell
[2012]
70
72. Feature
• Una
feature
è
un
servizio
fornito
da
un
prodoTo
per
soddisfare
uno
o
più
bisogni
del
cliente.
72
73. Feature
• Per
esempio:
"Il
sistema
offre
un
database
relazionale
per
ges>re
i
da>
persisten>”
73
74. Feature
» CaraTerisFche
• Una
feature
è
un
elemento
valido
a
livello
di
strategia
e
cosFtuisce
un
elemento
del
Program
Backlog
• Inoltre
può
essere
considerato
un
elemento
di
transizione
tra
il
layer
strategico
e
quello
tajco
(di
esecuzione)
74
88. Acceptance
Tests
• Le
feature
come
le
user
story,
richiedono
acceptance
test
• Ogni
feature
richiede
uno
o
più
acceptance
test,
e
non
può
essere
considerata
done
finché
tuj
i
suoi
test
non
passano
88
89. Backlog
Item
Is
one
of
Feature
1
Realized
by
Story
0,1
1..*
1
Done
when
passes
1..*
Feature
Acceptance
Test
1..*
Story
Acceptance
Test
89
99. 1.
Scrivi
un
test
che
fallisca
RED
3.
Elimina
le
ridondanze
REFACTOR
GREEN
2.
Rendi
il
codice
funzionante
99
100. • L'uso
del
Test
Driven
Development
permeTe
non
solo
di
costruire
il
programma
assieme
ad
una
serie
di
test
di
regressione
automaFzzabili,
ma
anche
di
sFmare
in
maniera
più
precisa
lo
stato
d'avanzamento
dello
sviluppo
di
un
progeTo.
• E’
una
tecnica
di
design
e
di
coding.
100
106. Backlog
Item
Constrained
by
0..*
0..*
Non-‐funcFonal
Requirement
1..*
Compliant
when
passes
0..*
System
QualiFes
tests
106
107. NonfuncFonal
requirement
• I
nonfuncFonal
requirement
possono
essere
visF
come
dei
vincoli
sui
Backlog
Feature
Story
Feature
Story
Feature
Story
Feature
Story
Feature
Story
Feature
Epic
Feature
Epic
Feature
Epic
NFR
NFR
107
117. Requirement
Constrained
by
Backlog
Item
0…*
0…*
1…*
1…*
Is
one
of
Feature
Non-‐funcFonal
Requirements
System
QualiFes
tests
Realized
by
0,1
1…*
Story
Implemented
by
0,1
1…*
Task
Is
one
of
Feature
Acceptance
Test
User
Story
Other
work
item
Done
when
passes
Story
Acceptance
Test
Unit
Test
117
119. Chi sono
– CEO di OpenWare
– Direttore artistico
dell’etichetta Different Lands
– Certified ScrumMaster &
Scrum Professional
– PMI-ACP Certified
– @fabioarmani
– www.open-ware.org
119
121. Strategic
Theme
IniFaFve
IniFaFve
Feature
Feature
Tac>c
Feature
Epic
T
Epic
Story
Story
Story
T
Epic
Story
Story
Story
Story
Story
Story
Story
T
T
T
T
T
T
T
Story
Story
T
T
T
T
122. Requirement
1…*
1…*
Backlog
Item
0…*
1…*
Constrained
by
Non-‐funcFonal
Requirements
Is
one
of
Feature
0,1
1…*
Realized
by
Story
0,1
1…*
Implemented
by
Done
when
passes
Acceptance
Test
Task
123. Requirement
1…*
1…*
Backlog
Item
0…*
1…*
Constrained
by
Non-‐funcFonal
Requirements
Is
one
of
Strategic
Product
Theme
1
1…*
IniFat.
Realized
by
0,1
1…*
Feature
Realized
by
0,1
1…*
Realized
by
Story
0,1
1…*
Implemented
by
Done
when
passes
Acceptance
Test
Consumer
Init.
Architecture
Init.
Task