Come tenere sotto controllo la proliferazione del software

All'inizio i sintomi della diffusione incontrollata del software possono essere difficili da riconoscere. A volte iniziano come piccoli intoppi che vengono messi da parte per dare priorità ad aspetti più cruciali. Tuttavia, se non gestita, la diffusione incontrollata del software può paralizzare i team di sviluppo con un livello di elaborazione più elevato, ridurre il coinvolgimento dei team e annullare i vantaggi associati a un'architettura in cui i servizi sono piuttosto indipendenti tra loro. Come si dice nel proverbio, "Il momento migliore per piantare un albero era 20 anni fa. Il secondo momento migliore è adesso". Il successo nel futuro dipende dalla capacità di gestire al meglio la proliferazione del software prima che diventi un problema.

Di seguito sono riportati tre segnali della proliferazione di software e viene spiegato cosa si può fare per dominare il caos creando al contempo un ambiente innovativo e dinamico che accresca il potenziale di ogni team.

Uno dei primi sintomi della proliferazione di software sono le molteplici recensioni post-imprevisto (PIR) che indicano le modifiche upstream come causa principale degli imprevisti. Un numero crescente di microservizi e un volume maggiore di modifiche all'interno di un ambiente possono mettere a dura prova le norme esistenti in materia di collaborazione tra sviluppatori e coordinamento delle modifiche. Anche un leggero aumento (da mensile a settimanale) della frequenza delle modifiche apportate a un'applicazione modernizzata può comportare un aumento per 100 volte dei rilasci mensili. Non sorprende che sia necessario per gli sviluppatori adattare le modalità di collaborazione. È più probabile che si verifichino imprevisti nell'ambiente di produzione quando le norme di collaborazione tra gli sviluppatori non riescono ad adeguarsi a un ambiente caratterizzato da ritmi frenetici.

Creare un modo non intrusivo per fare in modo che gli sviluppatori siano al corrente delle modifiche upstream e downstream è un'ottima soluzione per arginare l'impatto della proliferazione di software. In Atlassian, utilizziamo Compass, un portale per sviluppatori che aiuta i team a spostarsi nelle architetture distribuite, per inviare notifiche in-app ai team di sviluppo sulle modifiche che causano interruzioni ai servizi upstream e downstream. Prendendo atto di queste notifiche, si segnala al promotore della modifica che i team responsabili dei servizi dipendenti ne sono a conoscenza. Ciò offre l'opportunità di collaborare alla modifica se si prevedono problemi, riducendo la probabilità di conseguenze negative involontarie sulla produzione. Poiché gli imprevisti sono destinati a verificarsi negli ambienti dinamici, la collaborazione tra sviluppatori durante un imprevisto è fondamentale per ripristinare rapidamente i servizi.

Nelle revisioni post-imprevisto in cui le modifiche upstream sono la causa principale, è comune che il tempo di ripristino dei servizi dipenda dal tempo impiegato per identificare la modifica upstream che ha causato il problema, insieme al team o alla persona responsabile del servizio. Logicamente, la riduzione del tempo necessario per identificare la modifica upstream incriminata comporta la riduzione del tempo medio di ripristino (MTTR) nel corso del tempo. Ciò è reso più difficile in un'architettura debolmente accoppiata, in cui i servizi presentano una gerarchia di dipendenze complessa e la causa principale di un imprevisto potrebbe risiedere ovunque nello stack. Tradizionalmente, gli addetti agli imprevisti esaminano i log o i record delle modifiche per identificare la modifica che potrebbe aver causato l'imprevisto. Nel caso degli ambienti dinamici, è come distruggere un formicaio per trovare la formica che ci ha morso.

In Atlassian utilizziamo il feed attività di Compass per ridurre l'MTTR. Questo feed mostra tutti gli eventi relativi ai sistemi upstream insieme ai dettagli del team responsabile. Questo riduce significativamente i tempi di valutazione supportando la collaborazione tra sviluppatori durante gli imprevisti. Gli imprevisti si verificheranno, ma identificare tempestivamente una modifica upstream come causa principale di un imprevisto è fondamentale per assicurarsi che l'impatto sia ridotto al minimo e che i servizi vengano ripristinati rapidamente.

Il passaggio a un'architettura debolmente accoppiata è uno degli ingredienti chiave per raggiungere la produttività e la soddisfazione del team: la possibilità di muoversi in modo indipendente con alti livelli di autonomia. Se non controllata, la proliferazione di software può annullare alcuni di questi vantaggi, impegnando molto il team, ma trasformandolo in un team improduttivo e insoddisfatto. Una lamentela comune che emerge quando si parla con i team di sviluppo è che i problemi sorgono quando arriva il momento di interagire con un altro team. E questo concetto si amplifica quando la proliferazione di software diventa un problema. In un ambiente caratterizzato da espansione e cambiamento rapidi, la capacità degli sviluppatori di tenere traccia delle persone da contattare per le dipendenze upstream o downstream è ridotta, con conseguenti rallentamenti e un aumento della frustrazione dei team che cercano di tenere il passo con il ritmo delle distribuzioni.

Supponiamo, ipoteticamente, che la squadra Alpha e la squadra Beta abbiano un numero identico di ticket e che gli Story Point vengano spostati nello stato "Completato" in Jira ogni settimana. La squadra Alpha dedica il 90 percento del lavoro al rilascio di nuove funzioni nell'ambiente di produzione, mentre la squadra Beta dedica il 30 percento del lavoro a nuove funzioni e il 70 percento a capire come interagire con i numerosi servizi upstream da cui dipende. Entrambe le squadre hanno lo stesso livello di rendimento, ma è probabile che solo la squadra Alpha sia considerata produttiva. La proliferazione di software amplifica la necessità di collaborazione tra i team. Individuare modi intelligenti per consentire ai team autonomi di interagire quando serve è fondamentale per sfruttare la potenza di un ambiente debolmente accoppiato.

In un ambiente dinamico e in rapida crescita, la capacità di gestire le informazioni in modo autonomo è importante per la produttività e la soddisfazione del team. Un modo per raggiungere questo obiettivo è implementare un catalogo centralizzato di componenti software con gestione decentralizzata; si tratta di un catalogo centralizzato in cui ogni team è responsabile della creazione e dell'aggiornamento dei servizi di cui è responsabile. Gli ambienti tradizionali dispongono in genere di un catalogo centralizzato gestito da un team o da una funzione specifici. Tuttavia, questo approccio non può tenere il passo con la velocità delle modifiche negli ambienti distribuiti, con il risultato che i team creano wiki poco chiari sulle persone con cui interagire e sulle modalità di interazione. In Atlassian, abbiamo scoperto che un approccio decentralizzato riduce il lavoro invisibile e non necessario tra i team, migliora le funzionalità self-service e crea un ambiente di coinvolgimento su richiesta. Controllare la proliferazione di software rendendo disponibili informazioni self-service sulle dipendenze upstream e downstream è un ottimo modo per migliorare la produttività del team con effetti complementari sulla loro soddisfazione e sul loro coinvolgimento.