¿Qué es una retrospectiva de revisión de código?
Una retrospectiva de revisión de código es una reunión en la que el equipo analiza cómo revisa el código, no el código en sí. Pull requests que pasan días esperando, comentarios sin contexto, revisiones que solo miran el estilo: estos problemas casi nunca salen en una retrospectiva de sprint normal, porque se reparten a lo largo de la semana de todos en lugar de estar ligados a un hecho concreto. El tablero tiene cuatro columnas. "¿Qué está yendo bien?" recoge los hábitos de revisión que merece la pena mantener, como una checklist útil o un tono respetuoso. "¿Qué no está yendo bien?" reúne los puntos de dolor, desde pull requests demasiado grandes hasta criterios poco uniformes. "¿Qué podemos mejorar?" convierte todo eso en cambios concretos, como un límite al tamaño de los cambios o un plazo de respuesta acordado. "¿Qué preguntas han surgido?" deja aparcadas las dudas abiertas que el equipo tiene que investigar antes de poder decidir. Hacedla después de una entrega importante, cuando los retrasos en las revisiones empiecen a frenar las entregas o cuando se incorpore gente nueva y haya que poner por escrito los criterios de revisión que el equipo nunca ha documentado. Mantenedla libre de culpas: el tema es el proceso, no los comentarios de nadie en un pull request concreto.
Formato de retrospectiva de revisión de código
¿Qué está yendo bien?
¿Qué está funcionando bien en nuestras revisiones de código?
Empieza por lo que funciona. Pide ejemplos de prácticas de revisión concretas que hayan ayudado y reconoce a las personas cuyas revisiones marcaron la diferencia.
¿Qué no está yendo bien?
¿Qué dificultades o puntos de dolor tuvimos en las revisiones de código?
Crea un ambiente seguro para plantear problemas sin culpar a nadie. Pide ejemplos concretos, como una revisión que tardó días o un comentario con el que no estaba claro qué hacer.
¿Qué podemos mejorar?
¿Cómo podemos mejorar nuestro proceso y nuestras prácticas de revisión?
Pide propuestas concretas y accionables. "Mejores revisiones" no es una acción; "dividir los pull requests que tocan más de una funcionalidad" sí lo es.
¿Qué preguntas han surgido?
¿Qué nuevas preguntas o temas para investigar han aparecido?
Apunta las preguntas que el equipo no puede responder hoy y acordad quién investigará cada una antes de la próxima retrospectiva.
Cuándo utilizar este estudio retrospectivo
- Cuando las revisiones estén frenando las entregas o generando fricciones y queráis averiguar por qué.
- Cuando quieras que los desarrolladores compartan las prácticas de revisión que les funcionan.
- Después de entregas o proyectos importantes, para ver cómo aguantaron las revisiones bajo presión.
- Cuando se incorpore gente nueva y haya que acordar los criterios, las expectativas y los plazos de respuesta de las revisiones.
Preguntas sugeridas para romper el hielo
- ¿Cuál es el código más interesante que has revisado últimamente?
- Si pudieras añadir una funcionalidad a tu editor de código, ¿cuál sería?
¿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
- Mantened la conversación libre de culpas para que la gente opine con sinceridad sobre las revisiones que le resultaron difíciles.
- Reconoce las buenas revisiones, como los comentarios claros o las respuestas rápidas, además de los problemas.
- Implica a todas las personas que escriben o revisan código, incluidos los testers.
- Acordad uno o dos cambios concretos en lugar de una larga lista de buenas intenciones.
- Haced seguimiento de las acciones y revisad su avance en las próximas retrospectivas.
- Rotad la facilitación para que distintas perspectivas guíen la conversación.
Preguntas frecuentes
¿Qué es una retrospectiva de revisión de código?
¿Cuándo conviene hacer una retrospectiva de revisión de código?
¿Qué preguntas hay que hacer en una retrospectiva de revisión de código?
¿Cuánto dura una retrospectiva de revisión de código?
¿En qué se diferencia de una retrospectiva de sprint?
Plantillas relacionadas
Descubre por qué surgen los bugs y evita que se repitan
Retrospectiva de deuda técnica
Detecta, prioriza y planifica cómo saldar tu deuda técnica
Proceso de desarrollo de producto
Aléjate de los sprints y revisa cómo construyes tus productos.
Retrospectiva DevOps
Revisa despliegues, incidentes y traspasos entre desarrollo y operaciones.