Cos'è la metodologia agile? Spiegazione dello sviluppo del software moderno

Ogni organizzazione tecnologica oggi sembra mettere in pratica la metodologia agile per lo sviluppo del software, o una sua versione. O almeno credono di sì. Che tu sia nuovo nello sviluppo di applicazioni agili o che tu abbia imparato lo sviluppo di software decenni fa utilizzando la metodologia di sviluppo software a cascata, oggi il tuo lavoro è almeno influenzato dalla metodologia agile.

Ma cos'è la metodologia agile e come dovrebbe essere praticata nello sviluppo del software? In che modo lo sviluppo agile differisce dalla cascata nella pratica? Qual è il ciclo di vita dello sviluppo software agile o SDLC agile? E cos'è Scrum Agile rispetto a Kanban e altri modelli Agile? 

Agile è stato formalmente lanciato nel 2001, quando 17 tecnologi hanno redatto l'Agile Manifesto. Hanno scritto quattro principi principali per una gestione agile dei progetti, con l'obiettivo di sviluppare un software migliore:

  • Individui e interazioni su processi e strumenti
  • Software funzionante su documentazione completa
  • Collaborazione con il cliente nella negoziazione del contratto
  • Rispondere al cambiamento piuttosto che seguire un piano

Prima dell'agile: l'era della metodologia a cascata

I vecchi come me ricordano i giorni in cui la metodologia a cascata era il gold standard per lo sviluppo del software. Il processo di sviluppo del software richiedeva una tonnellata di documentazione in anticipo prima che iniziasse la codifica. Qualcuno, di solito l'analista aziendale, ha prima scritto un documento sui requisiti aziendali che ha catturato tutto ciò di cui l'azienda aveva bisogno nell'applicazione. Questi documenti sui requisiti aziendali erano lunghi e dettagliavano tutto: strategia complessiva, specifiche funzionali complete e design dell'interfaccia utente visiva.

I tecnologi hanno preso il documento sui requisiti aziendali e hanno sviluppato il proprio documento sui requisiti tecnici. Questo documento ha definito l'architettura dell'applicazione, le strutture dati, i progetti funzionali orientati agli oggetti, le interfacce utente e altri requisiti non funzionali.

Questo processo di sviluppo software a cascata avrebbe finalmente dato il via alla codifica, quindi all'integrazione e infine al test prima che un'applicazione fosse considerata pronta per la produzione. L'intero processo potrebbe facilmente richiedere un paio d'anni.

Noi sviluppatori dovevamo conoscere "le specifiche", come veniva chiamata la documentazione completa, così come gli autori dei documenti, e spesso venivamo rimproverati se dimenticavamo di implementare correttamente un dettaglio chiave delineato a pagina 77 di un 200- documento di pagina.

Allora, anche lo sviluppo del software stesso non era facile. Molti strumenti di sviluppo richiedevano una formazione specializzata e non c'erano neanche lontanamente componenti software open source o commerciali, API e servizi web che esistono oggi. Abbiamo dovuto sviluppare cose di basso livello come l'apertura di connessioni al database e il multithreading della nostra elaborazione dei dati.

Anche per le applicazioni di base, i team erano grandi e gli strumenti di comunicazione erano limitati. Le nostre specifiche tecniche erano ciò che ci allineava e le abbiamo sfruttate come la Bibbia. Se un requisito cambiava, sottoponevamo i dirigenti aziendali a un lungo processo di revisione e approvazione perché la comunicazione delle modifiche a tutto il team e la correzione del codice erano costose.

Poiché il software è stato sviluppato sulla base dell'architettura tecnica, gli artefatti di livello inferiore sono stati sviluppati per primi e successivamente gli artefatti dipendenti. Le attività venivano assegnate in base alle competenze ed era comune per gli ingegneri del database costruire prima le tabelle e altri artefatti del database, seguiti dagli sviluppatori dell'applicazione che codificavano la funzionalità e la logica di business, e infine l'interfaccia utente veniva sovrapposta. Ci sono voluti mesi prima che qualcuno vedesse l'applicazione in funzione e, a quel punto, le parti interessate stavano diventando nervose e spesso più intelligenti su ciò che volevano veramente. Non c'è da stupirsi che l'implementazione delle modifiche fosse così costosa!

Non tutto ciò che metti di fronte agli utenti ha funzionato come previsto. A volte, gli utenti non utilizzerebbero affatto una funzionalità. Altre volte, una funzionalità ha avuto un grande successo ma ha richiesto una riprogettazione per supportare la scalabilità e le prestazioni necessarie. Nel mondo a cascata, hai imparato queste cose solo dopo che il software è stato distribuito, dopo un lungo ciclo di sviluppo.

Video correlato: come funziona davvero la metodologia agile

Tutti sembrano parlare di sviluppo software agile, ma molte organizzazioni non hanno una solida conoscenza di come funziona il processo. Guarda questo video di cinque minuti per essere al passo con i tempi.

