Cosa abbiamo scoperto in questi 20 anni? Che cercare di cambiare il mondo focalizzandoci su un singolo aspetto, il processo, il TDD, il clean code, non porta da nessuna parte. I veri cambiamenti avvengono quando scopriamo le reali interazioni tra le parti, quando lasciamo la specializzazione e cominciamo a vedere il vero quadro d'insieme. In questo talk vedremo come scelte architetturali apparentemente innocue, finiscano per impattare il processo, ed in generale di come processi, pratiche, architetture, persone e scelte di business non possano essere considerate come elementi disaccoppiati tra loro.

1. L’illusione
dell’ortogonalita’
@ziobrando

2. About me
• Coding since 1982
• … but that’s not what I get paid for
• #DDDesign #Agile #Lean #Complexity
• I invented
• I smell
• I run

3. Test-Driven Development
Cose che funzionano, ma a volte no

4. Come funziona?
TDD
Codice affidabile
Aperti ad
opportunita’
Stime piu’ precise
Disponibile alle
evoluzioni
Design Migliore
#Pratiche
#Architettura
#Business
#Processo
#Persone
Se fatto bene…
Piano piano…
Che ci vuole?

5. TDD non e’ una pratica
strettamente
ingegneristica
#Pratiche
#Architettura
#Business
#Processo
#Persone
Impatti a livello di ansia, pianificazione, e reattivita’ business
Ansia Pianificazione Reattivita’

6. Sam

8. Pero’ non sempre
funziona…
Ci sono situazioni in cui queste promesse non vengono mantenute

9. “I miei colleghi non fanno TDD”
TDD
Commit distruttivi
#Pratiche
#Architettura
#Business
#Processo
#Persone
No TDD
WTF!
Copertura a macchia
di leopardo

11. Rendiamo Evidente il
contesto
Contesto
Quello che troppo
spesso dimentichiamo, o
e’ sottinteso, ma che
fa la differenza.
🙂

12. Dove funziona?
TDD
Codice affidabile
Aperti ad
opportunita’
Stime piu’ precise
Disponibile alle
evoluzioni
Design Migliore
#Pratiche
#Architettura
#Business
#Processo
#Persone
Se fatto bene…
Piano piano…
Confini ben precisi Mancava un ingrediente!
Pet Project - POC
Un solo sviluppatore,
su un progetto ben
definito
🙂
Team Agreement
Un team con un
approccio simile su una
porzione ben definita
del sistema.
🙂

13. Non puo’ funzionare se…
Applico TDD
Commit distruttivi
#Pratiche
#Architettura
#Business
#Processo
#Persone
Non applico TDD
WTF!
Copertura a macchia
di leopardo
Big Ball of Mud
Piu’ sviluppatori, senza
confini precisi.
😳
Big Ball of Mud
Continuo turnover su
una codebase senza
padroni
😳
Confini non definiti

14. Qualche nota
Il contesto mi serve a capire dove una cosa puo’
funzionare
Guardiamo a quello che in Blog Posts, Articoli, Libri
e’ sottinteso
Per capire il sottinteso devo provare in contesti
diversi (o confrontarmi con colleghi)

17. I confini contano
Confini
Ricordatevi di Romolo!

18. Bounded Context
• Unita’ di consistenza del
linguaggio
• Un modello costruito
attorno ad uno scopo ben
preciso
Bounded Context
(Questo l’ho imparato da Domain-Driven Design)

19. Un singolo scopo
Piu’ Facile ottimizzare per un solo obiettivo

21. Qui no!
In un BC ben definito il codice DEVE essere semplice

22. Ma non si tratta solo di
modelli e linguaggi…

23. Motivation
• Autonomy
• Mastery
• Purpose
https://vimeo.com/15488784

24. Bounded Context
• Unita’ di consistenza del
linguaggio
• Un modello costruito attorno
ad uno scopo ben preciso
• UN confine che permette
l’implementazione di pratiche
ed accordi “speciali” tra
colleghi
• Un “luogo” dove possiamo fare
la cosa giusta senza
compromessi
Bounded Context

