Progettare il software per un feedback migliore

L'agilità si fonda sul feedback, e il feedback più sincero è quello che proviene dal software funzionante, nelle mani degli utenti finali!

Molte pratiche agili servono a migliorare la qualità del feedback, e le organizzazioni hanno imparato a farne buon uso, ma spesso l'architettura del software rema contro: vorremmo potere avere feedback migliore rapidamente, ma sembra quasi che le nostre architetture e le nostre codebase si rifiutino testardamente di collaborare.

In questa presentazione vorrei raccontare come si può intenzionalmente orientare l'architettura del software per ottenere feedback più rapidi.

La presentazione è pensata per coloro che, pur non essendo necessariamente dei tecnici, dipendono dall'output dei team tecnici, e cerca di dare degli strumenti per capire che cosa chiedere ai tecnici, come aiutarli e come indirizzarli.

Transcript

1. © 2025 Thoughtworks | Restricted Progettare il software per un feedback migliore Matteo Vaccari
2. © 2025 Thoughtworks | Restricted 2 Scrum + XP = Nirvana Abbiamo un team che • consegna incrementi di prodotto • nelle mani degli utenti finali • ogni settimana! Si può fare. È un problema risolto.
3. © 2025 Thoughtworks | Restricted Ma 3
4. © 2025 Thoughtworks | Restricted Ma 4 • Non abbiamo un team. Ne abbiamo molti • Team che consegnano elaborati intermedi ad altri team (component teams) • Team legati agli strati tecnologici (infra, backend, frontend) • Team legati alle fasi (dev, qa, ops) E le conseguenze sono… ⇒ nessun team è in grado di consegnare incrementi di prodotto ⇒ il feedback si misura in mesi non giorni
5. © 2025 Thoughtworks | Restricted 5 About me & my employer • Technical Principal in Thoughtworks • Extreme Programmer • Developer, trainer and coach We're a leading global technology consultancy that integrates • strategy, • design and • software engineering to enable our clients to thrive. Martin Fowler Io
6. © 2025 Thoughtworks | Restricted 1. Pattern facili 6
7. © 2025 Thoughtworks | Restricted Pattern: fettine verticali 7 Products Desirable Usable Functional Vertical slice Products Apps and Services Channel Dashboard Customer experience PaaS IaaS Horizontal slice Products Channel Dashboard Customer experience IaaS Apps and Services PaaS Desirable Usable Functional Una conseguenza non ovvia di questo principio è che iniziamo con una rozza approssimazione del prodotto finito, che viene poi raffinata
8. © 2025 Thoughtworks | Restricted Pattern: fettine verticali 8 Spesso lʼiterazione zero viene dedicata a task tecnici preparatori senza alcun risultato visibile agli stakeholder. Dite di no! Insistete per vedere un walking skeleton dopo 1 o max 2 settimane Photo by Keystone-France/Gamma-Keystone via Getty Images
9. © 2025 Thoughtworks | Restricted Pattern: scheletro che cammina 9 Photo by Keystone-France/Gamma-Keystone via Getty Images Uno scheletro che cammina è unʼimplementazione minimale end-to-end dellʼarchitettura finale Attraversa tutti gli strati tecnologici Non esegue logica di business, ma dimostra che il sistema è integrato Può essere dato in mano agli utenti per dimostrare che funziona!
10. © 2025 Thoughtworks | Restricted Consegna Pattern: in produzione dall’inizio 10 Inizio progetto Tempo Caos Consegna Inizio progetto Tempo Caos Progetto tradizionale: la produzione viene predisposta verso la fine Progetto agile: la produzione viene predisposta allʼinizio
11. © 2025 Thoughtworks | Restricted 2. Pattern più impegnativi 11
12. © 2025 Thoughtworks | Restricted Bounded contexts 12 Vendite Marketing Spedizioni Magazzino Un tempo si cercava di definire un singolo modello unificato di tutti i dati dellʼimpresa. Oggi sappiamo che lʼimpresa è vana e controproducente: diversi contesti necessitano di diversi modelli
13. © 2025 Thoughtworks | Restricted Bounded contexts 13 Vendite Marketing Spedizioni Magazzino Il database condiviso è alla base del 98% dei problemi di delivery software delle grandi aziende Antipattern: integrazione tramite database
14. © 2025 Thoughtworks | Restricted Pattern fondamentale: 1-1-1 14 One bounded context One team One database Stakeholders End users Il team è autonomo e in grado di consegnare software end-to-end. È uno “stream-aligned teamˮ in Team Topologies Feedback!
15. © 2025 Thoughtworks | Restricted 1-1-1 at scale 15 Bounded context End users Stakeholders Bounded context Bounded context API Eventi
16. © 2025 Thoughtworks | Restricted Ostacolo: DB centralizzato 16 Come garantire la consistenza se buttiamo dalla finestra il DB condiviso? Bounded context Bounded context Eventi Dʼaltronde le banche riescono a trasmettere bonifici senza avere un DB condiviso! O no? Rinunciamo alla consistenza istantanea – ci accontentiamo di consistenza finale (eventuale) Pattern per transazioni senza DB centrale: • Eventi di dominio • Saghe • Controlli di quadratura • Compensating transactions
17. © 2025 Thoughtworks | Restricted Ostacolo: integrazione centralizzata Servizi centralizzati che il team deve invocare • Esempi: Autenticazione, API gateway, Enterprise Service Bus 17 ESB Bounded context Bounded context Bounded context API GW ✋ ✋ ✋ Bounded context Bounded context ✋ ✋ ✋
18. © 2025 Thoughtworks | Restricted Pattern: X-as-a-service 18 Il team A fornisce capacità al team B • Benefici: ◦ Semplicità: il team cliente non deve conoscere i dettagli ◦ Autonomia: il team cliente non deve chiedere permesso ◦ Compliance: i servizi offerti incorporano i principi architetturali dellʼazienda • Esempi: ◦ Deployment-as-a-service: supporta “You build it-you run itˮ ◦ Observability-as-a-service: aiuta i team a rendere più osservabile ed operabile il loro codice • How to: ◦ X-as-a-product! ◦ Documentation ◦ User research
19. © 2025 Thoughtworks | Restricted Esempio: Enterprise Service Bus 19 Spesso introdotto per risolvere il problema che “tutto parla con tuttoˮ Spesso si finisce che “tutto parla con tutto… attraverso il service busˮ
20. © 2025 Thoughtworks | Restricted Come risolvere il groviglio? 1. Visualizzare i pattern effettivi di comunicazione 2. Analizzare le comunicazioni duplicate o inefficaci 3. Rifattorizzare il servizio 20 Come risolvere il problema di governance? • Installare opportune architectural fitness functions
21. © 2025 Thoughtworks | Restricted Pattern: architectural fitness function 21 • Che cosʼè? ◦ Verifica automatica di quanto lʼarchitettura sia conforme a determinati obiettivi ◦ Crea un feedback continuo sulla “saluteˮ dellʼarchitettura (reale, non su carta! • Benefici: ◦ Autonomia: la regola architetturale viene verificata a posteriori ◦ Compliance: conosciamo il livello di integrità del sistema • Esempi: ◦ Dashboard che mostrano il volume di traffico da punto a punto ◦ Stadi di pipeline che misurano la qualità del codice
22. © 2025 Thoughtworks | Restricted Ostacolo: il team di infrastruttura • Il dev team deve chiedere permesso per ottenere o modificare infrastruttura • Sintomi: ◦ tempi di attesa per il procurement dellʼhardware ◦ Il team di Infra ha una lunga coda di cose da fare • Soluzione ◦ Deployment-as-a-service ◦ Internal-developer-platform-as-a-product 22 Non: “ti do una libreria di codice Terraform poi ti arrangiˮ Ma: “lancia questo comando per deployareˮ
23. © 2025 Thoughtworks | Restricted Pattern: Internal Developer Platform 23 Potrebbe essere semplice come Heroku o Fly.io 1. installa il toolkit con brew install flyctl. 2. descrivi il tuo servizio 3. esegui flyctl launch <tag> <environment> app = "your-app-name" primary_region = "eu-west-1" [services] postgresql = true storage_s3 = true [[vm]] cpu_kind = "shared" cpus = 1 memory_mb = 1024 I benefici di una Internal Developer Platform sono ovvi. Non è ovvia la quantità di investimento e impegno necessari per farla funzionare bene!
24. © 2025 Thoughtworks | Restricted 3. Come agire? 24
25. © 2025 Thoughtworks | Restricted Visualizza il Path To Production 25 Spiegato nel Thoughtworks Enterprise Architecture Playbook – chiedimi una copia!
26. © 2025 Thoughtworks | Restricted We look forward to working with you Matteo Vaccari Technical Principal matteo.vaccari@thoughtworks.com 26