Vent'anni dopo

Abstract

“Vent’anni dopo”, ma dopo cosa? Era il 2002 quando per la prima volta ho letto “Extreme Programming Explained: Embrace Change”, e vi assicuro che quella prima lettura è stata illuminante! Da allora cerco, con risultati alterni, di lavorare applicando XP.

Ne è passato di tempo da quella prima volta che lessi il libro e da allora l’ho letto e riletto svariate volte. Ogni volta ho scoperto qualcosa di nuovo e sono certo che mi rimangono ancora cose da scoprire :-)

In questi vent’anni di software ne ho scritto e tante cose sono cambiate. Vorrei raccontarvi qualcosa di questo mio percorso. Vorrei raccontarvi come nel 2002 ci siamo inventati dei modi per testare un portale web scritto in PHP. Vorrei raccontarvi come nel 2012 abbiamo fatto continuous delivery sviluppando un’applicazione cloud native e come avevamo automatizzato la creazione e configurazione di un ambiente cloud ibrido. Vorrei raccontarvi queste e tante altre cose, ma che valore ha raccontarvi tutte queste cose mettendo me come protagonista?

C’è forse qualcosa che posso raccontarvi di questo mio percorso in cui il protagonista non sono io, ma l’eXtreme Programming? Ovviamente sì…

Cosa hanno imparato i partecipanti

Al termine del talk, i partecipanti porteranno a casa spunti pratici e riflessioni chiave per orientarsi nel panorama dello sviluppo software contemporaneo:

• La vera essenza di XP come movimento evolutivo: comprendere come valori, principi e pratiche si siano trasformati dalla prima alla seconda edizione e come continuino ad adattarsi al contesto attuale.
• L’analogia della “guida di traverso”: imparare a concepire lo sviluppo software come un continuo e rapido riallineamento di rotta (feedback continuo) di fronte all’incertezza, anziché la rigida esecuzione di un piano preordinato.
• Giro di manopole e fine-tuning: capire cosa significa portare le pratiche “al massimo” (knobs at 10) e come bilanciarle con flessibilità in base al proprio team, contesto e strumenti moderni.
• Atteggiamento eXtreme, non estremista: riconoscere la differenza tra adottare con pragmatismo le pratiche ingegneristiche e l’applicarle in modo dogmatico.