Keynote “L’illusione dell’ortogonalità (la sfiga non esiste)”
Alberto Brandolini, CEO di Avanscoperta, ha curato il keynote di questo IAD 2021 parlandoci di ortogonalità, o meglio dell’illusione dell’ortogonalità.
Cosa abbiamo scoperto in questi 20 anni di vita del Manifesto per lo Sviluppo Agile di Software?
Focalizzarsi su un singolo aspetto – il processo, il Test-Driven Development (TDD), l’avere un codice pulito, o 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.
TDD
Per chi lavora praticando il TDD sa bene che porta diversi vantaggi quali un design dell’applicazione migliore e del codice affidabile perché sviluppato appunto “guidato dai test” – e aperto alle evoluzioni. Il TDD non è una pratica strettamente ingegneristica, secondo Alberto ha impatti anche a livello di ansia, pianificazione e reattività di business.
Per rendere più coinvolgente e divertente il suo ragionamento, Alberto ha utilizzato un personaggio immaginario, Sam. Un uomo di una certa età e con una certa esperienza, un po’ scettico e soprattutto sospettoso.
Che cosa dice Sam?
“Se lavori applicando il TDD ci metti il doppio del tempo per fare qualunque feature.” e ancora “Non sempre funziona”.
Prendiamo il seguente scenario di un team composto da persone che non lavorano in TDD oppure dove è un solo membro a praticarlo. Che cosa succede? Si hanno porzioni di codice completamente testate e altre no, quindi non appena si esegue un commit sul branch la pipeline inevitabilmente si rompe.
Sam, reticente al TDD, inizia a praticarlo per poi dire al collega “Io cucino, il tempo laverà i piatti” ovvvero “Ti accontento, però ricorda che sei la persona che vuole la cucina pulita ogni volta, ora quindi la devi mantenere pulita“.
Certi contesti lavorativi, dove si possono trovare persone come Sam che non colgono il reale valore di alcune pratiche, non sono contesti vincenti.
Quale ingrediente manca? Per Alberto è una questione di assenza di confini, chiari e condivisi, ad esempio delle best practice condivise da tutti.
Contesto
Sam continua ad essere scettico perché, nonostante lavorare in TDD abbia migliorato il codice e la qualità del prodotto, i bug rimangono.
È una questione di contesto, è fondamentale lavorare avendo piena consapevolezza dei confini all’interno del quale potersi muovere.
Riprendendo l’approccio Domain-Driven Design (DDD) e le sue definizioni fondamentali (dalla pagina Wikipedia), il contesto è importante:
- Dominio: un contesto di conoscenza, influenza, o attività. L’area in cui l’utente lavora con il software è il dominio dello stesso.
- Modello: un sistema di astrazione che descrive specifici aspetti del dominio e che può essere usato per risolvere problematiche relative alla definizione del dominio.
- Ubiquitous Language: un set di termini creato attorno al modello di dominio utilizzato dal team per indirizzare e contestualizzare i problemi da risolvere durante l’implementazione.
- Contesto: l’ambiente in cui un determinato termine assume un determinato significato.
Esiste anche il concetto di Bounded Context, ovvero ambiti applicativi indipendenti gli uni dagli altri ed ognuno con il proprio Ubiquitous Language. Dotarsi quindi di Bounded Context aiuta a capire come risolvere un problema specifico per certe persone e con un certo obiettivo. Quindi con confini ben precisi.
Sam ha un’altra obiezione: “Ok, ho svolto degli esercizi in TDD ma la realtà è tutta un’altra storia”.
Se fatto bene, anche un progetto reale è simile agli esercizi, è tutta una questione di avere definito dei confini ben precisi.
Stime e dipendenze tra team
Bisogna tener conto anche delle stime quando lavoriamo ad un progetto. È difficile, ma non impossibile, stimare il lavoro. Stimare zone ad alta incertezza (codice legacy pericoloso o attività altrui) ha margini di errore decisamente più alti. Le dipendenze contano, anche quando vorremmo che fosse solo un problema di processo. Magari c’è un problema di architettura che limita le relazioni tra le persone in azienda.
Idealmente ogni team dovrebbe rispondere a pochi progetti, ma la realtà è ben diversa: i team hanno dipendenze tra loro che portano inevitabilmente a problemi. Prendiamo per esempio un’azienda con diversi team che lavorano su uno stesso progetto, può capitare che magari un team rimanga fermo fintanto che l’altro team non avrà completato un lavoro. Peggio ancora quando un team, magari con skill specifiche, è fermo in attesa del completamento di una precisa fase del progetto.
Architettura
Alberto ha utilizzato una metafora tanto simpatica quanto calzante, ovvero quella del “mammut nel guardaroba” per parlarci di tutti quei casi in cui un’azienda progetta una applicazione software partendo da dati centralizzati in un unico database, il mammut appunto. Adottare questo approccio porterebbe quasi certamente ad avere una centralizzazione di concetti, inoltre le forti dipendenze architetturali e di team si tradurrebbero in problemi di coordinamento e stress…insomma, un freno lato business.
Intanto il caro e vecchio Sam fa un’altra obiezione: “Stiamo passando a un’architettura a microservizi, non c’è problema. Tutto si risolverà.”.
Event-Driven Design
Perché non basarsi su un’architettura Event-Driven, ovvero guidata dagli eventi? Questo tipo di architettura può aiutare le organizzazioni a realizzare un sistema flessibile che consenta loro di trasformarsi prendendo anche decisioni in tempo reale. Disporre di informazioni in tempo reale significa poter sfruttare tutti i dati disponibili che riflettono lo stato attuale del sistema per prendere qualsiasi decisione aziendale, sia manuale sia automatizzata.
Conclusioni
Come riportato nel titolo del suo keynote, la sfortuna nei progetti non esiste. Sono le aziende stesse a “fare sì che vada male”. Ciò che dobbiamo fare è ripartire dalle basi, dalle piccole attività ma fatte bene (Pair Programming, TDD, ecc…) lavorando in contesti ben definiti dove tutti abbiano ben chiaro l’obiettivo finale.