Metodologie di sviluppo

Storie di Sviluppo: Viaggio tra le Metodologie del Software

Nel mondo frenetico dello sviluppo software, dove codici prendono vita e idee si trasformano in realtà, le metodologie sono la bussola che guida il processo. Ogni metodologia ha la sua storia, il suo fascino e le sue battaglie, raccontandoci l’evoluzione del pensiero e l’ingegno di chi le ha create. La narrazione di una buona storia parte sempre dalle sue radici e quando si parla di metodologie di sviluppo e passato, non si può non citare il pilastro delle metodologie: il Modello a cascata.

Nascita e Ascesa: I Pilastri del Passato

Tutto ebbe inizio negli anni ‘60, lo sviluppo software iniziò a industrializzarsi e c’era bisogno di un metodo che definisse bene la strada da percorrere tra l’idea e il prodotto finito. La prima metodologia a nascere è il Modello a Cascata (O Waterfall), il pioniere strutturato. Introdotto per la prima volta dal Dr. Winston W. Royce che ne ha parlato in un articolo pubblicato nel 1970, il modello a cascata prevede la divisione in fasi rigide e sequenziali: analisi, progettazione, implementazione, test e manutenzione. Un approccio ordinato, perfetto per progetti ben definiti e con requisiti chiari. Ma la sua rigidità iniziò a scricchiolare con l’avanzare della complessità. Negli anni ’70, i computer iniziarono a prendere piede portando ad una richiesta di produzione e aggiornamento dei software sempre più rapida e dinamica.

Negli anni ’80 il modello a cascata ricevette molte critiche. Gli addetti ai lavori si sforzarono di inventare un modello che potesse sostituire il Waterfall una volta per tutte. Uno di questi fu Peter DeGrace, che creò il modello Sashimi.

DeGrace non introdusse idee rivoluzionarie, ma cercò di dare un po’ di flessibilità alla metodologia Waterfall. Nel modello di DeGrace, tutte le fasi di sviluppo del software vicine si sovrappongono tra loro. Ciò significa che, durante la fase di codifica vera e propria, sono stati eseguiti anche la progettazione dettagliata e i test.

Quello che doveva essere il suo punto di forza alla fine si rivelò la sua debolezza. Se Waterfall era una metodologia troppo rigida, Sashimi era troppo traballante. Nessuno sapeva cosa stesse succedendo esattamente in un dato momento, la gestione dei progetti finiva con il diventare un disastro.

Sfide e Adattamenti: L’Era dell’Evoluzione

Gli anni ‘70 e ‘80 videro nascere nuovi eroi per domare il caos crescente. Il primo tentativo di donare flessibilità alle metodologie di sviluppo avviene con il Modello Incrementale. Già dai primi anni ’70 troviamo diverse menzioni a concetti che richiamano l’attenzione sul concetto della pianificazione e controllo iterativo. Le menzioni più interessanti le troviamo nel libro “An Introduction to General Systems Thinking” di Gerald M. Weinberg e nel pioniere David Parnas che introdusse il concetto di modularità, suggerendo di suddividere i sistemi software in componenti più piccoli e gestibili.

Il principio base del modello incrementale è proprio quello di suddividere il progetto in piccoli moduli o incrementi, con test e feedback a ogni iterazione.

Il Modello Prototipazione si presentò come esploratore coraggioso, creando modelli funzionanti per raccogliere feedback e affinare l’idea. Nasce come estensione del modello incrementale, facendo del concetto di prototipo il suo punto di forza. Gli sviluppatori hanno iniziato a rendersi conto dell’importanza di testare la fattibilità delle idee prima di produrre il prodotto finale. Ciò ha portato a un nuovo approccio: lo sviluppo di software prototipo. Questo processo implicava la produzione di versioni iniziali in grado di simulare il prodotto finale, raccogliendo nel contempo parametri di prestazione e feedback degli utenti. I risultati servono come base per eventuali miglioramenti alla versione finale prima del rilascio. La prototipazione ha aggiunto una fase vitale al ciclo di vita dello sviluppo del software, durante le fasi di progettazione e sviluppo. Ciò ha condotto a due scoperte distinte che alla fine hanno portato allo sviluppo della metodologia di sviluppo Agile. Innanzitutto, ha aperto il software a un approccio iterativo. Lo sviluppo del software è diventato un processo ciclico di prototipazione, test, analisi e perfezionamento del prodotto. Inoltre, la prototipazione ha aperto gli sviluppatori al valore dei dati generati dagli utenti. Ciò ha aiutato a testare il software in una moltitudine di scenari utente, generando feedback critici nel miglioramento delle prestazioni.

