4 minuti di lettura
La conoscenza è preziosa, ma il suo vero potere risiede nel modo in cui la mettiamo in pratica. Noi di Freyr conoscevamo bene DevOps, le pratiche ad esso associate e il modo in cui avrebbe potuto trasformare la nostra organizzazione in un centro di sviluppo prodotti altamente performante, in grado di fornire prodotti e soluzioni di qualità ai nostri clienti nel settore delle scienze della vita. All'inizio del nostro percorso, i nostri sforzi hanno gettato delle solide basi, ma sapevamo che per diventare davvero un centro di sviluppo altamente performante avremmo dovuto adottare un approccio più strategico e adattivo.
La sfida principale nel tradurre la conoscenza in azione consiste nel sapere quando fare 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 dal punto in cui ci troviamo come organizzazione, dai nostri processi e pratiche attuali e dalle competenze e capacità del nostro personale.
Questo ha segnato un punto di svolta nella nostra trasformazione. In qualità di fornitore di software specializzato in soluzioni personalizzate, avevamo un team dedicato che si impegnava al massimo per ottenere risultati. Tuttavia, abbiamo intravisto l'opportunità di migliorare la qualità, incrementare la produttività e accelerare la conversione dei requisiti aziendali in prodotti. Invece di concentrarci sulle soluzioni dell'ultimo minuto, abbiamo voluto passare da una soluzione reattiva dei problemi a un'innovazione proattiva, costruendo soluzioni scalabili e di grande impatto.
Avevamo una visione di dove volevamo arrivare: come volevamo lavorare, sviluppare, testare, distribuire e rilasciare software. Tuttavia, sapevamo che per raggiungere questi obiettivi era necessaria una strategia ponderata, un apprendimento continuo e un impegno al miglioramento.
Oggi, nell'ultimo anno, abbiamo realizzato più di 100 release con quasi zero fallimenti di distribuzione e abbiamo raggiunto la quasi totale automazione nell'implementazione delle modifiche. Inoltre, abbiamo registrato progressi significativi in termini di fatturato, team più agili e snelli e uno spostamento generale verso la nostra visione di diventare una powerhouse di prodotti, soluzioni e servizi software. Anche se c'è sempre molto da fare, siamo convinti di aver gettato una solida base 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 che abbiamo imparato. Condividendo il nostro percorso, speriamo di sostenere altri che stanno affrontando cambiamenti simili.
Questa serie di blog è principalmente empirica, e condivide ciò che abbiamo fatto, collegando anche le nostre azioni alle best practice e alle raccomandazioni 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 interconnesse e i cambiamenti in una di esse hanno un impatto sulle altre. Tuttavia, è stato possibile apportare modifiche graduali in ciascuna categoria e misurare i progressi verso i nostri obiettivi generali.
Le iniziative di queste categorie spesso dipendevano l'una dall'altra. I cambiamenti in un'area aprono la possibilità di ulteriori miglioramenti in un'altra.
I primi passi
Per creare una base solida, ci siamo concentrati su tre iniziative fondamentali:
- Integrazione delle 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 la titolarità e la responsabilità.
Queste tre iniziative us hanno permesso di ottenere us su:
- Il lavoro da svolgere (requisiti e compiti).
- La qualità del codice (metriche SonarQube).
- Le persone coinvolte (responsabilità del team).
Tra queste, la definizione di chiare responsabilità del team è stata la più impegnativa. Inizialmente, le strutture dei team erano fluide, con persone che si spostavano da un progetto all'altro a seconda delle necessità. Il passaggio a team dedicati con aree funzionali distinte è stato un passo necessario, anche se complicato dall'architettura del prodotto esistente, che non era stata completamente progettata per supportare una chiara responsabilità.
Il ruolo dell'architettura del software
Ci siamo subito resi conto che l'architettura del prodotto era una delle aree più critiche da cambiare. 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 appartenenza del team avevano un impatto limitato.
La riarchitettura del nostro portafoglio è stata un processo complesso. Ha incluso il passaggio completo al cloud e l'inizio della costruzione di applicazioni cloud-native utilizzando un'architettura a microservizi. Questo argomento sarà trattato in un prossimo post. L'aspetto fondamentale, tuttavia, è che i cambiamenti sono incrementali e che alcuni passi devono precedere altri per sbloccare i benefici e compiere ulteriori progressi.
Metriche e miglioramento continuo
Dopo aver iniziato a lavorare sulla riarchitettura (un lavoro 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à per i singoli team.
- Adozione di servizi cloud-nativi.
Non si trattava di mandati rigidi, ma di obiettivi guida per aiutare i team ad allineare i loro sforzi.
Dare potere alle persone
Con l'introduzione delle metriche, è diventato evidente che i team avevano bisogno di supporto per raggiungere questi obiettivi. Ad esempio, mentre la definizione di obiettivi per la copertura dei test unitari e l'automazione dei test API era semplice, il loro raggiungimento era impegnativo, soprattutto per il codice legacy che non era stato progettato per la testabilità.
Per risolvere questo problema, noi:
- Stabilire obiettivi più bassi per il codice legacy.
- Ha organizzato workshop e formazione pratica sulla scrittura di test unitari di qualità e sulla progettazione di codice testabile.
- Ha fornito indicazioni sulla creazione di stub per il test delle API.
- Revisione dei test unitari da parte di architetti senior.
Il triangolo degli strumenti, dell'architettura e delle persone
Un buon esempio dell'interazione tra queste categorie è la gestione del codice e del repository. L'integrazione con SonarQube, che rappresenta un miglioramento degli strumenti, ha rivelato una bassa copertura dei test unitari, che indicava problemi architettonici 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 ramificazione inadeguate. Abbiamo risolto il problema standardizzando le strategie di ramificazione e assicurando l'integrazione regolare del codice nel ramo principale, consentendo alle pipeline CI di eseguire tutti i test.
La giusta sequenza del cambiamento
Un approccio alla trasformazione consiste nell'implementare indiscriminatamente le best practice. Sebbene questo possa portare dei 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 ha rivelato nuovi colli di bottiglia, richiedendo ulteriori interventi. Non si è trattato di un gioco di "whack-a-mole", ma di 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 alla frustrazione e al "teatro della copertura" (test superficiali scritti per soddisfare i parametri). Affrontando prima l'architettura e le competenze, abbiamo garantito progressi significativi.
Guardare avanti
La vera trasformazione non si basa su un unico grande cambiamento, ma su decisioni intelligenti e tempestive che portano a continui progressi. Siamo entusiasti di condividere il nostro viaggio e le nostre intuizioni per aiutare gli altri a percorrere il proprio cammino verso un cambiamento scalabile e di grande impatto.
Nei prossimi blog di questa serie - DevOps for the Win, analizzeremo ogni fase della nostra trasformazione nel triangolo DevOps - Strumenti, Architettura e Persone - che us ha aiutato us un impatto duraturo.
