Retrospectiva DevOps

Formato de retrospectiva DevOps

Despliegues exitosos

¿Qué salió bien en los despliegues recientes?

Empieza por lo que funcionó en los despliegues recientes y pregunta qué lo hizo posible para poder repetirlo.

Áreas de mejora

¿Qué dificultades tuvimos y cómo podemos hacerlo mejor?

Mantén un enfoque sin culpables. Pregunta qué pasó y qué lo complicó, y busca la carencia de proceso o de herramientas que hay detrás de cada problema.

Colaboración y cultura

¿Cómo mejoramos el trabajo en equipo y construimos una cultura DevOps?

Habla de dónde desarrollo y operaciones siguen pasándose el trabajo por encima del muro, y de qué haría falta para que operar el servicio sea una responsabilidad compartida.

Herramientas y procesos

¿Cómo podemos optimizar nuestras herramientas, tecnologías y procesos?

Busca pasos manuales que valga la pena automatizar y flujos de trabajo con demasiados traspasos. Elige el cambio que más tiempo ahorre o más riesgo elimine.

Cuándo utilizar este estudio retrospectivo

• Después de un lanzamiento o despliegue importante, para revisar cómo fue.
• Cada mes o trimestre, para seguir mejorando la forma en que construís y operáis el software.
• Cuando los mismos cuellos de botella o fallos se repiten una y otra vez en el pipeline de build y despliegue.
• Después de introducir nuevas herramientas, tecnologías o procesos, para comprobar si están ayudando.
• Después de un incidente o una caída importante, para encontrar las causas raíz y acordar cómo prevenirlo.

Preguntas sugeridas para romper el hielo

• Si pudieras automatizar una tarea manual, ¿cuál sería y por qué?
• Comparte un momento reciente de "¡ajá!" o algo que hayas aprendido sobre prácticas DevOps.

¿Le gustaría que su equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Eche un vistazo a los rompehielos gratuitos →

Ideas y consejos para su reunión retrospectiva

• Mantén un enfoque sin culpables para que la gente cuente lo que pasó de verdad en los incidentes y despliegues.
• Invita tanto a desarrollo como a operaciones. Cada parte ve problemas que la otra no ve.
• Dedica la mayor parte del tiempo a qué cambiar, y a los errores pasados solo lo justo para entenderlos.
• Asigna a cada acción acordada un responsable y una fecha.
• Menciona a las personas que hay detrás de los lanzamientos fluidos y de la resolución de incidentes. Ese trabajo suele pasar desapercibido.
• Cambia el formato de vez en cuando para que la retrospectiva no se vuelva rutinaria.

Preguntas frecuentes