25. primo progetto enterprise (2001)
In una banca
Stack Tecnologico ‘aggressivo’
Persistenza privata
Domain Model sofisticato
Modello dei dati non convenzionale
Continuous integration
Test Engine

26. Circolo Virtuoso
Se non funziona, puo’ essere solo colpa nostra
QUINDI
deve funzionare
QUINDI
Lo testiamo

27. Confini ben definiti
Limitano il rischio
Liberta’ di sperimentare
Focus sull’obiettivo
Empowerment
Condizioni per aumentare la qualita’ del risultato

28. L’ ecosistema conta!
Ecosistema

29. Stime!
Guardiamoci meglio

30. Le ho viste funzionare…
Sprint Planning
Stime precise
Team consolidato
#Pratiche
#Architettura
#Business
#Processo
#Persone
A casa presto
Pianificazione
rispettata
Buona codebase
Team Nuovo
Troppe incognite
😳
Legacy Codebase
Come stimare la ruota
della fortuna!
😳
Escludiamo qualche
contesto…

31. Una settimana dopo…
Sprint Planning
Stime Sballate del
100%
Team consolidato
#Pratiche
#Architettura
#Business
#Processo
#Persone
Oh Shit!
Buona codebase
Lo stesso team

32. Dove sta la differenza?

33. Dipendenze!
Sprint Planning
Stime precise
Team consolidato
#Pratiche
#Architettura
#Business
#Processo
#Persone
A casa presto
Pianificazione
rispettata
Buona codebase
Settimana 1
Attivita’ senza
dipendenze esterne
🙂
Settimana 2
Necessita’ di aiuto
dall’esterno
😳
No dipendenze

34. I confini contano
Ma sono difficili da difendere

35. Field notes
E’ difficile - ma non impossibile - stimare il nostro
lavoro
Stimare zone ad alta incertezza (Legacy pericoloso o
attivita’ altrui) ha margini di errore decisamente piu’
alti.
…Ne vale ancora la pena…?

36. Le dipendenze contano
dipendenze
Processo
Anche quando vorremmo che fosse solo un problema di
Abbiamo
problemi a
scalare agile…
“Forse”
avete un problema
di architettura

37. Coordinamento tra team?

38. Idealmente…
Team A
Team B
Team C
Team D
Progetto 1
Progetto 2 Progetto 4
Progetto 3
Progetto 5 Progetto 6
Progetto 7 Progetto 8

39. In pratica, bastano un po’ di
dipendenze…
Team A
Team B
Team C
Team D
Progetto 1
Progetto 2 Progetto 4
Progetto 3
Progetto 5 Progetto 6
Progetto 7 Progetto 8
1
2
5 6
4
3
Non sono escrescenze, sono straordinari

40. Questo non e’ accettabile
Team A
Team B
Team C
Team D
Progetto 1
Progetto 2
Progetto 4
Progetto 3
Progetto 5 Progetto 6
Progetto 7 1
2
5 6 4
3
Probabilmente il progetto più importante
Non li pago per
stare fermi

41. Ma questo e’ ancora meno
accettabile
Team A
Team B
Team C
Team D
Progetto 2
Progetto 5
Progetto 7 2
5 Probabilmente il progetto più importante

42. Quindi: teniamo fisse le date e
andiamo di overtime!
Team A
Team B
Team C
Team D
Progetto 1
Progetto 2 Progetto 4
Progetto 3
Progetto 5 Progetto 6
Progetto 7 Progetto 8
1
2
5 6
4
3

43. Dipendenze
Il miglior antidoto alla scalabilita’

44. Dipendenze
Chi le ha lasciate in giro?

45. Il mammut nel guardaroba

46. Abbiamo un problema