Nel 1986, Barry Boehm descrisse il processo di sviluppo del software sotto forma di modello a spirale. I processi a spirale utilizzano concetti di sviluppo iterativo per ridurre i rischi. Questo modello è ideale per progetti grandi e complicati. Inoltre, segue le stesse fasi del modello Waterfall, colmando le grandi lacune di quest’ultimo includendo la pianificazione, la valutazione del rischio, creazione e simulazioni di prototipi. I contro principali di questa metodologia sono:

  • È sicuramente un modello costoso da utilizzare in termini di sviluppo
  • Il successo del progetto dipende tutto dall’analisi fatta all’inizio.

Il Ciclo dei Feedback: Cuore Pulsante dell’Evoluzione

È proprio in questo contesto che prende forma uno degli elementi più trasformativi dell’intero sviluppo software: il ciclo dei feedback. Nelle prime fasi, i feedback arrivavano tardi, spesso solo a progetto quasi concluso, causando ritardi, costi aggiuntivi e risultati lontani dalle aspettative. Con l’evolversi delle metodologie iterative e agili, il feedback è stato riscoperto come strumento vitale: non più posticipato, ma continuo, tempestivo e integrato in ogni fase del processo.

Il ciclo dei feedback è diventato il battito cardiaco del progetto, scandendo il ritmo delle iterazioni, delle revisioni, dei rilasci. Che si tratti di un commento dell’utente su un prototipo o di un bug scoperto in un test automatico, ogni feedback contribuisce a un apprendimento rapido e allineato con la realtà. È attraverso questo ciclo costante che il software smette di essere un prodotto statico per diventare un organismo in evoluzione, plasmato da chi lo usa e da chi lo costruisce. Il feedback, così, non è solo un’opinione: è una direzione, un allarme, una conferma, un’opportunità.

Rivoluzione Agile: Manifesto per un Nuovo Mondo

Primi anni 2000, precisamente 2001, un gruppo di ribelli si riunì a Snowbird nello Utah. Erano gli esponenti del Movimento Agile, stanchi dei modelli pesanti e desiderosi di un cambiamento radicale. Da quell’incontro nacque uno dei manifesti più famosi nel mondo dell’informatica. Il manifesto agile divenne la bandiera di una rivoluzione: sviluppo incrementale, collaborazione tra team e clienti, adattamento continuo al cambiamento, e focus su individui e le loro interazioni erano i loro concetti chiave.

Il Manifesto Agile non definì una metodologia specifica, ma piuttosto un insieme di principi guida. Negli anni successivi, diverse metodologie Agile sono nate ispirandosi a questi principi, tra cui: Scrum, Kanban, Extreme Programming (XP) e Lean Development.

Il fulcro dello sviluppo Agile, come suggerisce il nome, è la flessibilità. Con i metodi Agile, i team di sviluppatori possono evitare errori costosi, risparmiare tempo e risorse e mantenere i clienti felici e fedeli quando sono coinvolti nel processo di sviluppo. Flessibilità significa anche che lo sviluppo agile consente ai progetti di evolversi naturalmente man mano che il mercato e le esigenze cambiano.

In un ambiente Agile, l’idea iniziale è prepararsi per un ciclo di sviluppo a breve termine, completo di obiettivi e requisiti. Utilizzando team più piccoli ma affiatati, gli sviluppatori si impegnano a completare un’iterazione il prima possibile.

Scrum: Rugby nello Sviluppo

