Agile requirements - alla ricerca del filo rosso (iad 2013)
124
1
-
Upload
fabio-armani -
Category
Business
-
view
3.110 -
download
0
description
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.
Transcript of Agile requirements - alla ricerca del filo rosso (iad 2013)
1
Agile Requirements
Alla ricerca del filo rosso
2
3
4
– CEO di OpenWare
– Direttore artistico dell’etichetta Different Lands
– Certified ScrumMaster & Scrum Professional
– PMI-ACP Certified
– @fabioarmani
– www.open-ware.org
Chi sono
5
6
7
COSA SONO I REQUISITI? Agile Requirements
8
9
10
11
12
Star Trike 13
Moto RV 14
15
16
So?ware requirements
Features
Needs
Problem space
SoluFon space
17
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
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
RequisiF so?ware
• Stabilire cosa richiede il cliente ad un sistema so?ware
• (Non stabilire come il sistema verrà costruito)
20
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 operaFvita del so?ware
21
22
23
24
PERCHÉ SONO NECESSARI I REQUISITI?
Agile Requirements
25
• 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
waterfall 27
agile 28
• Il primo rappresenta un ponte tra il problema di mercato da risolvere e la soluzione immaginata.
29
30
31
• 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
• Il secondo scopo del processo dei requisiF è la Comunicazione.
34
35
36
37
38
39
AG
ILE
40
41
42
43
44
45
Guardando da 10000 metri
46
Vision
Roadmap
Release
IteraFon
Day
5 livelli della pianificazione agile
47
• Lo stesso processo agile agisce (come un frattale) a differenti scale temporali, differenti time-box e livelli di pianificazione.
Stesso processo @ tutti I livelli
48
OGGETTI COINVOLTI Agile Requirements
49
Strategic
Tac>c
Theme
IniFaFve IniFaFve
Feature Feature Feature
Epic Epic Epic
T T T T T T T T T T TT T
Story Story Story Story Story Story
Story Story Story Story Story Story
50
Product Backlog
51
Product Backlog
Passare dalla documentazione alla discussione
52
Product Backlog
53
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
56
57
58
59
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
Epic Epic Epic
Story Story Story Story Story Story
Story
Story
61
62
Product Backlog
• Il Product Backlog deve essere DEEP (acronimo suggerito da Mike Cohn).
• Detailed Appropriately • EsFmated • Emergent • PrioriFzed
63
Backlog item
• Dai requisiF ai backlog item
Backlog Item Requirement 1…* 1…*
64
Backlog item
• Il Product Backlog può contenere molteplici Fpologie di elemenF (genericamente chiamaF Backlog item): – Feature – Epic – Story (user story, tech story) – Bug – …
65
Backlog Item Requirement 1…* 1…*
Backlog item
66
Backlog Item
Epic Story Feature
Is one of
Realized by Realized by 0,1 1…* 0,1 1…*
Requirement 1…* 1…*
Backlog item
67
Cos’è una”Feature”
68
69
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
Feature
• Una feature è un servizio fornito da un prodoTo per soddisfare uno o piu bisogni del cliente.
72
Feature
• Per esempio: "Il sistema offre un database relazionale per ges>re i da> persisten>”
73
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
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
75
Program Backlog Feature grain
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
76
Program Backlog Feature grain
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
77
Feature Story Realized by
0,1 1…*
78
79
80
81
82
83
Una User Story dovrebbe tagliare tutti i livelli dell'architettura
84
85
86
87
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
Backlog Item
Feature Story
Feature Acceptance Test
Is one of
Realized by
Done when passes
0,1 1..*
Story Acceptance Test
1
1..*
1
1..*
89
90
Story
91
Story Task Implemented by
0,1 1…*
92
93
Story Task
Done when passes
0,1 1…*
User Story Other work item
Story Acceptance Test Unit Test
Is one of
94
Story Task
Done when passes
0,1 1…*
User Story Other work item
Story Acceptance Test Unit Test
Is one of
95
96
97
Cos’è Test Driven Development?
98
RED
GREEN REFACTOR
1. Scrivi un test che fallisca
2. Rendi il codice funzionante
3. Elimina le ridondanze
99
• 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
102
Acceptance Test
103
104
Backlog Item Non-‐funcFonal Requirement
Constrained by
0..* 0..*
105
Backlog Item
Compliant when passes
Non-‐funcFonal Requirement
Constrained by
0..* 0..*
System QualiFes tests
1..*
0..*
106
NonfuncFonal requirement
• I nonfuncFonal requirement possono essere visF come dei vincoli sui Backlog
NFR
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
NFR
Story
Story
Story
Story
Story
Epic
Epic
Epic
107
FF
FURPS+
108
109
110
111
112
113
114
Q2Q1
Q3Q4
Critiques Product�Supp
orts
the T
eam�
Business Facing �
Technology Facing �
Unit Tests!Integration Tests
Functional Tests!Customer Tests!
Story Tests/Examples
User Acceptance Tests!Exploratory Tests!Usability Tests
Performance Tests!Load Tests!‘ility’ Tests
Product Owner�collaboration �
Customer�collaboration �
Developer�collaboration �
IT�collaboration �
115
116
Backlog Item
Feature Story Task
Feature Acceptance
Test
Is one of
Realized by Implemented by
Done when passes
Non-‐funcFonal Requirements
Constrained by
0,1 1…* 0,1 1…*
0…* 0…*
System QualiFes tests
User Story Other work item
Story Acceptance Test Unit Test
Is one of
Requirement 1…* 1…*
117
118
– CEO di OpenWare
– Direttore artistico dell’etichetta Different Lands
– Certified ScrumMaster & Scrum Professional
– PMI-ACP Certified
– @fabioarmani
– www.open-ware.org
Chi sono
119
A suivre … ;-‐) 120
Strategic
Tac>c
Theme
IniFaFve IniFaFve
Feature Feature Feature
Epic Epic Epic
T T T T T T T T T T TT T
Story Story Story Story Story Story
Story Story Story Story Story Story
Backlog Item
Feature Story Task
Acceptance Test
Is one of
Realized by Implemented by
Done when passes
Non-‐funcFonal Requirements
Constrained by
0,1 1…* 0,1 1…*
0…* 1…* Requirement
1…* 1…*
Backlog Item
Feature Story Task IniFat.
Acceptance Test Consumer Init. Architecture Init.
Is one of
Realized by Realized by Implemented by
Done when passes
Non-‐funcFonal Requirements
Constrained by
0,1 1…* 0,1 1…* 0,1 1…*
0…* 1…*
Strategic Product Theme
Realized by 1 1…*
Requirement 1…* 1…*
Disclaimer
124
