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

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!

122. ... finito?

123. ... finito?
Grazie a tutti!