Il framework Scrum suddivide il tempo del ciclo di sviluppo in periodi di lavoro specifici chiamati sprint. Prima dello “sprint” vero e proprio, viene convocata una sessione di pianificazione in cui vengono assegnati i compiti e fissati gli obiettivi. Il Product Owner delineerà un product backlog con priorità e discuterà con i team come completare ciascun elemento. Il gruppo stima collettivamente lo sforzo richiesto, il che porta a una previsione dello sprint. Questa, elenca la quantità di lavoro che può essere completata dal backlog. Scrum fornisce la struttura per aiutare i team a lavorare insieme.

Gli sprint, che di solito durano due settimane, sono il periodo in cui gli sviluppatori si mettono al lavoro per completare un obiettivo determinato dai project manager.

Durante gli sprint, i progressi vengono visualizzati sulla lavagna mostrando quali attività devono essere completate, quali sono in corso e quali sono state completate. Sono previsti incontri giornalieri (stand-up) (con gli ‘sprint’ in movimento) per valutare lo stato di avanzamento del progetto.

Gli stand-up sono solitamente il momento migliore per allineare i membri del team. Si basano su 3 principi cardine:

  • Durata, non oltre i 15 minuti.
  • Partecipanti, si consiglia non superare i 10 membri
  • Domande, ‘Cosa hai fatto ieri?, Cosa farai oggi?, Qualcosa sta bloccando i tuoi progressi?’

I tre ruoli cardine della metodologia sono:

Product Owner, questa persona è responsabile della pianificazione iniziale, dell’assegnazione delle attività, della definizione delle priorità e del mantenimento della comunicazione durante tutto il progetto.

Scrum Master, questa persona supervisiona il processo durante lo sprint e garantisce che i programmi vengano rispettati e che vengano compiuti progressi.

Development team, si tratta di singoli sviluppatori incaricati di svolgere i ruoli assegnati durante lo sprint. Simile al suo omonimo rugby, la mischia consente alle squadre di organizzarsi, adattarsi ai cambiamenti nell’ambiente e imparare dall’esperienza per migliorare il processo.

Kanban: Visualizzare il Flusso

Il Kanban, ispirandosi al sistema di gestione delle scorte giapponese, introdusse un sistema di schede visive per monitorare il flusso di lavoro. Un approccio adattivo che permetteva di vedere il lavoro in corso, i colli di bottiglia e le priorità in un colpo d’occhio. Come una bacheca ben organizzata, dove ogni post-it rappresenta un tassello del puzzle.

Kanban, nel frattempo, richiede una comunicazione della capacità in tempo reale e piena trasparenza. Similmente a Scrum, le attività sono rappresentate visivamente su una lavagna Kanban, consentendo a tutti i membri del team di vedere lo stato di ogni attività in qualsiasi momento.

In contrasto con gli sprint di lavoro definiti di Scrum, la metodologia Kanban comporta un flusso di lavoro più fluido senza ruoli definiti. Kanban enfatizza lo sviluppo e il miglioramento continui del processo. Il progetto (o la storia dell’utente) non stabilisce un periodo di tempo per il completamento delle attività. Si iscrive invece al completamento delle attività in base alla priorità.

Per aiutare a concentrarsi sui risultati finali e non essere sopraffatti dai compiti, i tabelloni Kanban di solito fissano un limite al numero di carte Work In Progress posizionate sul tabellone. Le nuove attività possono essere aggiunte alla bacheca solo una volta completate le attività precedenti. Ciò è in sintonia con il suo principio di consegna continua senza sovraccaricare i team.

Extreme programming (XP)

Nata dalle menti di Kent Beck (uno dei 17 firmatari originali del Manifesto Agile), Ward Cunningham e Ron Jeffries alla fine degli anni ‘90, XP sfida i confini convenzionali dello sviluppo, spingendo i team a confrontarsi con cicli di sviluppo rapidi, test continui e un codice impeccabile. Beck, già pioniere del Modello di Sviluppo Incrementale, era alla ricerca di un metodo che superasse i limiti dei modelli tradizionali e abbracciasse i principi di flessibilità, adattamento e collaborazione.

