Service Oriented Agility @ Italian Agile Day - Bologna 2008
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Service Oriented Agility @ Italian Agile Day - Bologna 2008

  • 1,972 views
Uploaded on

My Agile vs SOA Presentation, which I held at the Italian Agile Day 2008 in Bologna

My Agile vs SOA Presentation, which I held at the Italian Agile Day 2008 in Bologna

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,972
On Slideshare
1,959
From Embeds
13
Number of Embeds
4

Actions

Shares
Downloads
25
Comments
0
Likes
0

Embeds 13

http://lanyrd.com 6
http://www.slideshare.net 3
http://www.linkedin.com 3
https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Buzzword
 Deathmatch: Si
può
fare
agile
in
una
 SOA?
  • 2. About
me • 10
di
esperienza
come
consulente
nel
mondo
IT. • Ho
partecipato
a
mol>
“grossi
proge@” – Pubblica
amministrazione – Bancario – Assicura>vo – ... • Un
po’
architeIura,
un
po’
processo,
un
po’
 management... • Il
mio
blog:
hIp://ziobrando.blogspot.com
 • Trainer
(Italia
e
UK) • Ar>coli,
etc. • My
e‐mail:
 alberto.brandolini@gmail.com
  • 3. Lo
scenario
Agile
  • 4. Perchè
Agile? Tradurre
  • 5. Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta>
  • 6. Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta> – Waterfall
è
“tradizionalmente”
associato
a

  • 7. Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta> – Waterfall
è
“tradizionalmente”
associato
a
 • cos>
eleva>

  • 8. Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta> – Waterfall
è
“tradizionalmente”
associato
a
 • cos>
eleva>
 • tempi
di
sviluppo
lunghi
  • 9. Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta> – Waterfall
è
“tradizionalmente”
associato
a
 • cos>
eleva>
 • tempi
di
sviluppo
lunghi • Impredicibilità
dei
risulta>
e
bassa
percentuale
di
 successo
  • 10. Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta> – Waterfall
è
“tradizionalmente”
associato
a
 • cos>
eleva>
 • tempi
di
sviluppo
lunghi • Impredicibilità
dei
risulta>
e
bassa
percentuale
di
 successo • Difficoltà
nella
ges>one
del
cambiamento
  • 11. Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta> – Waterfall
è
“tradizionalmente”
associato
a
 • cos>
eleva>
 • tempi
di
sviluppo
lunghi • Impredicibilità
dei
risulta>
e
bassa
percentuale
di
 successo • Difficoltà
nella
ges>one
del
cambiamento • Se
chiedete
in
giro,
nessuno
sta
più
facendo
il
 waterfall
(…o
almeno
così
dicono)
  • 12. Unified
Process
  • 13. Unified
Process • Lo
unified
process
ha
cambiato
radicalmente
 lo
scenario – Iterazioni
come
elemento
fondamentale
 del
processo. – Definizione
fine
di
ruoli
ed
ar@fact/ responsabilità
 – UML
come
linguaggio
“ufficiale” – Una
definizione
esaus@va
di
tuFe
le
 aGvità
chiave
del
processo.
  • 14. Unified
Process
 • Unfortunately,
it
also
set
the
ground
for – A
family
of
UML
modelling
tools – A
lot
of
documenta@on
templates 6
  • 15. Il
lato
oscuro
dello
Unified
Process
  • 16. Il
lato
oscuro
dello
Unified
Process • Gli
strumen>
sono
 diventa>
sempre
più
 importan>,
deformando
 il
processo
stesso.
  • 17. Il
lato
oscuro
dello
Unified
Process • Gli
strumen>
sono
 diventa>
sempre
più
 importan>,
deformando
 il
processo
stesso. • Analisi
e
design
sono
 diventate
a@vità
soliste
  • 18. Il
lato
oscuro
dello
Unified
Process • Gli
strumen>
sono
 diventa>
sempre
più
 importan>,
deformando
 il
processo
stesso. • Analisi
e
design
sono
 diventate
a@vità
soliste • Carta,
carta
ed
ancora
 carta...
  • 19. Sviluppatori Gli
sviluppatori
erano
considera>
 “risorse
interscambiabili”
il
cui
unico
 compito
era
di
implementare
le
 specifiche.
 Però
itera@vamente.

  • 20. Sviluppatori Gli