47. Purtroppo
Data-driven Design
Dipendenze
Frenone
Effort di
Coordinamento
Stress
Centralizzazione
Focus sui nomi
Ma stiamo
passando a
Microservizi!
Lo stile di modellazione incentrato sul dato porta a costruire sistemi che
inevitabilmente generano dipendenze dannose

48. Guardando il dato (O i nomi)
Articolo
Prezzo
Disponibilita’
Cliente
Carrello Articolo
Prezzo
Pagamento
Ordine
Articolo
Prezzo
Cliente Cliente
Ordine
Ordine
Pagamento
Consegna
Cliente
Reclamo
Cliente
Ordine
Fattura
Articolo
Alcuni Termini sono usati quasi dappertutto: -> centralizziamo
Articolo
Business flow
Catalogo Acquisto Gestione ordine Delivery Claim

49. Spinta verso la centralizzazione
Mi
serve il
cliente!
Mi
serve il
cliente!
Mi
serve il
cliente!

50. Guardando il comportamento
Articolo
Prezzo
Disponibilita’
Cliente
Carrello
Articolo
Prezzo
Pagamento
Ordine
Articolo
Prezzo
Cliente
Cliente
Ordine
Ordine
Pagamento
Consegna Cliente
Reclamo
Cliente
Ordine
Fattura
Articolo
Il dato e’ lo stesso, ma il comportamento e’ diverso -> Possibili modelli diversi, copie o
altre opzioni architettura.
Articolo
Business flow
Registra
Completa
Autorizza
Aggiungi
Rimuovi
Checkout
Aggiungi a catalogo
Ritira
Modifica descrizione
Aggiorna
Cliente
Disponibilita’ Totale
Carrello
attiva
gestisci
chiudi
attiva
gestisci
chiudi
Cambia stato
Sola lettura
Catalogo Acquisto
Gestione ordine
Delivery Claim
Payment
Magazzino
Billing

51. Un’altra storia!
Event-driven Design
Dipendenze “leggere”
Piu’ spazio per
evoluzione
Coordinamento
ridotto
Meno riunioni
Partizionamento
Focus su eventi chiave
Piano piano…
Meno Stakeholders

52. I Microservizi (da soli) non
basteranno

53. Portare un modello data-
centrico a microservizi
Significa annegare nelle
dipendenze

54. Field Notes
Il focus sul dato ci porta a centralizzare (molti
stakeholder per componente)
Focus sul flusso (comportamenti ed eventi) ci porta a
vedere altri confini (e pochi stakeholder per
componente) Enterprise software
Collaborazione fra
team e dipartimenti
diversi
🙂

55. High Coesion
Low Coupling

56. Meno riunioni con troppa
gente

57. Pairing!
O meglio: facciamo esperimenti riducendo il WiP Limit

58. Quando funziona…
WiP a 1
Rilascio piu’ rapido
Collaborazione
#Pratiche
#Architettura
#Business
#Processo
#Persone
Aperitivo!
Design sulla
frontiera
Cliente contento

60. Riproviamo!
Ha funzionato una volta…

61. Quando NON funziona…
WiP a 1
Piu’ lenti…?
Uno sulla tastiera
#Pratiche
#Architettura
#Business
#Processo
#Persone
Cosa sta
succedendo?

64. Devo dargli ragione?
Guardiamoci meglio!

65. Quando funziona…
WiP a 1
Rilascio piu’ rapido
Collaborazione
#Pratiche
#Architettura
#Business
#Processo
#Persone
Aperitivo!
Design sulla
frontiera
Cliente contento
OOP ed architettura
Domain-Centric
Posso splittare classi
ed interfacce
🙂
Logica nel dominio
(OOP)

66. Quando NON funziona…
WiP a 1
Piu’ lenti…?
Uno sulla tastiera
#Pratiche
#Architettura
#Business
#Processo
#Persone
Tre umarells a
guardare
Logica nelle stored
procedure
Strati web come
passacarte
😳
Logica nelle Stored
Non si e’ accorto di
nulla!
E il business…?
Data-centric
Architecture

67. Certe architetture
invalidano le pratiche
Architetture
Pratiche