XP nasce da esigenze concrete:

  • Incapacità dei modelli tradizionali di gestire la complessità: Progetti software di grandi dimensioni e in continua evoluzione richiedevano un approccio più flessibile.
  • Comunicazione inefficiente tra team e clienti: La mancanza di collaborazione portava a software non allineato con le reali esigenze degli utenti.
  • Codice di bassa qualità: I lunghi cicli di sviluppo e la scarsa enfasi sui test producevano software buggato e difficile da manutenere.

Per affrontare queste sfide, XP si basa su pochi e semplici concetti:

  • Comunicazione: Dialogo aperto e costante per garantire una visione condivisa.
  • Semplicità: Design minimalista e codice elegante per favorire chiarezza e manutenibilità.
  • Feedback: Flusso continuo di feedback per orientare lo sviluppo e adattarsi rapidamente.

L’Extreme Programming prevede delle pratiche chiave nella sua applicazione:

  • Pair Programming: Due programmatori lavorano insieme su un singolo computer per scrivere codice, promuovendo una revisione continua e una migliore qualità del codice.
  • Test-Driven Development (TDD): Prima si scrivono i test, poi il codice necessario per passare quei test, assicurando una copertura di test elevata e una progettazione orientata ai test.
  • Refactoring: Migliorare continuamente il design del codice senza modificare il comportamento esterno per mantenere il codice pulito e manutenibile.
  • Continuous Integration: Integrare e testare il codice frequentemente per individuare e correggere gli errori rapidamente.
  • Small Releases: Rilasci frequenti e incrementali del software per fornire valore continuo ai clienti e ottenere feedback regolari.

Nonostante sia nata negli anni ‘90, XP continua ad evolversi e ad adattarsi alle nuove esigenze del mondo del software. I suoi principi e le sue pratiche rimangono rilevanti per team che desiderano sviluppare software di alta qualità in modo rapido e flessibile

Lean development

Nato negli anni ‘90 come adattamento dei principi del Toyota Production System (TPS) al mondo software, il Lean Development propone un approccio che valorizza il flusso continuo, la riduzione delle code e la centralità del cliente.

Le origini del Lean Development affondano negli anni ‘50, quando Taiichi Ohno, ingegnere della Toyota, rivoluzionò il sistema produttivo dell’azienda nipponica con il TPS. L’obiettivo era eliminare gli sprechi (muda), produzione Just-in-Time (JIT) basata sulla domanda reale e non sulla produzione di massa, e automazione (Jidoka) dove le macchine sono progettate per rilevare automaticamente i problemi e fermarsi per evitare la produzione di pezzi difettosi.

Negli anni ‘90, ispirati dai successi della Toyota, Mary e Tom Poppendieck, due studiosi americani, applicarono i principi del TPS al mondo dello sviluppo software. Nacque così il Lean Development, un paradigma che proponeva di adattare i concetti di flusso continuo, riduzione delle code e rispetto per le persone al processo di creazione di software.

Per affrontare queste sfide, il Lean Development si basa su sette principi fondamentali:

  • Eliminare gli sprechi: Identificare e rimuovere le attività non produttive che non apportano valore al cliente.
  • Amplificare il feedback: Raccogliere e utilizzare costantemente feedback da clienti e utenti per migliorare il software.
  • Decidere il più tardi possibile: Posticipare le decisioni non critiche fino a quando si dispone di maggiori informazioni per ridurre il rischio di errore.
  • Consegnare il più velocemente possibile: Rilasciare frequentemente nuove versioni del software per incorporare feedback e adattarsi alle esigenze.
  • Creare una base di conoscenza solida: Documentare le lezioni apprese e le migliori pratiche per migliorare continuamente.
  • Rispettare le persone: Valorizzare le competenze e l’esperienza del team per creare un ambiente di lavoro positivo e collaborativo.
  • Vedere l’intero flusso di lavoro: Comprendere le interconnessioni tra le diverse attività del processo di sviluppo per ottimizzare il flusso di lavoro.

Test Driven Development (TDD)

Nel panorama dello sviluppo software, il Test Driven Development (TDD) emerge come una filosofia che rivoluziona il modo di creare software. Nato a cavallo tra i due millenni, il TDD propone un approccio in cui i test non sono un’attività successiva allo sviluppo, ma il motore stesso del processo creativo. Scrivere test automatici prima e durante la stesura del codice permette di garantire qualità, affidabilità e un design robusto fin dalle prime fasi.

