L’Agile, se lo si vuole adottare appieno, ha un impatto profondo e molto ampio, che non si limita a toccare la sola Direzione IT. La Direzione IT è però senz’altro la prima a dover ripensare le proprie logiche di funzionamento. L’Agile, se lo si vuole adottare appieno, ha un impatto profondo e molto ampio, che non si limita a toccare la sola Direzione IT.
Se vuoi approfondire ancora di più, puoi leggere anche I 12 motivi per cui l'Agile è importante.
A livello di competenze occorre integrare e sviluppare i nuovi ruoli; occorre inoltre evitare la tendenza a sviluppare competenze tecniche specialistiche, cosa che ostacola la collaborazione, prediligendo uno spettro di competenze più ampio.
Per realizzare software di qualità non ci si può però fermare solo a pratiche organizzative, ma occorre entrare nel lavoro degli sviluppatori.
L’Agile mira all’eccellenza tecnica e quindi si accompagna con tecniche di sviluppo avanzate, quali l’Extreme Programming, che fa leva ad esempio su tecniche di pair programming (programmazione in coppia) e sulla test automation.
Fondamentale diventa il concetto di continuous integration, per poter avere sempre un software funzionante e completo in tutte le sue parti, garantendo che le parti di codice scritte da diversi membri del team funzionino insieme senza errori, grazie anche alle pratiche di Test Driven Development (TDD), dove i test automatici vengono realizzati prima della scrittura del codice, permettendo di verificare in maniera automatica e frequente il corretto funzionamento del sistema.
L’attenzione posta alla rapidità nel rilasciare software funzionante all’interno dei team Agile si scontra però spesso con il passaggio in esercizio delle applicazioni realizzate, cosa fondamentale se si vogliono fare rilasci frequenti di modo da avere più feedback possibili.
Nelle Direzioni IT i team di Operations, incaricati di gestire con sicurezza il passaggio in produzione delle applicazioni, hanno però spesso cultura e obiettivi molto differenti.
Lontani dagli obiettivi di business e dal ritmo dei team di sviluppo, vedono le attività come una sequenza di task principalmente manuali che devono essere realizzati in apposite finestre temporali per minimizzare il rischio di disservizi. In questa situazione, pur applicando la metodologia Agile, un’azienda può essere estremamente lenta, in grado di fare pochi rilasci all’anno dei propri software.
Per risolvere questa problematica si è sviluppato negli scorsi anni il concetto di DevOps: una serie di pratiche e metodologie per unire la parte di sviluppo applicativo con quella di messa in esercizio eleminando le barriere fra questi due mondi e permettendo un passaggio fluido e rapido delle applicazioni in esercizio.
L’elemento chiave del DevOps è l’automazione dei diversi passaggi, di modo da renderli replicabili e a basso contenuto di attività umane. Grazie a queste modalità è possibile passare a rilasci estremamente frequenti, anche più volte al giorno, in maniera sicura, permettendo di scaricare a terra le potenzialità dell’Agile.
L’altro elemento che spesso è bloccante per l’Agile è il ricorso a fornitori esterni per le attività operative di sviluppo, cosa sempre più frequente oggigiorno e figlia di un processo di delocalizzazione spinto da una lotta per la riduzione dei costi IT.
Con le tradizionali modalità contrattuali e i tradizionali processi di acquisto, un’azienda si trova vincolata e difficilmente potrà essere sufficientemente flessibile.
Solitamente infatti i processi di acquisto sono lunghi e burocratici, con logiche di contrattazione orientate al minor costo e basate su contratti a corpo, che hanno scope definito fin dall’inizio ed elevata rigidità per spostare il rischio sui fornitori.
In questa situazione ci vuole molto tempo per partire con le attività di sviluppo, i fornitori sono vincolati e non possono assecondare, se non per eccezione, i cambiamenti di specifica.
Anche qui occorre intervenire in maniera decisa: è innanzitutto un problema culturale: le persone del procurement devono uscire da un approccio rigido e burocratico e abbracciare gli obiettivi finali di business connessi ad ogni progetto. Nascono allora obiettivi diversi per le persone del procurement, nuove forme contrattuali che privilegiano il time & material o forme analoghe, processi che consentono di partire velocemente garantendo però la possibilità di interrompere le collaborazioni con facilità nel caso ci siano problemi.
Il punto chiave è instaurare con i fornitori relazioni di partnership, le uniche che permettano di investire congiuntamente per sviluppare nuove modalità di lavoro e di uscire da un approccio negoziale che porta le due parti, inevitabilmente, a tirare in direzioni opposte.
Risolto anche questo problema, l’Agile permette di sviluppare meglio il software, in maniera più efficiente e flessibile, ma rischia di essere solo una ottimizzazione locale se rimane confinato nella Direzione IT. Purtroppo, questo accade oggi molto spesso: la Direzione IT preferisce seguire una via esclusivamente interna, senz’altro più comoda. Non affronta la sfida più importante e difficile: il cambiamento delle relazioni e del ruolo delle Line of Business.
È qui che l’Agile smette di essere solo un sistema di software development e diventa un sistema per la gestione dei progetti di trasformazione digitale. Coinvolgere il business vuol dire:
Il tutto tenendo a mente che non esiste un punto di arrivo, ma solo un percorso di esplorazione e di evoluzione che non può fermarsi, perché è il mondo là fuori, dove competiamo, che non si ferma mai.
Facci sapere se vuoi approfondimenti su questo tema
Seguici sui nostri canali social per essere sempre aggiornato sulle novità di Nards IT
Instagram: @nards_it
Facebook: nards.it
TikTok: @nards.it
