,
4 minuti di lettura
La conoscenza è preziosa, ma il suo vero potere risiede nel modo in cui la mettiamo in pratica. In Freyr Digitale, conoscevamo DevOps, le sue pratiche associate e come potesse trasformare la nostra organizzazione in una potenza nello sviluppo di prodotti ad alte prestazioni, capace di fornire prodotti e soluzioni di qualità ai nostri clienti nel settore delle scienze della vita. Mentre iniziavamo il nostro percorso, i nostri sforzi hanno gettato solide basi, ma per diventare veramente una potenza nello sviluppo, sapevamo di dover adottare un approccio più strategico e adattivo.
La sfida principale nel tradurre la conoscenza in azione risiede nel sapere quando intraprendere i passi giusti. Poiché le azioni influiscono su molte persone in 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.
Questo ha segnato un punto di svolta nella nostra trasformazione. Come portafoglio di fornitori di software specializzati in soluzioni personalizzate, avevamo un team dedicato che si impegnava al massimo per ottenere risultati. Tuttavia, abbiamo visto l'opportunità di migliorare la qualità, aumentare la produttività e accelerare la conversione dei requisiti aziendali in risultati. Invece di concentrarci su soluzioni dell'ultimo minuto, miravamo a passare dalla risoluzione reattiva dei problemi all'innovazione proattiva, costruendo soluzioni scalabili e di grande impatto.
Avevamo una visione di dove volevamo essere – come volevamo lavorare, sviluppare, testare, implementare e rilasciare software. Tuttavia, sapevamo che il raggiungimento di tali obiettivi richiedeva una strategia ponderata, un apprendimento continuo e un impegno al miglioramento.
Oggi: nell'ultimo anno, abbiamo effettuato oltre 100 rilasci con quasi zero errori di implementazione e abbiamo raggiunto un'automazione quasi completa nell'introduzione delle modifiche. Inoltre, abbiamo registrato progressi significativi nei ricavi, team più snelli e agili e un cambiamento complessivo verso la nostra visione di diventare un punto di riferimento nei prodotti, soluzioni e servizi software. Anche se c'è sempre di più da raggiungere, siamo fiduciosi di aver gettato solide basi e siamo pronti ad accelerare.
Mentre andiamo avanti, ci prendiamo un momento per riflettere sulla nostra trasformazione: cosa ha funzionato, cosa no e le lezioni che abbiamo imparato. Condividendo il nostro percorso, speriamo di supportare altri che affrontano cambiamenti simili.
Questa serie di blog è principalmente empirica, condividendo ciò che abbiamo fatto e collegando le nostre azioni alle migliori pratiche e raccomandazioni provenienti da 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 strettamente interconnesse, con i cambiamenti in una che influenzano le altre. Tuttavia, è stato possibile apportare modifiche incrementali in ciascuna categoria e misurare i progressi verso i nostri obiettivi generali.
Le iniziative in queste categorie spesso dipendevano l'una dall'altra. I cambiamenti in un'area aprivano possibilità per ulteriori miglioramenti in un'altra.
I Primi Passi
Per gettare solide basi, ci siamo concentrati su tre iniziative principali:
- Integrare le nostre basi di codice sorgente con SonarQube per le metriche di qualità del codice.
- Spostare tutti i team su uno strumento comune per la gestione dei requisiti, del codice sorgente e dei piani di test – nel nostro caso, Azure DevOps.
- Strutturare i team con responsabilità chiare per migliorare l'ownership e la responsabilità.
Queste tre iniziative ci hanno dato visibilità su:
- Il lavoro svolto (requisiti e attività).
- La qualità del codice (metriche SonarQube).
- Le persone coinvolte (responsabilità del team).
Tra questi, definire chiare responsabilità del team è stata la sfida maggiore. Inizialmente, le strutture dei team erano fluide, con persone che si spostavano tra i progetti secondo necessità. Il passaggio a team dedicati con aree funzionali distinte è stato un passo necessario, sebbene complicato dalla nostra architettura di prodotto esistente, che non era stata completamente progettata per supportare una chiara attribuzione di responsabilità.
Il Ruolo dell'Architettura Software
Ci siamo subito resi conto che l'architettura del prodotto era una delle aree più critiche per il cambiamento. Un'architettura modulare era essenziale per consentire ai team indipendenti di assumersi la responsabilità del proprio lavoro. Senza di essa, i nostri sforzi per creare un senso di responsabilità nel team avevano un impatto limitato.
La riorganizzazione del nostro portfolio è stata un processo complesso. Ha incluso il passaggio completo al cloud e l'inizio della creazione di applicazioni cloud-native utilizzando un'architettura a microservizi. Questo argomento sarà trattato in un post futuro. Il punto chiave, tuttavia, è che i cambiamenti sono incrementali e alcuni passaggi devono precederne altri per sbloccare benefici e ulteriori progressi.
Metriche e miglioramento continuo
Dopo aver iniziato i lavori di riarchitettura (un'attività in corso), abbiamo spostato la nostra attenzione su il monitoraggio delle metriche e la definizione degli obiettivi:
- Metriche di qualità del codice in SonarQube.
- Metriche di integrazione del codice in Azure DevOps.
- Metriche di rendimento delle funzionalità per i singoli team.
- Adozione di servizi cloud-native.
Questi obiettivi non erano mandati rigidi, ma obiettivi guida per aiutare i team ad allineare i loro sforzi.
Valorizzare le persone
Con le metriche in atto, è diventato evidente che i team avevano bisogno di supporto per raggiungere questi obiettivi. Ad esempio, mentre stabilire obiettivi per la copertura dei test unitari e l'automazione dei test API era semplice, raggiungerli era impegnativo, specialmente per il codice legacy che non era stato progettato per la testabilità.
Per affrontare questo, abbiamo:
- Stabilire obiettivi inferiori per il codice legacy.
- Organizzato workshop e formazione pratica sulla scrittura di test unitari di qualità e sulla progettazione di codice testabile.
- Fornita guida sulla creazione di stub per il testing delle API.
- Revisioni dei test unitari effettuate da architetti senior.
Il Triangolo Strumenti, Architettura e Persone
Un buon esempio dell'interazione tra queste categorie è stata la gestione del codice e del repository. L'integrazione con SonarQube, che ha rappresentato un miglioramento negli strumenti, ha rivelato una bassa copertura dei test unitari, indicando problemi architetturali che limitavano la testabilità. I miglioramenti nell'architettura e nelle competenze del team hanno portato a test unitari di migliore qualità, ma questi non venivano eseguiti regolarmente a causa di pratiche di branching inadeguate. Abbiamo risolto questo problema standardizzando le strategie di branching e garantendo l'integrazione regolare del codice nel ramo principale, permettendo alle pipeline di CI di eseguire tutti i test.
La giusta sequenza del cambiamento
Un approccio alla trasformazione è implementare indiscriminatamente le migliori pratiche. Sebbene ciò possa portare benefici, i risultati spesso non giustificano lo sforzo, portando alla frustrazione.
Abbiamo seguito un approccio diverso, basato sul principio del flusso: analizzare il processo End-to-End, identificare i colli di bottiglia e affrontarli in modo incrementale.
Ogni miglioramento rivelava nuovi ostacoli, richiedendo ulteriori azioni. Non era un gioco del tipo "colpisci la talpa", ma un processo deliberato per fare la cosa giusta al momento giusto.
Ad esempio, imporre la copertura dei test unitari senza migliorare la progettazione del codice avrebbe portato a frustrazione e a una "copertura di facciata" (test superficiali scritti solo per soddisfare le metriche). Affrontando prima l'architettura e le competenze, abbiamo garantito progressi significativi.
Guardando al futuro
La vera trasformazione non riguarda un unico grande cambiamento, ma decisioni intelligenti e tempestive che promuovono un progresso continuo. Siamo lieti di condividere il nostro percorso e le nostre intuizioni per aiutare gli altri a intraprendere il proprio cammino verso un cambiamento scalabile e di grande impatto.
Nei prossimi blog 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 un impatto duraturo.