sviluppatori
erano
considera>
 “risorse
interscambiabili”
il
cui
unico
 compito
era
di
implementare
le
 specifiche.
 Però
itera@vamente.

  • 21. Sviluppatori Gli
sviluppatori
erano
considera>
 “risorse
interscambiabili”
il
cui
unico
 compito
era
di
implementare
le
 specifiche.
 Però
itera@vamente.

  • 22. Sviluppatori Gli
sviluppatori
erano
considera>
 “risorse
interscambiabili”
il
cui
unico
 compito
era
di
implementare
le
 specifiche.
 Però
itera@vamente.

  • 23. Sviluppatori Gli
sviluppatori
erano
considera>
 “risorse
interscambiabili”
il
cui
unico
 compito
era
di
implementare
le
 specifiche.
 Però
itera@vamente.

  • 24. Sviluppatori Gli
sviluppatori
erano
considera>
 “risorse
interscambiabili”
il
cui
unico
 compito
era
di
implementare
le
 specifiche.
 Però
itera@vamente.

  • 25. Sviluppatori Gli
sviluppatori
erano
considera>
 “risorse
interscambiabili”
il
cui
unico
 compito
era
di
implementare
le
 specifiche.
 Però
itera@vamente.

  • 26. Occasionalmente,
gli
archite@
passano
in
 rassegna
la
truppa...
  • 27. Ruoli
e
Responsabilità
  • 28. Ruoli
e
Responsabilità • La
ges>one
fine
dei
ruoli
ha
finito
per
 tradursi
in
un
faIore
di
rallentamento – Spesso
si
finisce
per
scegliere
solo
“i
task
 ada@
al
mio
ruolo” – (implicit
waterfall) – Tempi
di
risposta
più
len> – Colli
di
bo@glia
sigli
specialis>
(o
presun>
 tali) – Il
buon
caro
vecchio
scaricabarile – ...
  • 29. ...
I
ribelli
non
stanno
a
guardare
  • 30. ...
I
ribelli
non
stanno
a
guardare
  • 31. I
tre
gus@
dell’Agile • XP
ha
“faIo
il
boIo”
introducendo
 pra>che
rivoluzionarie
nello
sviluppo
 socware. • Scrum
ha
definito
un
framework
 all’interno
del
quale
le
pra>che
agili
 possono
essere
applicate
all’interno
di
 un
organizzazione. • Il
movimento
Lean
ha
introdoIo
 conce@
e
principi
dall’industria
 manifaIuriera,
nello
sviluppo
socware
 (fornendo
anche
un
retroterra
teorico
 ad
entrambe)
  • 32. eXtreme
Programming • User
Stories – Less
formal
than
Use
cases,
act
like
placeholder
for
a
real
discussion • Frequent
small
releases – Itera7ons
are
shorter
and
targeted
to
produc7on, • Frequent
planning
and
es4ma4on – Each
itera7on
is
re‐planned
according
to
the
currently
available
informa7on • No
an4cipated
development – No
frameworks
or
layered
architecture • Test
first – Test
suites
run
preserving
applica7on
integrity,
and
producing
beAer
interfaces • Customer
availability – Real
feedback
is
the
key
to
make
the
right
thing • No
code
ownership • Con4nuous
integra4on – The
whole
system
is
frequently
integrated
and
tested • Pair
programming – Programmers
work
in
pairs,
in
coding
sessions • No
over4me • ...
  • 33. XP • Il
feedback
è
l’elemento
chiave
per
molte
 delle
pra>che
proposte – dal
codice – dai
colleghi – dal
cliente – dal
progeFo – dal
team
 • Il
team
è
responsabilizzato
ed
incoraggiato
a
 proporre
soluzioni
crea>ve • Lo
stesso
processo
può
essere
modificato
  • 34. Scrum • Scrum
non
si
riferisce
streIamente
allo
 sviluppo
socware,
ma
offre
un
framework
 per
la
ges>one
ada@va
dei
proge@. • A
differenza
di
UP,
ci
sono
solo
3
ruoli: – Il
Team – Il
Product
Owner
 – Lo
Scrum
Master
  • 35. Lo
scenario
@pico
di
un
team
  • 36. Il
team
agile • Gruppi
di
piccole
dimensioni • Cross‐func>onal • Il
team
è
libero
di
prendere
qualsiasi
 decisione
