Retrospettiva DevOps

Formato della retrospettiva DevOps

Deployment riusciti

Cosa è andato bene nei deployment recenti?

Iniziate da ciò che ha funzionato nei deployment recenti e chiedete cosa l'ha fatto funzionare, così da poterlo ripetere.

Aree di miglioramento

Quali difficoltà abbiamo incontrato e come possiamo fare meglio?

Mantenete un approccio senza colpe. Chiedete cosa è successo e cosa ha reso le cose difficili, e cercate la lacuna di processo o di strumenti dietro ogni problema.

Collaborazione e cultura

Come possiamo migliorare il lavoro di squadra e costruire una cultura DevOps?

Parlate dei punti in cui dev e ops si scaricano ancora il lavoro a vicenda e di cosa renderebbe la gestione del servizio una responsabilità condivisa.

Strumenti e processi

Come possiamo ottimizzare strumenti, tecnologie e processi?

Cercate i passaggi manuali che vale la pena automatizzare e i flussi di lavoro con troppi passaggi di consegne. Scegliete la modifica che farebbe risparmiare più tempo o eliminerebbe più rischi.

Quando utilizzare questa analisi retrospettiva

• Dopo un rilascio o un deployment importante, per valutare come è andato.
• Ogni mese o trimestre, per continuare a migliorare il modo in cui sviluppate e gestite il software.
• Quando gli stessi colli di bottiglia o errori continuano a presentarsi nella pipeline di build e deployment.
• Dopo aver introdotto nuovi strumenti, tecnologie o processi, per verificare se stanno aiutando.
• Dopo un incidente o un disservizio significativo, per individuare le cause principali e concordare come prevenirlo.

Domande suggerite per rompere il ghiaccio

• Se potessi automatizzare un'attività manuale, quale sceglieresti e perché?
• Racconta una recente illuminazione o esperienza di apprendimento legata alle pratiche DevOps.

Desiderate un esercizio di riscaldamento che la vostra squadra possa svolgere, anziché limitarsi a rispondere ad alta voce? Sfogliate gli esercizi per rompighiaccio gratuiti →

Idee e consigli per la vostra riunione di retrospettiva

• Mantenete un approccio senza colpe, così le persone raccontano cosa è successo davvero durante incidenti e deployment.
• Invitate sia lo sviluppo sia le operations. Ognuno vede problemi che l'altro non vede.
• Dedicate la maggior parte del tempo a cosa cambiare, e agli errori passati solo quanto basta per capirli.
• Assegnate a ogni azione concordata un responsabile e una scadenza.
• Nominate le persone dietro i rilasci senza intoppi e la risoluzione degli incidenti. Quel lavoro spesso passa inosservato.
• Cambiate formato di tanto in tanto, così la retrospettiva non diventa ripetitiva.

Domande frequenti