Per anni, il Cultura DevOps sta diventando uno standard e sempre più aziende si rivolgono a questo modello Agile. Questo metodo è adatto alle aziende di servizi IT, che tradizionalmente si occupano di outsourcing?
Una volta adottata questa cultura, ci rendiamo conto che ci sono diverse derive, soprattutto in termini di scadenze e costi. Ciò che sembra ovvio sulla carta non funziona necessariamente come descritto: spesso utilizzato nel contesto di un prodotto, a volte è difficile coinvolgere i team e l'organizzazione quando si fornisce un servizio o quando tutti gli strumenti e le competenze non sono già presenti in azienda. Inoltre, questo cambiamento di paradigma può essere costoso in termini di costruzione di un ecosistema il più efficace possibile.
Il forte accelerazione del cloud pubblico ha reso questa cultura ancora più importante: un migliore "time to market", i vantaggi del CI/CD e l'infrastruttura "on demand" sono ora essenziali se vogliamo rimanere competitivi, sperimentare rapidamente e consegnare più velocemente.
Tuttavia, stiamo assistendo a uno scontro culturale tra ITIL e AGILE. Entrambi hanno vantaggi e svantaggi: mentre ITIL sostiene il controllo dei cambiamenti e la padronanza delle date, AGILE enfatizza i processi iterativi, la sperimentazione e la velocità di implementazione.
Adottando un approccio agile all'outsourcing IT, abbiamo individuato rischi e slittamenti nella tabella di marcia. L'argomentazione: "Lei capisce, caro cliente, che non possiamo finire il progetto in tempo perché la user story è slittata allo sprint successivo" è difficile da accettare...
L'attività storica di Cloud Temple è l'hosting in modalità Private Cloud e la gestione delle strutture secondo gli standard ITIL. Successivamente si sono aggiunte competenze di Public Cloud e di sviluppo software.
Naturalmente, abbiamo dovuto trasformare la nostra organizzazione per trovare il miglior equilibrio. Poiché i nostri esperti tecnici di Public Cloud sono persone DevOps, sono "intrinsecamente" agili.
Verso un'organizzazione ibrida
Per realizzare questa trasformazione aziendale e combinare DevOps con il rispetto dei vincoli dei nostri clienti, noi, come molti altri, abbiamo guardato al noto modello di Spotify. Dopo aver analizzato la loro organizzazione attraverso i numerosi articoli esistenti, ci siamo resi conto che la maggior parte degli elementi poteva essere utilizzata nel nostro contesto, ma non senza grandi adattamenti.
Volevamo anche rimanere agili, ma limitare il numero di processi, riunioni e strumenti. Ci siamo quindi rivolti a Agile moderno che consiste nel purificare l'Agile "classico" per concentrarsi sui valori di questa metodologia.
La nostra organizzazione si basa quindi su squadre, gilde e un unico strumento di gestione dei progetti: Schede Azzurre.
Squadre del Tempio delle Nuvole
Come veri e propri centri di competenza, abbiamo scelto di raggruppare tutti i nostri esperti in team forti e autonomi che si autogestiscono dal punto di vista tecnico. Di conseguenza, ogni fornitore di cloud pubblico (Azure, AWS, GCP, Alibaba) ha il proprio team di esperti. squadra dedicata i cui membri progrediscono insieme, aiutandosi, sfidandosi, rivedendosi e condividendo le proprie conoscenze ed esperienze man mano che i progetti avanzano.
I ruoli della squadra sono ben definiti: architetti, costruttori, corridori. Ma la vicinanza delle persone coinvolte e il fatto che lavorino insieme significa che le informazioni e le conoscenze possono essere condivise quotidianamente, in modo che tutti possano fare progressi. In questo modo, abbiamo creato un vero spirito di squadra e di solidarietà con un obiettivo comune: progresso ogni giorno per migliorare costantemente la qualità del nostro servizio.
Naturalmente, la ripartizione delle attività è chiara e conosciamo la nostra capacità di produzione mensile. Tuttavia, questa vicinanza significa che i runner e i costruttori possono contribuire alle architetture. Allo stesso modo, i nostri architetti e costruttori sanno che faranno delle escalation. Visitare abbattere le barriere e aiutarsi a vicenda sono diventati valori fondamentali della nostra cultura.
Le corporazioni, garanzia di conformità
Ogni esperto fa quindi parte di una Squadra che impiega 80% del suo tempo per supportare i nostri clienti nei nostri vari servizi. Allo stesso tempo, ogni esperto fa anche parte di una o due gilde che occupano 20% del loro tempo.
Di conseguenza, esperti di diversi team (Azure, AWS, ecc.) lavorano insieme per contribuire alla standardizzazione, alla documentazione e al miglioramento degli elementi tecnici di strutturazione che serviranno a tutti i nostri clienti (monitoraggio, backup, modelli, container, industrializzazione, ecc.) Questo tempo è gestito da ciascun membro del team in modo totalmente autonomo, a seconda del progetto del cliente; abbiamo ritenuto fondamentale garantire la qualità degli standard per la maggior parte degli elementi strutturanti e incoraggiare un approccio di miglioramento continuo.
Ogni argomento della gilda viene implementato nello stesso modo per ogni nostro cliente. Questo semplifica e ottimizza le fasi di compilazione, attingendo agli standard prodotti dalle corporazioni. Anche l'esecuzione beneficia di queste best practice, perché le implementazioni sono uniformi da un progetto all'altro.
Lavoriamo in iterazioni di quattro mesi, con un kick-off per stabilire gli obiettivi di ogni gilda e il valore che apporterà all'azienda. Viene redatto un backlog con le priorità.
Quando vengono pianificati gli sprint di ogni squadra, tutti sanno che dovranno occuparsi di User Stories fino a 20% della loro capacità.
Ogni mese si tiene una riunione di sincronizzazione per fare il punto sui progressi. Alla fine di ogni iterazione, si tiene una revisione davanti ai team per condividere il lavoro svolto, che sarà utilizzato per tutti i progetti. Oltre alla documentazione tecnica prodotta, le conoscenze vengono diffuse durante la presentazione.
Naturalmente, i problemi dei nostri clienti rimangono prioritari e i contributi alle gilde non possono essere erogati in caso di frana. Il tutto sarà poi compensato in un periodo più calmo. Soprattutto, l'obiettivo non è quello di mettere sotto pressione gli esperti della gilda (hanno già abbastanza pressione sulle spalle per i progetti dei clienti), ma piuttosto di aiutare il team a crescere e a migliorarci tutti.
Che ruolo hanno i nostri project manager?
In Cloud Temple abbiamo anche un team di project manager che lavorano in tutta l'azienda. Sono responsabili della pianificazione e della gestione dei nostri progetti.
Come le squadre tecniche, sono autonome nella loro organizzazione, ma la vicinanza stimola una standardizzazione degli strumenti, dei metodi e dei supporti utilizzati per i diversi progetti.
Quindi, quando un project manager viene assegnato a un progetto, si allinea con il leader della squadra tecnica sulle risorse disponibili e pianifica il lavoro in base alle milestone di cui è garante il cliente. In questo modo, garantiamo che la pianificazione avvenga in anticipo rispetto alla fase, e che gli sprint vengano completati in base ai requisiti del cliente, anziché su base ad hoc come nello Scrum tradizionale.
Naturalmente, a meno che il cliente non abbia delle scadenze nel suo programma, gli esperti tecnici rimangono liberi di organizzare il loro lavoro, purché rispettino l'ambito dello sprint e il piano del progetto. Mantengono questa autonomia agile, ma all'interno di un certo quadro di riferimento, che garantisce che le sfide del cliente siano soddisfatte. Non abbiamo quindi uno Scrum Master nei nostri team, perché i project manager riempiono gli sprint in base alle capacità, garantendo così la fattibilità delle operazioni.
Azure Boards è il nostro strumento di gestione dei progetti. Le User Stories vengono pianificate non appena i progetti vengono firmati e le date chiave vengono indicate all'inizio, in modo da avere visibilità su diverse settimane per ogni risorsa. Con il contributo dei team e di alcuni cruscotti, siamo in grado di consolidare il nostro Activity Report (ARC) nello strumento e di avere una visione chiara delle nostre proiezioni e capacità. Questo limita il numero di strumenti che utilizziamo e ci fornisce un quadro di riferimento comune.
Una formula che funziona!
Quindi sì, abbiamo "stravolto" il manifesto agile e il modello Spotify per mantenere solo ciò che volevamo. Abbiamo scelto di concentrarci sui valori in cui i nostri dipendenti e clienti possono identificarsi, invece di copiare e incollare un modello prestabilito. Questo ci ha permesso di sviluppare le nostre competenze e di mettere in piedi un'organizzazione efficiente.
Oggi siamo convinti che il modello che abbiamo sviluppato per la nostra azienda concili il nostro business con la cultura dei nostri dipendenti, fornendo al contempo valore ai nostri clienti. Ogni giorno, i nostri numerosi progetti di Public Cloud ci permettono di mettere alla prova questa organizzazione e di supportare i nostri clienti nei loro progetti di trasformazione.