di
design • In
Scrum,
il
team
riferisce
solo
al
P.O. – Un
cerimoniale
definito
ed
un
insieme
di
possibili
 azioni
garan>scono
che
il
gruppo
non
prenda
 direzioni
indesiderate.
  • 37. Mol@
stakeholders? Il
Product
 Owner
è
 l’unico
 responsabile
 per
il
gruppo
 di
sviluppo.
  • 38. I
principi
dello
sviluppo
Lean • Eliminate
waste – TuAo
ciò
che
non
fornisce
alcun
valore
per
l’utente. • Amplify
learning – Lo
sviluppo
è
un
aIvità
di
esplorazione
e
di
ricerca
di
soluzioni.
 • Decide
as
late
as
possible – Evitare
le
decisioni
irreversibili,
o
prenderle
solo
quando
si
disponde
di
 tuAe
le
informazioni
necessarie. • Deliver
as
fast
as
possible – Cicli
di
sviluppo
veloci
aiutano
il
feedback.
Spesso
la
velocità
è
meglio
 della
qualità. • Empower
the
team – Il
team
diventerà
il
massimo
esperto
sull’argomento.
 • Build
integrity
in – Il
soNware
deve
essere
u7le,
e
adaAo
al
compito. • See
the
whole – In
assenza
di
una
visione
complessiva
avremo
solo
oFmi
locali.
  • 39. Spreco • Lo
spreco
(waste)
può
apparire
in
varie
forme – Documentazione
non
necessaria – Design
an7cipato – Over
engineering – AIese – Comunicazioni
inefficien> – Dife@ – Handoff – Complessità – blame
(scaricabarile) – Qualità
(?) – ...
  • 40. L’approccio
Lo‐Fi • Come
conseguenza,
alcuni
tools
sono
sta>
 abbandona>,
in
favore
di
un
approccio
più
 materiale. – Carta
(user
stories,
CRC
cards,
burndown
chart) – Post‐it – Lavagne • Gli
Informa@on
radiators
sfruIano
la
prossimità
 fisica
per
permeIere
uno
scambio
di
 informazioni
più
efficiente
e
completo • Alcuni
Strumen>
sono
sta>
bandi>
(es.
 MSProject),
altri
sono
apparsi
(es.
Wikis)
  • 41. The
boFom‐up
 revolu@on • Agile
prepara
il
terreno
per
 fare
emergere
proposte
 interessan>
dal
team • Il
team
impara
and
si
 concentra
su
un
 determinato
spazio
di
 problemi,
spesso
diventando
 il
massimo
esperto
 disponibile
sull’argomento
  • 42. Col@vare
la
collaborazione • Raramente
si
lavora
isola> • Molte
a@vità
sono
svolte
in
 gruppo,
in
coppie
o
in
 maniera
visibile. • La
trasparenza
migliora
la
 fiducia
e
premeIe
una
 collaborazione
più
efficace. • Gli
scambi
di
informazione
 avvengono
in
entrambi
i
 sensi
  • 43. Lo
scenario
ideale • Non
tuIe
le
condizioni
di
partenza
sono
o@mali
 per
“diventare
agili”:
per
poter
sfruIare
 pienamente
il
potenziale
dell’agile
dovremmo
 (idealmente) – Essere
assun>
in
un’azienda
la
cui
massima
priorità
sia
 il
socware. – lavorare
nello
stesso
posto – Avere
accesso
agli
uten>
(qualsiasi
cosa
significhi) – Essere
liberi
di
crescere
come
team
ed
assumersi
 responsabilità. – Essere
liberi
di
scegliere
logis>ca,
hardware,
etc.
  • 44. Lo
scenario
SOA
  • 45. SOA
Ra@onale • Organizzazioni
di
grandi
dimensioni
erano
 appesan>te
dal
fardello
di – Svaria>
legacy
systems – Fusioni
and
acquisizioni • Necessità
di
integrare
sistemi
eterogenei • Sistemi
duplica@
e
ridondan@ – Elevata
complessità
(non
necessaria) • Cos@
opera@vi • Cos@
di
evoluzione – Tempi
di
reazione
estremamente
len>,
...sviluppi
 sostanzialmente
blocca>,
incapacità
di
produrre
 valore. • ...Ricorda
qualcosa?
  • 46. In
cerca
dell’uniformità Standard,
frameworks,
 regole
ed
integrazione
non
 hanno
