Retrospectiva de DevOps

Formato da Retrospectiva de DevOps

Implantações bem-sucedidas

O que deu certo nas implantações recentes?

Comece pelo que funcionou nas implantações recentes e pergunte o que levou a esse resultado, para que vocês possam repetir.

Pontos de melhoria

Que desafios enfrentamos e como podemos fazer melhor?

Mantenha o clima sem culpados. Pergunte o que aconteceu e o que dificultou, e procure a lacuna de processo ou de ferramenta por trás de cada problema.

Colaboração e cultura

Como podemos melhorar o trabalho em equipe e construir uma cultura DevOps?

Converse sobre onde dev e ops ainda jogam o trabalho por cima do muro e sobre o que faria da operação do serviço uma responsabilidade compartilhada.

Ferramentas e processos

Como podemos otimizar nossas ferramentas, tecnologias e processos?

Procure etapas manuais que valham a pena automatizar e fluxos de trabalho com passagens demais. Escolha a mudança que economizaria mais tempo ou eliminaria mais risco.

Quando utilizar esta análise retrospectiva

• Depois de um release ou implantação importante, para avaliar como foi.
• Todo mês ou trimestre, para continuar melhorando a forma como vocês desenvolvem e operam software.
• Quando os mesmos gargalos ou falhas continuam aparecendo no pipeline de build e implantação.
• Depois de introduzir novas ferramentas, tecnologias ou processos, para verificar se estão ajudando.
• Depois de um incidente ou indisponibilidade significativa, para encontrar as causas raiz e combinar medidas de prevenção.

Perguntas sugeridas para quebra-gelo

• Se você pudesse automatizar uma tarefa manual, qual seria e por quê?
• Conte um momento recente de "eureka" ou um aprendizado relacionado às práticas de DevOps.

Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →

Ideias e dicas para sua reunião de retrospectiva

• Mantenha um clima sem culpados para que as pessoas contem o que realmente aconteceu durante incidentes e implantações.
• Convide tanto o pessoal de desenvolvimento quanto o de operações. Cada lado enxerga problemas que o outro não vê.
• Dedique a maior parte do tempo ao que mudar, e só o suficiente aos erros passados para entendê-los.
• Dê a cada ação combinada um responsável e um prazo.
• Cite nominalmente quem esteve por trás de releases tranquilos e de correções de incidentes. Esse trabalho muitas vezes passa despercebido.
• Varie o formato de vez em quando para que a retrospectiva não fique cansativa.

Perguntas frequentes