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.
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’
9. “I miei colleghi non fanno TDD”
TDD
Commit distruttivi
#Pratiche
#Architettura
#Business
#Processo
#Persone
No TDD
WTF!
Copertura a macchia
di leopardo
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)
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)
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
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
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…?
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
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!
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
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
🙂
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
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!
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!
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…
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
86.
87.
88.
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
95. Non abbiamo alcuna notizia di
aziende che cerchino aiuto per
uscire dall’architettura esagonale
Forse, Alcune architetture sono piu’ reversibili di altre
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.
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
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
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
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.
🙂