garan>to
la
 necessaria
agilità
al
 business.
Con
il
risultato
di
 essere
un
ulteriore
fardello
 con
cui
fare
i
con>
prima
 ancora
di
di
progeIare
una
 qualsiasi
soluzione.
  • 47. Service
Oriented
Architecture • SOA
ha
come
obie@vo
di
ridurre
le
 dipendenze
fra
le
applicazioni: – Language
coupling
 XML – Protocol
coupling
 WS,
SOAP – Network
coupling
 ESB – Availability
coupling
 messages • Standard
e
basso
accoppiamento
 concorrono
a
definire
un’architeIura
basata
 su
componen@
sos@tuibili
  • 48. Low
coupling • I
servizi
possono
 dialogare
tra
loro
 con
il
più
basso
 Enterprise
Service
Bus livello
di
 conoscenza
 reciproca
 possibile
  • 49. Low
coupling • I
servizi
possono
 dialogare
tra
loro
 con
il
più
basso
 Enterprise
Service
Bus livello
di
 conoscenza
 reciproca
 possibile
  • 50. La
promessa
iniziale
  • 51. La
promessa
iniziale • SOA
era
uno
strumento
per
  • 52. La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia
  • 53. La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia – PermeIere
all’
IT
di
diventare
un
faKore
chiave
 per
il
business,
invece
che
un
peso.
  • 54. La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia – PermeIere
all’
IT
di
diventare
un
faKore
chiave
 per
il
business,
invece
che
un
peso. – “è
un
casino”
  • 55. La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia – PermeIere
all’
IT
di
diventare
un
faKore
chiave
 per
il
business,
invece
che
un
peso. – “è
un
casino” – “lo
meAo
in
agenda
per
il
2010”
  • 56. La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia – PermeIere
all’
IT
di
diventare
un
faKore
chiave
 per
il
business,
invece
che
un
peso. – “è
un
casino” – “lo
meAo
in
agenda
per
il
2010” – “Adesso
non
c’è
tempo”
  • 57. La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia – PermeIere
all’
IT
di
diventare
un
faKore
chiave
 per
il
business,
invece
che
un
peso. – “è
un
casino” – “lo
meAo
in
agenda
per
il
2010” – “Adesso
non
c’è
tempo” – “Possiamo
farlo”
  • 58. La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia – PermeIere
all’
IT
di
diventare
un
faKore
chiave
 per
il
business,
invece
che
un
peso. – “è
un
casino” – “lo
meAo
in
agenda
per
il
2010” – “Adesso
non
c’è
tempo” – “Possiamo
farlo” – “Perchè
non
fare
quest’altra
cosa,
invece?”
  • 59. La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia – PermeIere
all’
IT
di
diventare
un
faKore
chiave
 per
il
business,
invece
che
un
peso. – “è
un
casino” – “lo
meAo
in
agenda
per
il
2010” – “Adesso
non
c’è
tempo” – “Possiamo
farlo” – “Perchè
non
fare
quest’altra
cosa,
invece?” – “...Abbiamo
un
idea...”
  • 60. La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia – PermeIere
all’
IT
di
diventare
un
faKore
chiave
 per
il
business,
invece
che
un
peso. – “è
un
casino” – “lo
meAo
in
agenda
per
il
2010” – “Adesso
non
c’è
tempo” – “Possiamo
farlo” – “Perchè
non
fare
quest’altra
cosa,
invece?” – “...Abbiamo
un
idea...” – PermeIere
alle
imprese
di
ridurre
il
vandor
lock‐ in
e
di
recuperare
il
controllo
sul
budget
dell’IT.

  • 61. ...deFa
in
un
altro
modo Alberto Brandolini 01/0 Qui ci pouò stare l'esem Amazon • SOA
è
uno
strumento
per
permeIere
alle
 grandi
aziende
di
raggiungere
la
business
 agility – Cicli
di
rilascio
dei
prodo@
più
brevi – OIenere
il
feedback
direIamente
dal
mercato – Sperimentare
nuovi
modi
di
fare
business
  • 62. ...deFa
in
un
altro
modo Alberto Brandolini 01/0 Qui ci pouò stare l'esem Amazon • SOA
è
uno
strumento
per
permeIere
alle
 grandi
aziende
di
raggiungere
la
business
 agility – Cicli
