Tempo di lettura: 4 min
La conoscenza è preziosa, ma il suo vero potere risiede nel modo in cui la mettiamo in pratica. In Freyr Digitale, avevamo familiarità con il DevOps, le sue pratiche associate e il modo in cui avrebbe potuto trasformare la nostra organizzazione in una centrale di sviluppo di prodotti ad alte prestazioni, capace di fornire prodotti e soluzioni di qualità ai nostri clienti delle scienze della vita. All'inizio del nostro percorso, i nostri sforzi hanno gettato solide basi, ma per diventare veramente una centrale di sviluppo, sapevamo di dover adottare un approccio più strategico e adattivo.
La sfida principale nel tradurre la conoscenza in azione consiste nel sapere quando compiere i passi giusti. Poiché le azioni hanno un impatto su molte persone all'interno di un'organizzazione, fare la cosa giusta al momento giusto dipende da dove ci troviamo come organizzazione, dai nostri processi e pratiche attuali e dalle competenze e capacità delle nostre persone.
Ciò ha segnato una svolta nella nostra trasformazione. Come portfolio di fornitori di software specializzati in soluzioni personalizzate, avevamo un team dedicato che faceva il massimo per ottenere risultati. Tuttavia, abbiamo visto l'opportunità di migliorare la qualità, aumentare la produttività e accelerare la conversione dei requisiti aziendali in prodotti consegnabili. Piuttosto che concentrarci su soluzioni dell'ultimo minuto, il nostro obiettivo era passare dalla risoluzione reattiva dei problemi all'innovazione proattiva, costruendo soluzioni scalabili e ad alto impatto.
Avevamo una visione di dove volevamo arrivare: come volevamo lavorare, sviluppare, testare, distribuire e rilasciare il software. Sapevamo tuttavia che il raggiungimento di tali obiettivi richiedeva una strategia ponderata, un apprendimento continuo e un impegno per il miglioramento.
Tornando a oggi: nell'ultimo anno abbiamo effettuato oltre 100 rilasci con errori di distribuzione quasi nulli e abbiamo raggiunto un'automazione quasi totale nell'implementazione delle modifiche. Inoltre, abbiamo registrato progressi significativi nei ricavi, team più snelli e agili e un cambiamento generale verso la nostra visione di diventare un punto di riferimento in termini di prodotti, soluzioni e servizi software. Sebbene ci sia sempre molto da fare, siamo certi di aver gettato solide basi e di essere pronti ad accelerare.
Mentre andiamo avanti, ci prendiamo un momento per riflettere sulla nostra trasformazione: cosa ha funzionato, cosa non ha funzionato e le lezioni imparate. Condividendo il nostro percorso, speriamo di supportare altri che stanno affrontando cambiamenti simili.
Questa serie di blog è prevalentemente empirica: condivide ciò che abbiamo fatto, collegando al contempo le nostre azioni alle migliori pratiche e ai consigli di varie risorse DevOps e Agile.
Fare la cosa giusta al momento giusto
Uno degli aspetti chiave della nostra trasformazione è stato identificare le azioni giuste al momento giusto. Con molteplici iniziative possibili, avevamo bisogno di un approccio strutturato per garantire progressi significativi.
Guardando indietro, possiamo raggruppare queste azioni in tre categorie: Strumenti e processi, Architettura software e Persone. Queste categorie sono fortemente intrecciate e i cambiamenti in una si ripercuotono sulle altre. Tuttavia, è stato possibile apportare modifiche incrementali in ogni categoria e misurare i progressi verso i nostri obiettivi generali.
Le iniziative in queste categorie dipendevano spesso l'una dall'altra. I cambiamenti in un'area aprivano nuove possibilità di miglioramento in un'altra.
I primi passi
Per stabilire solide basi, ci siamo concentrati su tre iniziative principali:
- Integrazione delle nostre basi di codice sorgente con SonarQube per le metriche di qualità del codice.
- Passaggio di tutti i team a uno strumento comune per la gestione dei requisiti, del codice sorgente e dei piani di test: nel nostro caso, Azure DevOps.
- Strutturazione dei team con responsabilità chiare per migliorare il senso di appartenenza e la responsabilità.
Queste tre iniziative ci hanno permesso di verificare:
- Il lavoro svolto (requisiti e attività).
- La qualità del codice (metriche di SonarQube).
- Le persone coinvolte (responsabilità del team).
Tra questi aspetti, definire responsabilità chiare per i team è stato il più complesso. Inizialmente, le strutture dei team erano flessibili e le persone si spostavano tra i progetti secondo necessità. Il passaggio a team dedicati con aree funzionali distinte è stato un passo necessario, sebbene reso complicato dalla nostra architettura di prodotto esistente, che non era stata completamente progettata per supportare una chiara titolarità.
Il ruolo dell'architettura software
Ci siamo resi conto rapidamente che l'architettura del prodotto era una delle aree più critiche da modificare. Un'architettura modulare era essenziale per consentire a team indipendenti di assumersi la responsabilità del proprio lavoro. Senza di essa, i nostri sforzi per creare una titolarità all'interno dei team avrebbero avuto un impatto limitato.
La riprogettazione dell'architettura del nostro portafoglio è stata un processo complesso. Ha incluso il passaggio completo al cloud e l'avvio dello sviluppo di applicazioni cloud-native basate su un'architettura a microservizi. Questo argomento verrà trattato in un articolo futuro. L'aspetto fondamentale, tuttavia, è che i cambiamenti sono incrementali e alcuni passaggi devono precedere altri per sbloccare vantaggi e ulteriori progressi.
Metriche e miglioramento continuo
Dopo aver avviato il lavoro di riprogettazione dell'architettura (un'attività in corso), abbiamo spostato la nostra attenzione sul monitoraggio delle metriche e sulla definizione degli obiettivi:
- Metriche di qualità del codice in SonarQube.
- Metriche di integrazione del codice in Azure DevOps.
- Metriche di produttività delle funzionalità per i singoli team.
- Adozione di servizi cloud-native.
Questi obiettivi non erano rigidi mandati, bensì traguardi di riferimento per aiutare i team ad allineare il proprio lavoro.
Valorizzazione delle persone
Con le metriche a disposizione, è apparso evidente che i team avevano bisogno di supporto per raggiungere questi traguardi. Ad esempio, sebbene fosse semplice fissare obiettivi per la copertura dei test unitari e l'automazione dei test API, raggiungerli risultava complesso, in particolare per il codice legacy che non era stato progettato per essere testabile.
Per affrontare questo aspetto, abbiamo:
- Definito obiettivi inferiori per il codice legacy.
- Organizzato workshop e sessioni pratiche sulla scrittura di unit test di qualità e sulla progettazione di codice testabile.
- Fornito linee guida sulla creazione di stub per il testing delle API.
- Condotto revisioni dei test unitari da parte di architetti senior.
Il triangolo di strumenti, architettura e persone
Un buon esempio dell'interazione tra queste categorie è rappresentato dalla gestione del codice e dei repository. L'integrazione con SonarQube, che costituisce un miglioramento degli strumenti, ha evidenziato una ridotta copertura dei test unitari, mettendo in luce problemi architetturali che limitavano la testabilità. I miglioramenti nell'architettura e nelle competenze del team hanno portato a test unitari di qualità superiore, che tuttavia non venivano eseguiti regolarmente a causa di pratiche di branching inadeguate. Abbiamo risolto il problema standardizzando le strategie di branching e garantendo la regolare integrazione del codice nel branch principale, consentendo alle pipeline CI di eseguire tutti i test.
La giusta sequenza del cambiamento
Un approccio alla trasformazione consiste nell'implementare le best practice senza distinzioni. Sebbene ciò possa comportare dei benefici, spesso i risultati non giustificano lo sforzo, generando frustrazione.
Abbiamo seguito un approccio diverso, basato sul principio del flusso: analizzare il processo end-to-end, identificare i colli di bottiglia e risolverli in modo incrementale.
Ogni miglioramento ha rivelato nuovi colli di bottiglia, richiedendo ulteriori interventi. Non si è trattato di un gioco di "whack-a-mole", bensì di un processo deliberato volto a fare la cosa giusta al momento giusto.
Ad esempio, imporre la copertura dei test unitari senza migliorare la progettazione del codice avrebbe generato frustrazione e una "copertura di facciata" (test superficiali scritti solo per rispettare le metriche). Affrontando prima l'architettura e le competenze, abbiamo garantito progressi significativi.
Prospettive future
La vera trasformazione non si fonda su un unico grande cambiamento, ma su decisioni intelligenti e tempestive che guidano il progresso continuo. Siamo felici di condividere il nostro percorso e le nostre intuizioni per aiutare gli altri a orientarsi nel loro cammino verso un cambiamento scalabile e di grande impatto.
Nei prossimi articoli di questa serie - DevOps per la vittoria, analizzeremo ogni fase della nostra trasformazione nel triangolo DevOps (strumenti, architettura e persone) che ci ha aiutato a ottenere risultati duraturi.
