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

Service Oriented Agility @ Italian Agile Day - Bologna 2008

on

  • 1,881 views

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

Statistics

Views

Total Views
1,881
Views on SlideShare
1,868
Embed Views
13

Actions

Likes
0
Downloads
24
Comments
0

4 Embeds 13

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

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Service Oriented Agility @ Italian Agile Day - Bologna 2008 Service Oriented Agility @ Italian Agile Day - Bologna 2008 Presentation Transcript

  • Buzzword
 Deathmatch: Si
può
fare
agile
in
una
 SOA?
  • 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
  • Lo
scenario
Agile
  • Perchè
Agile? Tradurre
  • Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta>
  • Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta> – Waterfall
è
“tradizionalmente”
associato
a

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

  • Perchè
Agile? Tradurre • Lo
sviluppo
Waterfall
si
è
dimostrato
 inefficiente
e
insoddisfacente
come
risulta> – Waterfall
è
“tradizionalmente”
associato
a
 • cos>
eleva>
 • tempi
di
sviluppo
lunghi
  • 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
  • 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
  • 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)
  • Unified
Process
  • 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.
  • Unified
Process
 • Unfortunately,
it
also
set
the
ground
for – A
family
of
UML
modelling
tools – A
lot
of
documenta@on
templates 6
  • Il
lato
oscuro
dello
Unified
Process
  • Il
lato
oscuro
dello
Unified
Process • Gli
strumen>
sono
 diventa>
sempre
più
 importan>,
deformando
 il
processo
stesso.
  • 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
  • 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...
  • Sviluppatori Gli
sviluppatori
erano
considera>
 “risorse
interscambiabili”
il
cui
unico
 compito
era
di
implementare
le
 specifiche.
 Però
itera@vamente.

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

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

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

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

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

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

  • Occasionalmente,
gli
archite@
passano
in
 rassegna
la
truppa...
  • Ruoli
e
Responsabilità
  • 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 – ...
  • ...
I
ribelli
non
stanno
a
guardare
  • ...
I
ribelli
non
stanno
a
guardare
  • 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)
  • 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 • ...
  • 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
  • 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
  • Lo
scenario
@pico
di
un
team
  • 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.
  • Mol@
stakeholders? Il
Product
 Owner
è
 l’unico
 responsabile
 per
il
gruppo
 di
sviluppo.
  • 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.
  • 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à
(?) – ...
  • 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)
  • 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
  • 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
  • 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.
  • Lo
scenario
SOA
  • 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?
  • 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.
  • 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
  • Low
coupling • I
servizi
possono
 dialogare
tra
loro
 con
il
più
basso
 Enterprise
Service
Bus livello
di
 conoscenza
 reciproca
 possibile
  • Low
coupling • I
servizi
possono
 dialogare
tra
loro
 con
il
più
basso
 Enterprise
Service
Bus livello
di
 conoscenza
 reciproca
 possibile
  • La
promessa
iniziale
  • La
promessa
iniziale • SOA
era
uno
strumento
per
  • La
promessa
iniziale • SOA
era
uno
strumento
per – PermeIere
le
necessarie
operazioni
di
pulizia
  • 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.
  • 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”
  • 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”
  • 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”
  • 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”
  • 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?”
  • 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...”
  • 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.

  • ...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
  • ...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
  • 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.
  • La
tecnologia
di
SOA
  • Libertà!? • Basso
accoppiamento
e
standard
di
 comunicazione
indipenden>
dal
linguaggio
 offrono
la
possibilità
di
implementare
 applicazioni
nelle
tecnologie
più
appropriate. Enterprise
Service
Bus
  • Libertà!? • Basso
accoppiamento
e
standard
di
 comunicazione
indipenden>
dal
linguaggio
 offrono
la
possibilità
di
implementare
 applicazioni
nelle
tecnologie
più
appropriate. Enterprise
Service
Bus
  • ...
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
  • In
che
lingua
parliamo? • UML
non
è
sufficiente
per
le
esigenze
di
SOA • Emerge
un
nuovo
gergo,
nuovi
diagrammi,
 nuove
notazioni,
nuovi
layer
...
  • In
che
lingua
parliamo? • UML
non
è
sufficiente
per
le
esigenze
di
SOA • Emerge
un
nuovo
gergo,
nuovi
diagrammi,
 nuove
notazioni,
nuovi
layer
...
  • In
che
lingua
parliamo? • UML
non
è
sufficiente
per
le
esigenze
di
SOA • Emerge
un
nuovo
gergo,
nuovi
diagrammi,
 nuove
notazioni,
nuovi
layer
...
  • Mettiamo
le
cose
 assieme
  • Agile
and
SOA
  • 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
  • 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
  • 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.
  • Un
team
di
successo
  • 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
  • Un
team
un
po’
meno
di
successo...
  • Un
team
un
po’
meno
di
successo...
  • 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...
)
  • Gioco
a
risorse
limitate • Lo
scenario
è
limitato
su
svaria>
parametri
 chiave: – Budget – Tempo – Esperienza – Talento – Quan@tà
di
informazioni
ges@bili
  • 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
  • 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>.
  • 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.
  • Dimensione
del
progeFo • SOA
spesso
implica
la
presenza
di
mol>
team
 di
sviluppo
allo
stesso
tempo
  • Dimensione
del
progeFo • SOA
spesso
implica
la
presenza
di
mol>
team
 di
sviluppo
allo
stesso
tempo
  • Più
realis@camente...
  • 51
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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.
  • Scegliete
un
obie@vo
facile • Scegliamo
obie@vi
raggiungibili
in
un
 tempo
ragionevole • Raggiungiamoli • Costruiamo
sui
risulta> • sicurezza • affiatamento • reputazione

  • Viaggiamo
leggeri
  • Viaggiamo
leggeri • la
disponibiltà
di
strumen>
per
 ges>re
la
complessità
di
SOA
 non
significa
che
dobbiamo
 incoraggiare
la
complessità
  • 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...
  • 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...
  • 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
  • La
decisione
più
 irreversibile...
  • La
decisione
più
 irreversibile... Non
separiamoci
dai
 nostri
soldi! Non
compriamo
 nulla
la
cui
necessità
 non
sia
provata!!!
  • 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
  • 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
  • Never
be
blocked 60
  • Never
be
blocked • Le
interdipendeze
tra
sistemi
possono
 rallentarci
indefinitamente 60
  • Never
be
blocked • Le
interdipendeze
tra
sistemi
possono
 rallentarci
indefinitamente • Non
aspeFare
qualcosa
al
di
fuori
del
nostro
 scope
di
progeIo. 60
  • Never
be
blocked • Le
interdipendeze
tra
sistemi
possono
 rallentarci
indefinitamente • Non
aspeFare
qualcosa
al
di
fuori
del
nostro
 scope
di
progeIo. – Mockiamola 60
  • 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
  • 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
  • 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
  • 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
  • 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.
  • 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
  • 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
  • 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
  • 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
 
  • 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>
  • In
due
parole...
  • 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!
  • ... finito?
  • ... finito? Grazie a tutti!