di
rilascio
dei
prodo@
più
brevi – OIenere
il
feedback
direIamente
dal
mercato – Sperimentare
nuovi
modi
di
fare
business • SOA
non
è
uno
strumento
per
ricostruire
 un’architeFura
esistente
con
una
nuova
 tecnologia
  • 63. Il
@pico
scenario
SOA... Lo
scenario
ideale
Agile Lo
scenario
SOA • Essere
assun>
in
un’azienda
 • Generalmente
la
massima
 la
cui
massima
priorità
sia
il
 priorità
dell’azienda
NON
è
il
 socware. socware • lavorare
nello
stesso
posto • consulen>,
risorse
a
 • Avere
accesso
agli
uten>
 progeIo,
etc.
sono
la
regola. (qualsiasi
cosa
significhi) • Lo
sviluppo
spesso
avviene
in
 • Essere
liberi
di
crescere
 più
sedi,
frequente
il
ricorso
 come
team
ed
assumersi
 all’offshore. responsabilità. • Pochi
incen>vi
alla
crescita
 • Essere
liberi
di
scegliere
 ed
all’assunzione
di
 responsabilità logis>ca,
hardware,
etc. • Controllo
molto
limitato
su
 logis>ca,
hardware,
etc.
  • 64. La
tecnologia
di
SOA
  • 65. Libertà!? • Basso
accoppiamento
e
standard
di
 comunicazione
indipenden>
dal
linguaggio
 offrono
la
possibilità
di
implementare
 applicazioni
nelle
tecnologie
più
appropriate. Enterprise
Service
Bus
  • 66. Libertà!? • Basso
accoppiamento
e
standard
di
 comunicazione
indipenden>
dal
linguaggio
 offrono
la
possibilità
di
implementare
 applicazioni
nelle
tecnologie
più
appropriate. Enterprise
Service
Bus
  • 67. ...
Forse
siamo
ancora
 accoppia@...? • L’accoppiamento
tecnologico
è
solo
uno
dei
 vari
faIori
di
accoppiamento
sulla
scena: – Budget
per
le
licenze – Opera>ons
&
Support – Standard
aziendali,
Regole
e
prescrizioni
già
in
 essere – Strategie
per
la
ges>one
del
personale – ArchiteIura – Cultura
aziendale
  • 68. In
che
lingua
parliamo? • UML
non
è
sufficiente
per
le
esigenze
di
SOA • Emerge
un
nuovo
gergo,
nuovi
diagrammi,
 nuove
notazioni,
nuovi
layer
...
  • 69. In
che
lingua
parliamo? • UML
non
è
sufficiente
per
le
esigenze
di
SOA • Emerge
un
nuovo
gergo,
nuovi
diagrammi,
 nuove
notazioni,
nuovi
layer
...
  • 70. In
che
lingua
parliamo? • UML
non
è
sufficiente
per
le
esigenze
di
SOA • Emerge
un
nuovo
gergo,
nuovi
diagrammi,
 nuove
notazioni,
nuovi
layer
...
  • 71. Mettiamo
le
cose
 assieme
  • 72. Agile
and
SOA
  • 73. Agile
and
SOA “Enterprises
experience
more
success
with
SOA
 when
they
eschew
big
top‐down
delivery
 projects
and
instead
get
down
in
the
trenches
 with
an
evolu7onary
approach.
Agile
processes
 provide
a
basic
structure
for
this
kind
of
 incremental
delivery.”

 • Carey
Schwaber,
Forrester
Research ...
non
mol>
ar>coli
invece
ci
dicono
quanto
i
 processi
agili
possano
trarre
beneficio
da
SOA
  • 74. Agile
come
Gioco
Coopera@vo • Lo
sviluppo
socware
può
essere
definito
 come
un
gioco
coopera@vo,
finito,
direFo
ad
 un
obieGvo(Cockburn) Compe@@ve Coopera@ve Finite, Carpet
 wrestling Jazz Non‐goal‐directed Dolls Finite, SoLware
 Tennis goal‐directed Development Career
