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.

1. 1

2. Agile
Requirements
Alla
ricerca
del
filo
rosso
2

3. 3

4. 4

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

6. 6

7. 7

8. Agile
Requirements
COSA
SONO
I
REQUISITI?
8

9. 9

10. 10

11. 11

12. 12

13. Star Trike
13

14. Moto RV
14

15. 15

16. 16

17. Problem
space
Needs
Features
So?ware
requirements
SoluFon
space
17

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

22. 22

23. 23

24. 24

25. Agile
Requirements
PERCHÉ
SONO
NECESSARI
I
REQUISITI?
25

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

27. waterfall
27

28. agile
28

29. • Il
primo
rappresenta
un
ponte
tra
il
problema
di
mercato
da
risolvere
e
la
soluzione
immaginata.
29

30. 30

31. 31

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

33. 33

34. • Il
secondo
scopo
del
processo
dei
requisiF
è
la
Comunicazione.
34

35. 35

36. 36

37. 37

38. 38

39. 39

40. AGILE
40

41. 41

42. 42

43. 43

44. 44

45. 45

46. Guardando da 10000 metri
46

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

49. Agile
Requirements
OGGETTI
COINVOLTI
49

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

51. Product
Backlog
51

52. Product
Backlog
Passare
dalla
documentazione
alla
discussione
52

53. Product
Backlog
53

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

55. 55

56. 56

57. 57

58. 58

59. 59

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

61. Story
Story
Story
Story
Story
Story
Story
Story
Epic
Epic
Epic
61

62. 62

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

66. Backlog
item
Requirement
1…*
1…*
Backlog
Item
66

67. Backlog
item
Requirement
1…*
1…*
Backlog
Item
Is
one
of
Feature
0,1
1…*
Realized
by
Epic
0,1
1…*
Story
Realized
by
67

68. Cos’è una”Feature”
68

69. 69

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

71. 71

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

75. Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
75

76. Feature
Feature
Feature
Feature
Program
Backlog
Feature
grain
Feature
Feature
Feature
Feature
76

77. Feature
Feature
Feature
Feature
Program
Backlog
Feature
grain
Feature
Feature
Feature
Feature
77

78. Feature
Realized
by
0,1
1…*
Story
78

79. 79

80. 80

81. 81

82. 82

83. 83

84. Una User Story dovrebbe tagliare
tutti i livelli dell'architettura
84

85. 85

86. 86

87. 87

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

90. 90

91. Story
91

92. Story
Implemented
by
0,1
1…*
Task
92

93. 93

94. Story
0,1
1…*
Task
Is
one
of
User
Story
Other
work
item
Done
when
passes
Story
Acceptance
Test
Unit
Test
94

95. Story
0,1
1…*
Task
Is
one
of
User
Story
Other
work
item
Done
when
passes
Story
Acceptance
Test
Unit
Test
95

96. 96

97. 97

98. Cos’è Test Driven Development?
98

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

101. 101

102. 102

103. Acceptance
Test
103

104. 104

105. Backlog
Item
Constrained
by
0..*
0..*
Non-­‐funcFonal
Requirement
105

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

108. FURPS+
FF
108

109. 109

110. 110

111. 111

112. 112

113. 113

114. 114

115. Product Owner
collaboration
Business Facing
User Acceptance Tests!
Exploratory Tests!
Usability Tests
Functional Tests!
Customer Tests!
Story Tests/Examples
Critiques Product
Supports the Team
Customer
collaboration
Q2 Q3
Q1 Q4
Performance Tests!
Load Tests!
‘ility’ Tests
Unit Tests!
Integration Tests
Developer
collaboration
Technology Facing
IT
collaboration
115

116. 116

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

118. 118

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

120. A
suivre
…
;-­‐)
120

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

124. Disclaimer
124