Il perno dello sviluppo agile del software

Inventata nel 1970, la metodologia a cascata era rivoluzionaria perché ha portato disciplina allo sviluppo del software per garantire che ci fosse una specifica chiara da seguire. Si basava sul metodo di produzione a cascata derivato dalle innovazioni della catena di montaggio di Henry Ford del 1913, che forniva certezza su ogni fase del processo di produzione per garantire che il prodotto finale corrispondesse a quanto specificato in primo luogo.

Quando la metodologia a cascata è arrivata nel mondo del software, i sistemi informatici e le loro applicazioni erano tipicamente complessi e monolitici, richiedendo una disciplina e un risultato chiaro da fornire. Anche i requisiti sono cambiati lentamente rispetto a oggi, quindi gli sforzi su larga scala sono stati meno problematici. In effetti, i sistemi sono stati costruiti partendo dal presupposto che non sarebbero cambiati ma sarebbero state navi da guerra perpetue. I tempi pluriennali erano comuni non solo nello sviluppo del software, ma anche nella produzione e in altre attività aziendali. Ma la rigidità della cascata è diventata un tallone d'Achille nell'era di Internet, dove erano richieste velocità e flessibilità.

La metodologia di sviluppo del software ha iniziato a cambiare quando gli sviluppatori hanno iniziato a lavorare sulle applicazioni Internet. Gran parte del lavoro iniziale è stato svolto in startup in cui i team erano più piccoli, erano stati raggruppati e spesso non avevano un background informatico tradizionale. C'erano pressioni finanziarie e competitive per portare siti Web, applicazioni e nuove funzionalità sul mercato più rapidamente. Gli strumenti e le piattaforme di sviluppo sono cambiati rapidamente in risposta.

Ciò ha portato molti di noi che lavorano nelle startup a mettere in discussione la metodologia a cascata ea cercare modi per essere più efficienti. Non potevamo permetterci di fare tutta la documentazione dettagliata in anticipo e avevamo bisogno di un processo più iterativo e collaborativo. Abbiamo ancora discusso le modifiche ai requisiti, ma eravamo più aperti alla sperimentazione e all'adattamento alle esigenze degli utenti finali. Le nostre organizzazioni erano meno strutturate e le nostre applicazioni erano meno complesse dei sistemi legacy aziendali, quindi eravamo molto più aperti alla creazione rispetto all'acquisto di applicazioni. Ancora più importante, stavamo cercando di far crescere le aziende, quindi quando i nostri utenti ci hanno detto che qualcosa non funzionava, il più delle volte abbiamo scelto di ascoltarli.

Le nostre capacità e le nostre capacità di innovare sono diventate strategicamente importanti. Potresti raccogliere tutti i soldi che desideri, ma non potresti attrarre sviluppatori di software di talento in grado di lavorare con tecnologie Internet in rapida evoluzione se volessi trattarli come programmatori sottomessi che seguono pedissequamente "le specifiche". Abbiamo rifiutato che i project manager arrivassero con programmi end-to-end che descrivessero cosa dovremmo sviluppare, quando le applicazioni dovrebbero essere spedite e talvolta anche come strutturare il codice. Siamo stati terribili nel rispettare i programmi di tre e sei mesi che i responsabili del progetto a cascata hanno redatto e aggiornato incessantemente.

Invece, abbiamo iniziato a spiegare loro come progettare le applicazioni Internet e abbiamo fornito i risultati in base a una pianificazione che abbiamo stabilito in modo iterativo. Si scopre che non siamo stati così cattivi nel fornire ciò che avevamo detto che avremmo fatto quando ci siamo impegnati in piccoli intervalli, da una settimana a quattro settimane.

Nel 2001, un gruppo di sviluppatori di software esperti si sono riuniti e si sono resi conto che stavano praticando collettivamente lo sviluppo del software in modo diverso dalla classica metodologia a cascata. E non erano tutti in startup. Questo gruppo, che comprendeva i luminari della tecnologia Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber e Jeff Sutherland, ha elaborato l'Agile Manifesto che documentava le loro convinzioni condivise su come dovrebbe funzionare un moderno processo di sviluppo del software. Hanno sottolineato la collaborazione sulla documentazione, l'auto-organizzazione piuttosto che le rigide pratiche di gestione e la capacità di gestire un cambiamento costante piuttosto che bloccarsi in un rigido processo di sviluppo a cascata.

Da questi principi è nata la metodologia agile per lo sviluppo del software.

I ruoli nella metodologia agile

Un processo di sviluppo software agile inizia sempre definendo gli utenti e documentando una dichiarazione di visione su un ambito di problemi, opportunità e valori da affrontare. Il proprietario del prodotto cattura questa visione e lavora con uno o più team multidisciplinari per realizzare questa visione. Ecco i ruoli in quel processo.

Utente

I processi agili iniziano sempre con l'utente o il cliente in mente. Oggi, spesso li definiamo con gli utenti personas per illustrare i diversi ruoli in un flusso di lavoro che il software sta supportando o diversi tipi di esigenze e comportamenti dei clienti.