management Infinite Organiza>on
Survival
  • 75. So[ware
development
as
a
Game • Finito:
un
progeIo
comincia
e
finisce
(in
un
 modo
o
nell’altro)
 • DireFo
ad
un
obieGvo:
es.
consegnare
in
 tempo • Collabora@vo:
s>amo
giocando
insieme
agli
 altri
membri
del
team • …
ma
non
s>amo
facendo
solo
questo: – S>amo
investendo
sulla
carriera – Giochiamo
a
fare
i
genitori – Etc.
etc.
  • 76. Un
team
di
successo
  • 77. Alcuni
elemen@
chiave • Il
Team – Migliori
talen>
disponibili – Obie@vi
della
squadra
prima
di
quelli
personali – Elevata
mo>vazione • L’obieGvo – Obie@vo
chiaro – esperienza
limitata
nel
tempo – Risultato
misurabile
  • 78. Un
team
un
po’
meno
di
successo...
  • 79. Un
team
un
po’
meno
di
successo...
  • 80. Elemen@
chiave • Il
team – I
migliori
talen>? – Obie@vi
individuali
(o
di
par>to)
prima
di
quelli
 del
team,
...
o
del
cliente...
:‐( • L’obieGvo – Non
così
ben
definito
(a
meno
di
credere
ai
 proclami
eleIorali) – Intervallo
di
tempo
casuale – Risultato
non
misurabile
(ai
posteri...
)
  • 81. Gioco
a
risorse
limitate • Lo
scenario
è
limitato
su
svaria>
parametri
 chiave: – Budget – Tempo – Esperienza – Talento – Quan@tà
di
informazioni
ges@bili
  • 82. Qual
è
il
gioco
di
SOA? • SOA
è
generalmente
un
gioco
giocato
ad
un
 livello
differente
dallo
sviluppo: – Gli
obie@vi
sono
lega>
ad
una
strategia
di
lungo
 periodo – I
risulta>
di
medio
termine
possono
risultare
non
 osservabili
o
misurabili
per
il
team. • Es.
Budget • Eliminazione
di
un
sistema
esterno
  • 83. The
SOA
Game Una
cri>ca
comune
alle
metodologie
Agili,
è
 che
si
focalizzano
su
obie@vi
a
breve
termine. SOA
vuole
vedere
il
quadro
 complessivo,
concentrandosi
su
 obie@vi
a
volte
non
 completamente
trasparen>.
  • 84. La
cultura
dominante • la
cultura
aziendale
può
essere
molto
lontana
 dai
principi
agili • SOA
può
avere
l’appoggio
del
management,
 ma
non
è
deIo
che
anche
le
metodologie
 agili
ce
l’abbiano. • Carriere,
ruoli
e
specializzazioni
possono
 risultare
soIo
pressione.
  • 85. Dimensione
del
progeFo • SOA
spesso
implica
la
presenza
di
mol>
team
 di
sviluppo
allo
stesso
tempo
  • 86. Dimensione
del
progeFo • SOA
spesso
implica
la
presenza
di
mol>
team
 di
sviluppo
allo
stesso
tempo
  • 87. Più
realis@camente...
  • 88. 51
  • 89. Il
ritorno
del
Top
Down • Alcun
strumen>
reintroducono
la
filosofia
 top‐down – Ruoli
prefissa>
 – Tool
driven
design – Sviluppo
basato
sulle
specifiche • Un
ulteriore
sgradevole
effeIo
... – Il
feedback
dal
basso
è
scoraggiato – Idee
potenzialmente
buone
vanno
perdute
  • 90. Il
ritorno
del
Top
Down • Alcun
strumen>
reintroducono
la
filosofia
 top‐down – Ruoli
prefissa>
 – Tool
driven
design – Sviluppo
basato
sulle
specifiche • Un
ulteriore
sgradevole
effeIo
... – Il
feedback
dal
basso
è
scoraggiato – Idee
potenzialmente
buone
vanno
perdute
  • 91. Il
ritorno
del
Top
Down • Alcun
strumen>
reintroducono
la
filosofia
 top‐down – Ruoli
prefissa>
 – Tool
driven
design – Sviluppo
basato
sulle
specifiche • Un
ulteriore
sgradevole
effeIo
... – Il
feedback
dal
basso
è
scoraggiato – Idee
potenzialmente
buone
vanno
perdute
  • 92. Il
ritorno
del
Top
Down • Alcun
strumen>
reintroducono
la
filosofia
 top‐down – Ruoli
prefissa>
 – Tool
driven
design – Sviluppo
basato
sulle
specifiche • Un
ulteriore
sgradevole
effeIo
... – Il
feedback
dal
basso
è
scoraggiato – Idee
potenzialmente
buone
vanno
perdute
  • 93. Cominciare
Agile
e
SOA? • Benchè
siano
ortogonali,
due
rivoluzioni
allo
 stesso
tempo
sono
probabilmente
troppo
per
 un
team • Ma
...agile
si
comporta
bene
in
presenza
di
 esplorazioni
ed
incertezza: – processo
ada@vo – spikes – approccio
test
driven
  • 94. Prepariamo
la
scena • Non
generiamo
aspeIa>ve
difficili
da
 soddisfare • Manteniamo
il
management
al
corrente
dei
 possibili
problemi – Le
transizioni
ai
metodi
agili
meIono
soIo
 pressione
le
organizzazioni,
esponendo
problemi
 che
sono
sempre
sta>
nascos>
soIo
il
tappeto. – Cer>
problemi
sono
sempre
sta>
lì
(magari
soIo
il
 tappeto),
meIerli
in
evidenza
può
apparire
 sgradito.
  • 95. Scegliete
un
obie@vo
facile • Scegliamo
obie@vi
raggiungibili
in
un
 tempo
ragionevole • Raggiungiamoli • Costruiamo
sui
risulta> • sicurezza • affiatamento • reputazione

  • 96. Viaggiamo
leggeri
  • 97. Viaggiamo
leggeri • la
disponibiltà
di
strumen>
per
 ges>re
la
complessità
di
SOA
 non
significa
che
dobbiamo
 incoraggiare
la
complessità
  • 98. Viaggiamo
leggeri • la
disponibiltà
di
strumen>
per
 ges>re
la
complessità
di
SOA
 non
significa
che
dobbiamo
 incoraggiare
la
complessità • Il
lato
oscuro
di
SOA
non
è
 meglio
di
ciò
che
l’ha
 preceduta...
  • 99. Viaggiamo
leggeri • la
disponibiltà
di
strumen>
per
 ges>re
la
complessità
di
SOA
 non
significa
che
dobbiamo
 incoraggiare
la
complessità • Il
lato
oscuro
di
SOA
non
è
 meglio
di
ciò
che
l’ha
 preceduta...
  • 100. Appoggiamoci
su
standard • Come
corollario
a

“decide
as
late
as
 possible”: – Sviluppiamo
su
standard
consolida>
se
possibile • Migliore
documentazione • Rimpiazzabili • ...
s>amo
facend
strategie
di
lungo
termine. – Evitare
le
tentazioni
di
features
vendor‐specific – Manteniamo
soIo
controllo
la
deviazione
dagli
 standard
  • 101. La
decisione
più
 irreversibile...
  • 102. La
decisione
più
 irreversibile... Non
separiamoci
dai
 nostri
soldi! Non
compriamo
 nulla
la
cui
necessità
 non
sia
provata!!!
  • 103. Evi@amo
l’approccio
Big‐Bang • Un’approccio
su
larga
scala
introduce
più
 problemi
lega>
al
coordinamento
ed
alla
 condivisione
di
informazioni
in
evoluzione. • Piccoli
guerrilla‐teams
possono
fare
un
 lavoro
migliore
con
un
uso
più
efficiente
delle
 risorse 59
  • 104. Evi@amo
l’approccio
Big‐Bang • Un’approccio
su
larga
scala
introduce
più
 problemi
lega>
al
coordinamento
ed
alla
 condivisione
di
informazioni
in
evoluzione. • Piccoli
guerrilla‐teams
possono
fare
un
 lavoro
migliore
con
un
uso
più
efficiente
delle
 risorse • Ogni
frase
che
comincia
con
“ogni”
è
 potenzialmente
pericolosa! 59
  • 105. Never
be
blocked 60
  • 106. Never
be
blocked • Le
interdipendeze
tra
sistemi
possono
 rallentarci
indefinitamente 60
  • 107. Never
be
blocked • Le
interdipendeze
tra
sistemi
possono
 rallentarci
indefinitamente • Non
aspeFare
qualcosa
al
di
fuori
del
nostro
 scope
di
progeIo. 60
  • 108. Never
be
blocked • Le
interdipendeze
tra
sistemi
possono
 rallentarci
indefinitamente • Non
aspeFare
qualcosa
al
di
fuori
del
nostro
 scope
di
progeIo. – Mockiamola 60
  • 109. Never
be
blocked • Le
interdipendeze
tra
sistemi
possono
 rallentarci
indefinitamente • Non
aspeFare
qualcosa
al
di
fuori
del
nostro
 scope
di
progeIo. – Mockiamola – implemen>amola 60
  • 110. Never
be
blocked • Le
interdipendeze
tra
sistemi
possono
 rallentarci
indefinitamente • Non
aspeFare
qualcosa
al
di
fuori
del
nostro
 scope
di
progeIo. – Mockiamola – implemen>amola – facciamone
a
meno 60
  • 111. Never
be
blocked • Le
interdipendeze
tra
sistemi
possono
 rallentarci
indefinitamente • Non
aspeFare
qualcosa
al
di
fuori
del
nostro
 scope
di
progeIo. – Mockiamola – implemen>amola – facciamone
a
meno • ...qualsiasi
cosa
facciamo,
facciamolo
 pubblicamente. 60
  • 112. Ripensiamo
agli
Sprechi • Alcune
forme
di
spreco
“fare
due
volte
la
 stessa
cosa”
possono
essere
preferibili
a
 “documenta
cos’hai
faKo” • Lo
sviluppo
su
larga
scala
cambia
le
priorità • I
confini
aziendali
e
logis>ci
cambiano – Cos>
di
comunicazione – Passaggi
di
consegne
  • 113. Il
costo
di
comunicare • Le
informazioni
non
si
propagano
con
la
 documentazione,
ma
sapendo
cosa
stanno
 facendo
gli
altri. – Mantenere
più
team
allinea> • Scrum
of
Scrums • Informa>on
radiators • Prossimità • End
of
itera>on
demo • Quando
è
comunque
meglio
scrivere,
i
Wiki
 permeIono
di
scrivere
documentazione
on‐ demand.
  • 114. Condividiamo
il
piano • Impedire
agli
sviluppatori
di
vedere
il
quadro
 complessivo
impedisce
di
dare
dei
contribu@
 significa@vi. – Sono
possibili
solo
oGmizzazioni
locali – Sono
possibili
errori
madornali
  • 115. Pianificazione
di
alto
livello • SOA
è
un
processo
di
trasformazione
a
lungo
 A termine f • Ogni
passo
cambia
lo
scenario – Maggiore
conoscenza
del
contesto – Pesi
e
priorità
differen> – Differen>
opportunità • E’
necessario
aggiornare
e
ri‐pianificare
di
 frequente,
per
centrare
gli
obie@vi
(non
 necessariamente
quelli
originali)
 – Misuriamo,
non
assumiamo – Ges@amo
i
rischi,
non
facciamo
previsioni – Non
iniziamo
nulla
di
cui
non
ci
sia
bisogno
ora
  • 116. SOA
Tes@ng • SOA
è
basata
sui
principi
di
Design
by
 Contract
...il
paradiso
del
tester! – Definizione
dell’interfaccia
basata
su
standard.
 – AIese
ben
definite
sul
comportamento
esposto
 dai
servizi
  • 117. Tes@
su
SOA:
challenges • Test
suite
indipendente
dal
linguaggio
 • Mocks
e
Stubs
che
implementano
i
servizi
 • Selezione
delle
aree
chiave
per
il
test  • Definizione
e
ges>one
dell’ambiente
di
test
 
  • 118. Definizione
degli
ambien@ • In
determina>
contes>,
gli
ambien>
di
test
 possono
essere
troppo
complessi
o
costosi
 per
essere
replica> – Teniamo
sempre
in
funzione
i
tool
di
con>nuous
 integra>on – Estendiamo
gli
ambien>
di
integrazione
fin
dove
 possibile – Troviamo
un
punto
di
equilibrio
tra
correIezza
e
 ges>bilità – Manteniamo
sempre
i
test
aggiorna>
  • 119. In
due
parole...
  • 120. In
due
parole... • Impediamo
alle
vecchie
abitudini
di
farla
da
 padrone • Prepariamoci
a
compromessi
(temporanei) – Teniamo
traccia
del
prezzo
da
pagare – Siamo
pron>
a
cambiare,
cogliendo
nuove
 opportunità • Coinvolgiamo
i
gius>
sponsor • Comunicare!!! • Prepariamoci
ad
un
oIovolante!
  • 121. ... finito?
  • 122. ... finito? Grazie a tutti!