Skip to main content

Sebbene DevOps sia ampiamente riconosciuto per snellire la distribuzione del software e migliorare la qualità, creare un team davvero efficace va oltre l’implementazione di un singolo strumento. Si tratta di una combinazione strategica dei giusti elementi: cultura, processi, collaborazione e tecnologia. Questo articolo esplora i componenti critici di un team DevOps ad alte prestazioni e offre spunti su come le organizzazioni possano integrarli per ottenere risultati ottimali.

Per questo Q&A, abbiamo parlato con David Brooks, Senior Vice President of Evangelism presso Copado. Veterano di 35 anni nella Silicon Valley, è entrato in Copado nel 2018 per creare la pratica di Product Management e ha guidato il team di prodotto per quattro anni. Brooks è entrato in Salesforce.com nel 2005 per lanciare l’AppExchange. In qualità di Vice President of Product, ha guidato i team che hanno costruito la piattaforma Force.com durante i suoi nove anni di permanenza in Salesforce.

Grazie mille per aver parlato con noi! Prima di entrare nel vivo, ci racconti il tuo percorso personale? 

Want more from The CTO Club?

Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.

This field is for validation purposes and should be left unchanged.
Name*

Ho conseguito un master in Ingegneria Elettrica presso l’Università di Auburn nel 1984. La mia tesi era un sistema operativo multiprocessore tollerante ai guasti per la difesa contro missili balistici. 

Mi sono trasferito nella Silicon Valley, lavorando per otto startup con tre exit di successo fino ad ora. Sono anche entrato in Salesforce poco dopo la quotazione in borsa nel 2005. Ho guidato i team che hanno lanciato AppExchange e poi la piattaforma Salesforce. Ho ricoperto principalmente ruoli di leadership senior in ingegneria e product management, anche se sono stato fondatore e CEO di due aziende. 

Nessuno di noi può raggiungere il successo senza un aiuto lungo la strada. C’è una persona in particolare che ti ha aiutato a diventare chi sei?

Ci sono due persone significative. Chuck Comiso era il CEO di Link Technologies, dove gestivo lo sviluppo prodotto. Era un manager HP della vecchia scuola. Chuck mi ha insegnato molto sulla gestione delle persone. Ted Elliott era l’amministratore delegato di JobScience ed è oggi CEO di Copado. Ted mi ha insegnato a concentrarmi sulle cose importanti e cosa serve per far crescere una startup.

Quali tre punti di forza, competenze o caratteristiche ti hanno aiutato a raggiungere questo punto della tua carriera? Come possono gli altri sviluppare attivamente queste aree?

Curiosità, comunicazione e creatività. Sono naturalmente curioso e un apprendista per tutta la vita, un dono che apprezzo molto. Ho anche la capacità di comunicare con le persone in modo che possano comprendere. Parlo cinese e ho imparato a essere paziente con chi parla inglese come seconda lingua. Questo si traduce anche nella capacità di spiegare idee tecniche a persone non tecniche.

Spesso le persone sono così occupate a pensare a cosa dire dopo da perdere la questione centrale della conversazione. Infine, poiché ho tanti interessi, riesco a mettere insieme idee in modi nuovi. Quindi la mia creatività si traduce nella capacità di sintetizzare molte informazioni in una nuova applicazione.

Quali competenze stai ancora cercando di migliorare oggi?

Sicuramente la comunicazione. Recentemente sono passato a un nuovo ruolo come Technical Evangelist, che richiede di alzare il livello nella comunicazione delle idee chiave che rendono Copado diversa. Sto anche guidando il nostro progetto in Cina, quindi il mio cinese verrà messo alla prova.

Parliamo di come avere un team DevOps di successo. Quali obiettivi chiave dovrebbe identificare un team DevOps in un percorso di trasformazione digitale?

Penso che chiarezza e rispetto siano fondamentali. Ottenere chiarezza su ciò che bisogna fare è una questione di priorità, e definisce chiaramente le singole user story e funzionalità. Un ottimo product manager dovrebbe essere in grado di comunicare il “cosa” e il “perché”.