68. … ma se leggi
bene bene tra le
righe…

69. Ho appena cominciato
E’ molto peggio di cosi’

70. Logica Nelle stored
E’ tempo di guardarci meglio

71. Riapriamo il processo?
Forse, sono emerse nuove prove…
https://vimeo.com/253336751

73. Usiamo le
stored procedures
per migliorare le
performances Ci vogliono 18
minuti per
completare una
query!
Pensa quanto
ci vorrebbe se la
logica non fosse
vicino al dato!

74. Tempo e ripetizioni
Cosa c’e’ dietro alla freccia?

75. Un giorno qualsiasi
#Pratiche
#Architettura
#Business
#Processo
#Persone
Logica nelle stored
procedure
???
Nuovo requisito
business
Chi se ne occupa?
Chi se ne occupa?

76. Al giorno zero…
Il cuore del nostro
sistema, l’infrastruttura
che non puo’ cedere
Requisito Business
Un ipotetico team di
persone ugualmente
competenti
Competenza
A chi affidereste
l’attivita’?
Stored Procedures
Posso fare io!
Posso
fare anche io, e’
uguale…
#Pratiche
#Architettura
#Business
#Processo
#Persone
Solo
programming

77. Il risultato?
Competenza
Un po’ piu’ competente, perche’ ci ha messo le mani…
Un po’ meno competenti, perche’ non conoscono le ultime modifiche…
Stored Procedures

78. Il giorno successivo:
Requisito Business
Competenza
Stored Procedures
A chi affidereste
l’attivita’?
Abbiamo una asimmetria!

79. Il risultato:
Nuovo requisito
Competenza
Stored Procedures
L’asimmetria tende
naturalmente ad
aumentare…
E’ meglio se
lo fai tu…
Non sono
allineato con le
ultime

80. Prima o poi…
Requisiti critici
Stored Procedures Collo di bottiglia
Burnout
Competenze
asimmetriche
Ansia Turnover
Requisiti critici
Requisiti critici
Business in ritardo
#Pratiche
#Architettura
#Business
#Processo
#Persone
Solo
programming
Il destino
dell’universo
Posso
aiutarti?
No, mi
rallenti
Ciao ragazzi,
e’ stato bello…

82. Ineluttabilita’
E’ tutto tranne che sfortuna

85. Illusione del libero arbitrio
• Le stored procedure non facilitano la collaborazione
• Lavoreremo principalmente da soli
• Asimmetria sulle competenze
• Specializzazione
• colli di bottiglia
• Tensione e stress
• Maggior probabilita’ di turnover
• Scadenze business difficilmente raggiungibili
Quindi
Quindi
Quindi
Quindi
Quindi
Quindi
Quindi
Posso accettare un ‘molto probabilmente’ … ma temo che il risultato non cambi

89. C’e’ un filo rosso che
collega un’architettura data-
centric
al planning non rispettato,
All’apparizione di un ambiente
malsano ed al rallentamento
dell’evoluzione business

90. Non e’ sfortuna
E’ sulla linea di confine tra correlazione e causalita’ diretta

91. Possiamo fare
pairing per
condividere la
conoscenza!
Possiamo
fare le stored
procedure in TDD
per essere piu’
sicuri

92. Lo Yeti!
Non posso escludere che
esista, ma nessuno l’ha
mai visto…

94. Forse
l’architettura
esagonale ci e’
sfuggita un po’ di
mano…

95. Non abbiamo alcuna notizia di
aziende che cerchino aiuto per
uscire dall’architettura esagonale
Forse, Alcune architetture sono piu’ reversibili di altre

96. L’illusione
dell’ortogonalita’
Potrei seppellirvi di esempi, ma devo arrivare a qualche conclusione

97. Che problema ho con il
database e le stored
procedures?

98. Non tutte le dipendenze sono uguali
• Non servono cliniche per
curarmi