Le origini del TDD possono essere rintracciate in diverse correnti di pensiero: Sviluppo incrementale ed Extreme Programming. Kent Beck ha introdotto il TDD in modo più formale con la pubblicazione del libro “Test-Driven Development: By Example” nel 2002. In questo libro, Beck descriveva il processo di sviluppo guidato dai test, fornendo esempi pratici e linee guida per gli sviluppatori.

Il TDD si basa su tre semplici principi (Red-Green-Refactor):

  • Scrivere un test automatico che fallisce (Red): Prima di scrivere una linea di codice, definire un test automatico che specifica il comportamento desiderato della nuova funzionalità.
  • Far passare il test con il minimo codice necessario (Green): Scrivere il codice più semplice possibile per far passare il test appena scritto.
  • Riorganizzare il codice senza modificare il comportamento (Refactor): Migliorare la struttura e la leggibilità del codice senza alterare il comportamento testato.

Il TDD ha avuto un impatto significativo sul modo in cui viene sviluppato il software, diventando una pratica fondamentale non solo in XP, ma anche in molte altre metodologie agili e di sviluppo software. Ha contribuito a diffondere l’importanza del testing automatico e della qualità del codice, influenzando positivamente la disciplina e la professionalità nello sviluppo software.

DevOps: storia di una collaborazione vincente

Il termine DevOps nasce dall’unione di Development e Operations ed è emerso ufficialmente alla fine degli anni 2000, quando le crescenti tensioni tra sviluppatori e sistemisti minacciavano l’agilità dei processi software, ampliando sempre più quella che veniva considerata una disfunzione fatale nel settore.

Uno degli eventi chiave che segnò la nascita del movimento DevOps fu la conferenza Velocity del 2009, durante la quale John Allspaw e Paul Hammond (ingegneri di Flickr) presentarono il celebre talk “10+ Deploys per Day: Dev and Ops Cooperation at Flickr”. Dimostrarono come fosse possibile effettuare oltre dieci deploy al giorno grazie a una stretta collaborazione tra sviluppo e operazioni. I punti chiave del loro talk sono:

  • 1. Dev e Ops non devono essere separati: Tradizionalmente, gli sviluppatori scrivono codice e lo “buttano oltre il muro” agli ops. Questo crea frizioni, rallenta i rilasci e aumenta il rischio di errori.
  • 2. Automazione e strumenti: Flickr ha adottato automazione ovunque possibile, incluso il deploy, il testing e il monitoraggio. Usavano strumenti come Fabric (per il deploy) e scripts personalizzati per facilitare i rilasci.
  • 3. Deploy piccoli e frequenti: Invece di fare pochi rilasci grandi e dolorosi, è meglio fare molti piccoli cambiamenti: sono più facili da testare, monitorare ed eventualmente ritirare. Rilasci frequenti riducono il rischio perché ogni modifica è isolata.
  • 4. Feature toggles: Le nuove funzionalità venivano rilasciate in produzione ma disattivate per gli utenti, in modo da testarle in sicurezza. Permettevano anche di fare test A/B o rollout graduali.
  • 5. Responsabilità condivisa: Tutti erano responsabili della stabilità del sistema, non solo gli ops. Se qualcosa andava storto, si lavorava insieme per risolvere e imparare, evitando colpe e cercando collaborazione continua.

Da quel momento, DevOps si è trasformato da semplice metodologia a cultura aziendale, promuovendo automazione, integrazione continua e monitoraggio costante. Oggi, aziende come Netflix, Amazon e Google ne sono esempi iconici, avendo reso i rilasci frequenti e affidabili una routine quotidiana.

Conclusioni: Un Viaggio Continuo

Il mondo delle metodologie di sviluppo è in continua evoluzione. Nuove idee nascono, vecchie si adattano, e la ricerca della metodologia perfetta continua. Ogni progetto è un’avventura unica, che richiede la giusta bussola per orientarsi. E la storia di queste metodologie ci insegna che il miglior approccio è quello che sa abbracciare il cambiamento, la flessibilità e la collaborazione.