Si parte dalla comprensione profonda del “perché” e facendo sì che team di sviluppo e test lo capiscano anch’essi. Deve esserci rispetto reciproco tra i membri del team, ciascuno deve sapere che la propria opinione conta e che le proprie preoccupazioni vengono ascoltate. Tuttavia, ogni membro deve prendersi la responsabilità di consegnare quanto stabilito e guadagnarsi quella fiducia in ogni sprint. 

Ci sono ostacoli o errori comuni che i team DevOps dovrebbero considerare?

Troppo spesso il product owner comprende male i bisogni degli utenti—non ciò che chiedono, ma ciò di cui hanno bisogno. Mi hanno sempre insegnato a chiedere “perché?” cinque volte. Così si capisce ciò che veramente serve e si può comunicare al resto del team.

L’altro problema nasce quando i membri del team non sono sinceri sulle divergenze. Ho visto sviluppatori dire a un PM che qualcosa non era tecnicamente possibile solo perché non pensavano fosse la scelta giusta. Ogni membro dovrebbe sentire che la propria opinione è considerata e parlare quando non è d’accordo. Alla fine, il leader deve prendere una decisione e il resto del team deve sostenerla.

In che modo una collaborazione e comunicazione efficace tra i membri del team può aumentare la produttività e il successo di un team DevOps, e quali pratiche possono facilitarlo?

Una comunicazione franca e aperta, in cui ogni opinione viene ascoltata e chiunque ha l’opportunità di farsi sentire, è fondamentale. Anche capire il motivo è importante. Se un membro del team vede un modo migliore per soddisfare un requisito, il gruppo dovrebbe essere aperto all’idea. Spesso si arriva così ad una soluzione migliore in meno tempo.

Che ruolo gioca CI/CD in DevOps e quali sono le best practice per implementare pipeline CI/CD per garantire un processo di rilascio software fluido e affidabile?

CI/CD riguarda il rilascio di molti piccoli cambiamenti. Si inizia definendo le User Stories in modo che possano essere realizzate in poche ore, non giorni, e rilasciate alla fase successiva senza causare interruzioni. Anche il testing automatizzato funzionale e di sicurezza è fondamentale.

I team dovrebbero adottare lo sviluppo guidato dai test affinché la funzionalità possa fluire rapidamente lungo la pipeline. Devono essere stabiliti gate di qualità a ogni fase per garantire che una modifica non possa procedere se non è completa. Un vero CI/CD fino alla produzione non è praticabile in alcuni settori fortemente regolamentati, ma ciò non dovrebbe impedire la pratica per tutte le fasi precedenti alla produzione.

Come può la promozione di una cultura DevOps e di una mentalità orientata in tal senso contribuire al successo complessivo di un team, e quali strategie possono utilizzare le organizzazioni per promuovere questa cultura tra i team di sviluppo e di operations?

Una mentalità DevOps significa che tutti i membri del team hanno un obiettivo comune: consegnare lavori di qualità fino alla produzione. Gli sviluppatori non possono pensare che il loro compito finisca quando inviano le modifiche al repository. La qualità non è responsabilità di una sola persona; è compito di ogni membro del team. Questo, unito a fiducia e apertura al miglioramento continuo, rende il team vincente.

Quali sono le componenti essenziali di un team DevOps di successo? 

1 . Fiducia reciproca—All'inizio della mia carriera, lavoravo in un team in cui i membri non si fidavano completamente l'uno dell'altro. Mettevano continuamente in dubbio le decisioni degli altri e apportavano modifiche di nascosto per "correggere" dei problemi. Questo rallentava lo sviluppo e rendeva l'ambiente di lavoro molto spiacevole. 

2 . Impegno verso gli obiettivi del team - Il lavoro di squadra efficace si basa su obiettivi condivisi. Nella mia esperienza, i team più di successo vanno oltre il raggiungimento personale. Ho visto sviluppatori senior che, dopo aver terminato rapidamente i loro compiti, offrivano supporto e guida ai programmatori junior. Questo spirito collaborativo si estendeva ulteriormente, con sviluppatori che aiutavano i tester a completare l'automazione dei test. Di conseguenza, questo team rispettava sempre gli impegni presi e manteneva un ambiente di lavoro positivo.