99. Il mio problema e’ che ci
sono aziende che hanno
questo problema da 20 anni
E forse e’ troppo tardi per salvare tutti

100. Pero’ possiamo evitare che
si ripeta
Magari osservando quei piccoli “segnali deboli” che sono sotto i
nostri occhi.

101. Sociotecnico
Interrelazione tra aspetti sociali e tecnici di un’organizzazione
- L’interazione tra fattori sociali e tecnici crea le condizioni
per la performance di un’organizzazione, in maniera lineare e
non-lineare.
- L’ottimizzazione di uno di questi aspetti indipendentemente
dall’altro tende a far aumentare l’instabilita’ del sistema
con relazioni non previste, ed a farne peggiorare il
rendimento
Liberamente tradotto da…
https://en.wikipedia.org/wiki/Sociotechnical_system
#Pratiche
#Architettura
#Business
#Processo
#Persone

102. La dimensione del problema
Bolle nate come soluzione tecnologica (come
partizionare un grafo per aumentare la velocita’)
L’algoritmo ha innescato comportamenti nuovi a
livello individuale e collettivo
Il nuovo paradigma ha reso possibili - e convenienti -
strategie mirate per influenzare elezioni, etc.

103. Restando a noi…

104. 1. Non possiamo risolvere
problemi da specialisti
#Pratiche
#Architettura
#Business
#Processo
#Persone

105. Non possiamo risolvere i
problemi da soli
#Pratiche
#Architettura
#Business
#Processo
#Persone

106. Se accettiamo il principio…

107. Q
u
e
s
t
a
d
i
v
i
s
i
o
n
e
n
o
n
e
’
p
i
u
’
c
o
s
i
’
n
e
t
t
a

108. “Non preoccupo dei tools”
E’ un’affermazione che potrebbe fare Sam

109. 2. I dettagli fanno la differenza
• Architetture, processi e tools Impattano e vincolano
individui ed interazioni
• Individui ed interazioni sono piu’ importanti, ma non
riusciremo a proteggerli se abbassiamo la guardia su
architetture processi e strumenti.
• Osserviamo ed analizziamo le interazioni, poi adattiamo
gli strumenti per permettere interazioni positive

110. Non e’ uguale

111. Board fisica
• Vincoli fisici,
• Policy esplicite
• Discussione in un luogo ben preciso
• Peso sul richiedente
Ho una nuova
feature per la settimana
prossima, dove la posso
mettere che non c’e’
posto?

112. Board digitale
• Sensazione che ci sia
posto…
• Un lieve sentore di
rosso
• Policy quasi mai visibili
Metto in selected, poi ci
penseranno loro

113. Non e’ uguale
Stiamo dando forma a due interazioni diametralmente opposte

114. Architetture, Processi e Tools
Gli strumenti inducono alcuni gesti invece che altri
Piccoli gesti ripetuti ed accumulati ci portano lontano
dell’obiettivo.
Il caso non e’ nostro alleato: dobbiamo pensarci noi,
ma per questo dobbiamo proteggere i confini.

115. 3. Proteggiamo i confini!
• Non lasciamo che siano altri, o il
fato a decidere come portare a casa
il risultato #SkinInTheGame
• Costruiamo un luogo dove poter
sperimentare e trovare la NOSTRA
strada giusta
Qui possiamo
fare grandi cose
BTW: lasciare i team
liberi di scegliere il loro
stack, sembra essere una
strategia vincente

116. Minimizziamo le dipendenze
Analizzare I flussi di business con il focus sul comportamento
aiuta a trovare i confini naturali per minimizzare le dipendenze.
Dipendenze Sbagliate -> Death by Coordination Meetings
(“Massimizzare il lavoro non fatto”)
#Pratiche
#Architettura
#Business
#Processo
#Persone

117. E Sam?

119. 4. Provate!
Si impara dagli esperimenti ed anche dagli errori!
Non fidatevi degli esperti da bar…
Contesto
Quello che troppo
spesso dimentichiamo,
ma che fa la differenza.
🙂