Agile e DevOps sono tra le metodologie più accreditate per disegnare e rilasciare software in modo rapido ed efficiente, doti di cui le imprese hanno bisogno per essere più competitive nella creazione e aggiornamento di soluzioni e processi digitalizzati. Metodologie (che più propriamente dovremmo definire approcci) che sono efficaci per eliminare le rigidità nelle filiere dello sviluppo e della gestione IT, ma attorno alle quali c’è oggi molto fumo e un mercato di prodotti e di qualifiche professionali poco trasparente. Come risultato, molte aziende che hanno puntato su Agile e DevOps per modernizzare i loro processi falliscono nel cercare di ottenere i risultati attesi.
Cosa è lecito attendersi dall’introduzione di Agile e DevOps? Come si realizza un cambiamento che, prima della tecnologia, riguarda il lavoro delle persone? Abbiamo posto queste domande a Paolo Pustorino, co-founder e head of HR di SparkFabrik, società specializzata nella progettazione, sviluppo e gestione di software cloud-native.
Indice degli argomenti
Cosa NON sono Agile e DevOps
Agile e DevOps non sono prodotti o soluzioni. “Offrirle come tali è una semplificazione del mercato – spiega Pustorino – creata su misura di CEO e alti dirigenti che hanno poco tempo e non possono permettersi di osservare nel dettaglio argomenti quali le modalità produttive, i processi di filiera e le ottimizzazioni. Questo ha favorito la creazione di un mercato di etichette che mette in secondo piano il nocciolo della questione: il cambiamento che Agile e DevOps introducono nel lavoro delle persone”.
Agile e DevOps sono approcci che nascono “dal basso” per risolvere i problemi della filiera digitale e produrre i benefici che il business si attende; non qualcosa che è possibile comprare. “Sbaglia la grande azienda che paga dieci certificazioni, assume tre Scrum Master e adotta il framework Scrum perché è famoso, e un dirigente ha letto il titolo del libro di Jeff Sutherland (L’arte di fare il doppio del lavoro in metà tempo. Puntare al successo con il metodo Scrum – ndr). In questo modo si insegue una chimera e si affaticano inutilmente le persone”.
Agile è in estrema sintesi una codifica metodologica del buon senso: “Se si fa un prodotto nuovo è meglio non attendere sei mesi per scoprire al rilascio che non fa ciò che serve. Come nel lavoro di un sarto, serve fare più prove con i modelli sempre più raffinati dell’abito per eliminare i difetti prima che sia troppo tardi”. Spesso le certificazioni e l’impiego di prodotti blasonati sono una foglia di fico per nascondere le responsabilità in merito a cambiamenti che non si sono fatti o non si vogliono fare. Una copertura quando i risultati non sono quelli attesi: “Ma non si tratta di una posizione consapevole. Sono i sistemi sociali consolidati che tendono a preservare se stessi e i propri processi”, chiosa Pustorino.
Fissare le giuste aspettative e preparare il cambiamento
Agile, Devops devono essere valutati sulla base dell’insieme di benefici che possono dare all’azienda e non sulla base delle promesse di produttività o di riduzione costi. “È come per il cloud – spiega Pustorino – per un caso in cui si ottiene una riduzione dei costi dell’80% perché l’IT interna era fuori controllo, ce ne sono altri in cui i costi segnano un aumento. A fronte di questo, ci sono anche dei benefici: l’azienda ha potuto ottimizzare le risorse, scalarle in modo da non rallentare con i picchi d’utilizzo, si è garantita l’always-on e può sperimentare le nuove soluzioni digitali senza investimenti hardware”.
Agile e DevOps funzionano bene quando sono integrati in tutta l’azienda, e non servono soltanto a ottimizzare il lavoro di un team IT. “È inutile implementare tecniche di CI/CD (continuous integration/delivery, che fanno parte di DevOps)” se poi l’azienda fa i rilasci di software solo due volte all’anno, accumulando il lavoro”. Serve avere coraggio nell’attuare il cambiamento e abbracciare in profondità i nuovi metodi, adottando il giusto mindset e introducendo nuovi valori.
Non è comunque un approccio adatto dappertutto. “Parole come ‘coraggio’ e ‘sperimentazione’ assumono implicazioni ben differenti se oggetto dello sviluppo è un nuovo social media o il software di pilotaggio di un aereo – precisa Pustorino – e non sempre è sensato rilasciare sul mercato prodotti in eterno divenire. È necessaria un po’ di esperienza per comprendere quali approcci funzionino meglio in determinati contesti e come integrarli progressivamente nel proprio.” Ciò che conta è la capacità dell’Agile di ridurre le frizioni nel lavoro e migliorare la comunicazione tra le persone: “I processi innovativi sono per loro natura non meccanizzabili, per questo le persone sono importanti. Non a caso il Manifesto Agile mette in primo piano le persone. Se i processi sono calati dall’alto non funzionano, le persone li aggirano e trovano le proprie strade di minor resistenza, i propri processi ombra”.
Nelle realtà che fanno sviluppo e operation IT, il DevOps porta molti benefici, primo tra tutti riduce i costi delle delivery. “All’atto pratico richiede molto impegno nel cambiamento. Per questo è importante capire in fase preliminare se aiuta davvero l’azienda”. Incorporando i concetti dell’Agile, DevOps consente di focalizzare le risorse, il tempo e la creatività su ciò che porta più valore nel business. “Se c’è un problema di time-to-market, va identificata la causa. A volte il software non c’entra. L’azienda è lenta perché vuole andare in produzione con soluzioni troppo grandi e complicate con la falsa convinzione che solo così potrà avere successo. E il fallimento è causato dal target sbagliato o dalle ricerche di mercato incomplete”.
In sintesi: cosa attendersi da Agile e DevOps
Adottare Agile e DevOps non dev’essere visto come un obiettivo, “ma come un mezzo per raggiungere gli obiettivi aziendali” spiega Pustorino. “Un modo per chiarire che cosa l’azienda vuol fare, rendere i processi più trasparenti ed efficienti e, quando le cose non vanno per il verso giusto, capirlo quanto prima possibile e sperimentare nuove modalità risolutive”.
Nell’introduzione di Agile e DevOps è importante non avere l’aspettativa di benefici immediati a fronte degli investimenti fatti in consulenza, certificazioni e soluzioni. All’inizio, in genere, i costi aumentano. Solo in seguito, si apprezzano i vantaggi della trasparenza sui processi e poi, gradualmente, gli aumenti d’efficienza e d’efficacia dei risultati nella filiera di produzione.
Per non sbagliare le scelte e fissare le aspettative in modo corretto, serve acquisire un livello minimo di conoscenza. Per quanto riguarda l’Agile: “I decision maker beneficerebbero molto di un corso base anche solo di un paio di giorni tra i tanti che il mercato offre, come quelli, per esempio, di formatori accreditati Scrum Alliance o della Kanban University. Questo li aiuterebbe a comprendere l’argomento, prima di procedere nelle loro scelte”.
In particolare, è importante non sottovalutare gli impatti sulle persone, sia a livello dirigenziale sia, più in basso, nei team di sviluppo e IT. Nel cambiamento c’è chi vedrà riduzioni delle mansioni, peraltro rimpiazzate da compiti più qualificati e spendibili sul mercato del lavoro. “La trasparenza del lavoro e le scadenze ravvicinate possono creare inizialmente tensioni. Per questo l’introduzione di Agile e di DevOps si avvantaggia del coinvolgimento dei responsabili delle risorse umane, per rendere più semplici i cambiamenti dei rapporti”, conclude Pustorino.