Proprietario del prodotto

Lo stesso processo di sviluppo agile inizia con qualcuno a cui è richiesto di essere la voce del cliente, inclusi eventuali stakeholder interni. Quella persona distilla tutte le intuizioni, idee e feedback per creare una visione del prodotto. Queste visioni del prodotto sono spesso brevi e dirette, ma comunque dipingono un quadro di chi è il cliente, di quali valori ci si rivolge e una strategia su come affrontarli. Posso immaginare che la visione originale di Google fosse qualcosa del tipo "Facciamo in modo che chiunque abbia accesso a Internet possa trovare facilmente siti Web e pagine Web pertinenti con un'interfaccia semplice basata su parole chiave e un algoritmo che classifica le fonti affidabili più in alto nei risultati di ricerca".

Chiamiamo questa persona il proprietario del prodotto . La sua responsabilità è definire questa visione e poi lavorare con un team di sviluppo per realizzarla.

Per lavorare con il team di sviluppo, il proprietario del prodotto scompone la visione del prodotto in una serie di storie utente che spiegano in modo più dettagliato chi è l'utente di destinazione, quale problema viene risolto per lui, perché la soluzione è importante per loro e quali vincoli e criteri di accettazione definiscono la soluzione. Queste storie utente hanno la priorità dal proprietario del prodotto, esaminate dal team per garantire che abbiano una comprensione condivisa di ciò che viene loro chiesto.

Team di sviluppo software

In Agile, le responsabilità del team di sviluppo e dei suoi membri differiscono da quelle dello sviluppo software tradizionale.

I team sono multidisciplinari, composti da un gruppo eterogeneo di persone con le competenze per portare a termine il lavoro. Poiché l'obiettivo è fornire software funzionante, il team deve completare applicazioni funzionanti end-to-end. Quindi il database, la logica aziendale e l'interfaccia utente di una parte dell'applicazione vengono sviluppati e quindi dimostrati, non l'intera applicazione. Per fare ciò, i membri del team devono collaborare. Si incontrano frequentemente per assicurarsi che tutti siano allineati su ciò che stanno costruendo, su chi sta facendo cosa e su come esattamente il software viene sviluppato.

Oltre agli sviluppatori, i team di sviluppo software possono includere ingegneri del controllo qualità (QA), altri ingegneri (ad esempio per database e sistemi back-end), progettisti e analisti, a seconda del tipo di progetto software.

Scrum, Kanban e altri framework agili

Molti framework agili che forniscono specifiche sui processi di sviluppo e pratiche di sviluppo agili, allineati a un ciclo di vita dello sviluppo del software.

Il framework agile più popolare si chiama scrum . Si concentra su una cadenza di consegna chiamata sprint e strutture di riunione che includono quanto segue:

  • Pianificazione - dove vengono identificate le priorità dello sprint
  • Impegno: in cui il team rivede un elenco o un backlog di storie utente e decide quanto lavoro può essere fatto nella durata dello sprint 
  • Riunioni quotidiane in piedi, in modo che i team possano comunicare aggiornamenti sullo stato di sviluppo e sulle strategie)

Gli sprint terminano con una riunione dimostrativa in cui la funzionalità viene mostrata al proprietario del prodotto, seguita da una riunione retrospettiva in cui il team discute cosa è andato bene e cosa deve essere migliorato nel proprio processo.

Molte organizzazioni impiegano master o allenatori di Scrum per aiutare i team a gestire il processo di Scrum.

Sebbene scrum domini, ci sono altri framework agili:

  • Kanban funziona come un processo di fan-in e fan-out in cui il team estrae le storie degli utenti da una scheda di assunzione e le incanala attraverso un processo di sviluppo graduale fino al completamento.
  • Alcune organizzazioni adottano un approccio ibrido agile e a cascata, utilizzando processi agili per le nuove applicazioni e a cascata per quelle legacy.
  • Esistono anche diversi framework per consentire alle organizzazioni di adattare la pratica a più team.

Mentre i framework agili definiscono il processo e la collaborazione, le pratiche di sviluppo agile sono specifiche per affrontare le attività di sviluppo del software eseguite in linea con un framework agile.

Quindi, ad esempio:

  • Alcuni team adottano la programmazione in coppia, in cui due sviluppatori codificano insieme per generare codice di qualità superiore e per consentire agli sviluppatori più esperti di fare da mentore a quelli junior.
  • I team più avanzati adottano lo sviluppo e l'automazione basati sui test per garantire che la funzionalità sottostante fornisca i risultati attesi.
  • Molti team adottano anche standard tecnici in modo che l'interpretazione da parte dello sviluppatore di una user story non porti solo alla funzionalità desiderata, ma soddisfi anche la sicurezza, la qualità del codice, le convenzioni di denominazione e altri standard tecnici.

Perché la metodologia agile è migliore