{"id":24897,"date":"2023-12-11T12:01:36","date_gmt":"2023-12-11T11:01:36","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=24897"},"modified":"2024-01-25T12:25:05","modified_gmt":"2024-01-25T11:25:05","slug":"agile-ed-il-suo-manifesto-quanto-sono-ancora-rilevanti-nel-2024","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/devops-it\/agile-ed-il-suo-manifesto-quanto-sono-ancora-rilevanti-nel-2024\/","title":{"rendered":"Agile ed il suo Manifesto: quanto sono ancora rilevanti nel 2024?"},"content":{"rendered":"\n

L’Agile Manifesto \u00e8 stato redatto nel 2001 da alcune tra le pi\u00f9 grandi personalit\u00e0 dello sviluppo software. Da allora, la community Agile cerca di diffondere e sostenere le migliori pratiche conosciute, vecchie ed emergenti, sotto il cappello di pratiche e metodologie Agili.<\/p>\n\n\n\n

Ad una manciata di anni dal quarto di secolo, una domanda legittima, forse, ha fatto capolino di recente online: ma oggi, dopo tutti questi anni, l’Agile \u00e8 ancora cos\u00ec rilevante<\/strong>?<\/p>\n\n\n\n

Con l’evoluzione delle tecnologie e delle pratiche e metodologie a nostra disposizione, i nuovi linguaggi, il cloud, e tutto quello che di nuovo \u00e8 arrivato negli ultimi 20 anni, \u00e8 davvero ancora cos\u00ec importante parlare di Agile?<\/p>\n\n\n\n

Ma cos’\u00e8 questo Agile<\/h2>\n\n\n\n

Per poter riflettere su quanto sia ancora rilevante parlare di Agile nel 2024, \u00e8 doveroso ricapitolarne velocemente i valori e principi, rendendo anche evidente la correlazione con altre metodologie – questo perch\u00e8 sono sicuro che tutti avrete sentito parlare di Agile in qualche forma, ma purtroppo molti fraintendimenti si sono diffusi nelle implementazioni pi\u00f9 comuni.<\/p>\n\n\n\n

Il nome “Agile” nasce nel 2001 con la redazione e firma del Manifesto<\/a>, nel quale troviamo una dichiarazione di intenti e i 12 principi Agili. Tra le metodologie Agili pi\u00f9 conosciute ci sono sicuramente Scrum e Kanban<\/strong>, con il primo che negli ultimi anni \u00e8 diventato enorme fonte di discussione a causa proprio di tante interpretazioni non proprio coerenti, volte sopratutto a rendere il tutto pi\u00f9 digeribile ai contesti corporate.<\/p>\n\n\n\n

Chiunque abbia avuto la fortuna, o la perseveranza, di incontrare davvero l’Agile in qualunque forma, riconoscer\u00e0 subito che tante delle singole best practice che negli ultimi anni si sono diffuse e hanno guadagnato una buona nomea nel nostro settore non posso che derivare da quella radice – e viceversa, in alcuni casi.<\/p>\n\n\n\n

Alcuni esempi? Eccoli!<\/p>\n\n\n\n

I punti in comune tra eXtreme Programming ed Agile sono evidenti e quasi banali, probabilmente: per esempio, l’autore di XP \u00e8 fra i firmatari del Manifesto, non a caso – ed includere XP significa anche includere altre pratiche facilmente riconducibili ad XP stesso, come il TDD, gli OKR (quarter cycle) o il planning (weekly cycle), evidentemente molto simile agli Sprint di Scrum. Allo stesso modo, anche il Lean \u00e8 sicuramente riconducibile a moltissimi principi in comune, e di conseguenza l’approccio DevOps che ad esso si ispira, come la collaborazione stretta figure che spesso si considerano parti successive di un processo (Development e Ops, ma anche Testers, Product Management, etc) che \u00e8 un ottima espressione di individuals and interactions over processes and tools<\/em>. <\/p>\n\n\n\n

Se pensiamo alle pratiche, la Continuous Delivery \u00e8 espressamente citata dal Manifesto, e di conseguenza possiamo contare anche Continuous Integration e Trunk-Based Development; appare piuttosto evidente, infine, come i team cross-funzionali siano l’implementazione principale che rende i team “self-organized”.<\/p>\n\n\n\n

E la lista potrebbe proseguire ancora per molto! Ritengo che le pratiche che rientrano in questo gruppo siano sostanzialmente tutte parte di un circolo vizioso positivo, alimentandosi ed abilitandosi l’una con l’altra.<\/p>\n\n\n\n

Ma quindi vale ancora la pena parlare di Agile nel 2024?<\/h2>\n\n\n\n

Risposta breve? Si. Certo che si! Anzi, il tempo ha sicuramente aiutato a diffondere certi concetti, e le nuove tecnologie piuttosto che rendere inutile la filosofia Agile la potenziano.<\/p>\n\n\n\n

Pensateci, oggi i computer sono velocissimi, i linguaggi di programmazione sono tutti molto pi\u00f9 “dev friendly”, e poi tutti hanno a disposizione almeno uno smartphone in mano, la tecnologia \u00e8 diventata davvero popolare nel senso pi\u00f9 stretto del termine: considerando questo, possiamo riflettere sul fatto che qualche anno avere processi di sviluppo molto lunghi era considerato ragionevole perch\u00e8 le tempistiche lunghe dovute a cattive pratiche nello sviluppo software erano accompagnate, ed in parte mascherate, da tempi altrettanto lunghi per poter anche solo compilare e testare il nostro codice. <\/p>\n\n\n\n

Oggi, quando parliamo di Continuous Delivery, possiamo mirare ad avere realmente almeno una release al giorno senza patemi: la tecnologia per farlo \u00e8 alla portata di qualunque team di sviluppo, sul cloud, senza necessit\u00e0 di configurare tutto in-house se non per una scelta specifica.<\/p>\n\n\n\n

Un esempio lampante di quanto sia attuale parlare di Agile, Lean, ed XP ce lo da il libro Accelerate nel 2018: un libro basato su una ricerca che va a dimostrare, anno dopo anno, come le pratiche e le metodologie Agili abbiano un impatto enormemente positivo non solo sul team di sviluppo, ma anche e sopratutto sul successo aziendale – ed ogni anno la ricerca viene portata avanti ed aggiornata con l’annuale State Of DevOps Report, andando sempre pi\u00f9 in profondit\u00e0 sull’argomento.<\/p>\n\n\n\n

Fondamentale rimane anche continuare a parlarne e a diffonderne i valori, i principi e le pratiche tecniche che permettono ai team di diventare performanti: ci ritorneremo nei prossimi articoli di questa serie, ma \u00e8 fondamentale capire che un organizzazione non pu\u00f2 essere Agile se il team di sviluppo non mette in pratica le pratiche e metodologie Agile – in questo senso, grazie ad esse la tecnologia pu\u00f2 abilitare l’azienda ad avere un maggiore successo e rispondere in modo pi\u00f9 efficace alle esigenze del mercato e dei clienti.<\/p>\n\n\n\n

Ma tanto ora arriva l’AI<\/h2>\n\n\n\n

Un altro elemento importante da mettere sul tavolo, che potrebbe generare qualche malinteso, \u00e8 l’avvento dell’Intelligenza Artificiale<\/a>, ma anche dei tool di Low\/No-Code.<\/p>\n\n\n\n

Nessuno di noi pu\u00f2 sapere con certezza dove ci porteranno, anche se ovviamente io stesso ho una mia idea; la potenzialit\u00e0 piu grossa che vedo a livello di sviluppo software \u00e8 quella di una IA che sia in grado di scrivere, mantenere e rifattorizzare a comando una codebase intera di un progetto. Qualcuno potrebbe pensare che questo tolga la necessit\u00e0 dei test automatici, in fondo li scriviamo sopratutto per assicurarci di non rompere il codice esistente con le future modifiche, e dato che si occupa di tutto l’IA… ma io non concordo.<\/p>\n\n\n\n

Mi immagino, invece, di fare “TDD con l’IA” – ovvero scrivere codice in TDD, io scrivo i test e l’IA aggiorna la codebase per soddisfare il nuovo test e tutti quelli pre-esistenti – qualcosa di simile si pu\u00f2 gi\u00e0 fare su una singola classe, e sono sicuro sar\u00e0 possibile farlo su un intera codebase in futuro.<\/p>\n\n\n\n

Quest’esempio serve a spiegare il mio punto: ci sono aspetti della programmazione, anche piuttosto complicati, che sono dovuti al fatto che \u00e8 molto difficile non tanto scrivere la prima versione di un software, ma mantenerlo nel tempo tenendo i costi del cambiamento sotto controllo. Se l’IA diventasse in grado di gestire lei la codebase, potremmo per esempio dimenticarci dei principi di Clean Code e Design Patterns – l’unica cosa che conta \u00e8 che quel codice faccia quel che serve al business, il design non dovr\u00e0 pi\u00f9 essere ottimizzato per la leggibilit\u00e0 e la manutenibilit\u00e0, ma solo, quando richiesto, per eventuali performance migliori. Per questo vorrei continuare a scrivere io i test automatici, per garantirmi quel livello di controllo che mi faccia dire “il codice fa quel che serve”. <\/p>\n\n\n\n

\u00c8 un piccolo esempio per dimostrare come secondo me le pratiche Agili rimarranno fondamentali: se fare TDD pu\u00f2 darci controllo sul comportamento del codice, se faremo manutenzione solo dei test sar\u00e0 quello il nostro focus lavorando in pair\/mob, con gli stessi benefici attuali di condivisione conoscenze e review in tempo reale; essere in grado di fare CI rimarr\u00e0 fondamentale per poter rilasciare in meno tempo possibile un MVP della nostra feature e capire se funziona, semplicemente il tempo richiesto sar\u00e0 sempre meno perch\u00e8 molti pi\u00f9 elementi saranno automatizzati.<\/p>\n\n\n\n

Per concludere, insomma, la risposta mi sembra evidente: si, l’Agile, il Manifesto, Lean, XP – tutte queste metodologie intrecciate tra loro continueranno ad essere di valore, ed anzi paradossalmente potranno aumentare il loro valore perch\u00e8 impattanti su tutta quella parte di lavoro dove l’IA avr\u00e0 impatto minore perch\u00e8 il contesto, gli obiettivi aziendali, la conoscenza del dominio e delle specificit\u00e0 del caso sono importantissimi – e in un mondo in cui gli aspetti puramente tecnici si appiattiranno un p\u00f2 grazie a queste automazioni, saranno pratiche e metodologie di lavoro gli elementi su cui potremo avere maggiore impatto e fare davvero la differenza.<\/p>\n\n\n\n

\n\n\n\n
Ciao, sono Dan the Dev! <\/pre>\n\n\n\n
Se questo articolo ti \u00e8 piaciuto, sappi che \u00e8 solo il primo di una serie di articoli mensili a tema Agile che cominciano proprio da questo, quindi preparati perch\u00e8 nel 2024, ogni mese, porter\u00f2 i temi dell'agilit\u00e0! Dai anche un occhiata a Learn Agile Practices, il mio ecosistema di contenuti online nei quali parlo di pratiche e metodologie Agile come TDD, CI, CD e molto altro a tema programmazione:<\/pre>\n\n\n\n