3 . Comunicazione chiara - Si possono sprecare molto tempo ed energie quando il team non comunica bene. Tutto parte da una corretta comprensione degli obiettivi. Quando ho iniziato a lavorare con la metodologia agile nel 2006, pensavo che le riunioni di pianificazione degli sprint fossero troppo lunghe e i meeting giornalieri inutili. Non aiutava il fatto che dovessi indossare la foto di un gallo durante la riunione per ricordarmi che ero un osservatore e non potevo parlare.

Col senno di poi, comprendo l'importanza di mantenere tali riunioni brevi, ma ci sono state occasioni perse per chiarire dei punti. Più avanti nella mia carriera, abbiamo utilizzato i daily standup per chiarire le domande. Non vuoi arrivare alla fine dello sprint per scoprire di aver costruito qualcosa di sbagliato.

4 . Miglioramento Continuo - Nessun team è uguale a un altro, e nessun processo unico funziona per tutti. Il movimento Lean Manufacturing dava potere ai lavoratori della catena di montaggio di modificare i processi per renderli più efficienti. Sperimentavano e valutavano se i cambiamenti apportati migliorassero o peggiorassero la situazione. Lo stesso vale per i processi di sviluppo software. Il team dovrebbe misurare i risultati usando strumenti come la Value Stream Mapping per individuare i veri problemi, quindi essere disposto a modificare il processo in modo che abbia senso e rispetti comunque le regole aziendali di conformità.

5 . Spazio sicuro per nuove idee - L'unico modo per far sì che tutti i membri del team condividano le proprie idee è fare in modo che si sentano sicuri nel farlo. Non esistono domande o idee stupide. Spesso un'idea può sembrare impossibile da realizzare, ma se si mettono in discussione pratiche consolidate, si scopre che nessuno sa davvero perché siano state adottate. La peggiore risposta che abbia mai sentito è stata: "Perché abbiamo sempre fatto così." Il bisogno di miglioramento continuo implica che bisogna essere aperti a nuovi modi di pensare. Potresti respingere il 90% delle nuove idee, ma quel 10% può avere un impatto significativo.

Quali tendenze emergenti prevedi nel panorama DevOps che potrebbero avere un impatto significativo sulle strategie di trasformazione digitale in futuro?

L'intelligenza artificiale generativa, senza dubbio. L'uso di prodotti Copilot per generare codice e script di test aumenterà notevolmente la produttività. Tuttavia, bisogna partire da una buona definizione dei requisiti, quindi vedremo grandi miglioramenti negli strumenti a supporto della pianificazione.

La maggior parte dei nostri sforzi futuri sarà focalizzata sull'assicurarsi di fare le cose giuste e di comprendere impatti e dipendenze. La GenAI renderà più semplice la documentazione di una release e migliorerà la nostra capacità di supportare gli utenti generando servizi di aiuto in tempo reale e aggiornati sullo stato attuale delle applicazioni.

Se potessi ispirare un movimento che avrebbe il maggior beneficio per il maggior numero di persone, quale sarebbe? 

Wow! Penso che tutto si possa ricondurre a principi molto semplici. Tratta gli altri come vorresti essere trattato, cioè rispetta il prossimo. Prenditi la responsabilità dei tuoi impegni e mantieni ciò che prometti, ovvero integrità. Concentrati sul successo dei tuoi stakeholder: aiuta loro ad avere successo e conquista la loro fiducia.

Conclusioni

Costruire un team DevOps ad alte prestazioni richiede un impegno deliberato e continuo. Dando priorità agli elementi chiave—cultura, processi, collaborazione e tecnologia—le organizzazioni possono sbloccare tutto il potenziale di DevOps.

  • Valuta la situazione attuale e identifica le aree di miglioramento.
  • Investi in formazione e workshop per promuovere una cultura DevOps collaborativa.
  • Implementa strumenti e automatizza i processi per semplificare i flussi di lavoro.
  • Misura costantemente i progressi e adatta il tuo approccio in base ai risultati.

Per altre interviste e approfondimenti DevOps, iscriviti alla newsletter di The CTO Club.