Skip to main content

Sprint Retrospective

En esta página se recoge el feedback proporcionado por el profesor y los compañeros relativo a la retrospectiva realizadas por los grupos durante las sesiones de clase. El objetivo principal es identificar los puntos fuertes y aspectos a mejorar de cada presentación, con el fin de aprender de los errores y mejorar en futuras presentaciones.

Feedback del día 07/02​

  • Análisis de rendimiento del equipo. Al menos una trasparencia con horas y productividad de los miembros del equipo.
  • Resultados del análisis del código: medir la calidad.
  • Lecciones aprendidas (de cada problema o global).
  • Medición para saber si está funcionando el mecanismo de solución del problema. Por ejemplo, reducir el tiempo de las reuniones.
  • Reloj del avance del proyecto: avance en tiempo con respecto a lo esperado al final del curso.
  • Realizar seguimiento detallado de los problemas identificados, documentar soluciones y el estado de los mismos.
  • No iniciar retrospectiva con el apartado de lecciones aprendidas.
  • No incluir los riesgos en la retrospectiva.
  • El análisis del rendimiento del equipo no puede ser sólo en base a commits y horas porque se pueden falsificar fácilmente.
  • Medidas cualitativas y cuantitativas también.

Feedback del día 14/02​

  • Se debe realizar un análisis del rendimiento en cada sprint, lo que permite evaluar la evolución del proyecto a lo largo del tiempo. Este análisis debe incluir no solo los tiempos de respuesta de los miembros del equipo, sino también el impacto de las tareas realizadas en el rendimiento general del sistema.

  • En la evaluación individual y de equipo, se mencionó la importancia de explicar cómo las métricas de productividad afectan la valoración del trabajo realizado. Esto implica que el compromiso de cada miembro debe ser medido y visible, de manera que todos comprendan su impacto en el proyecto y puedan ajustar su rendimiento en función del análisis proporcionado.

  • Se destacó la importancia de registrar y comunicar con claridad los motivos por los cuales un miembro no ha podido contribuir al proyecto. Esto es fundamental para evaluar el impacto de cada integrante en el desempeño general del equipo y para garantizar una distribución equitativa del trabajo.

  • La forma en que se presentan los avances influye en la percepción del compromiso del equipo. Se hizo énfasis en evitar desequilibrios en la exposición de la información, lo que puede reflejar desigualdad en la implicación de los integrantes.

Feedback del día 21/02​

  • Destacar los problemas encontrados, no es aceptable comunicar que "no ha habido problemas", pues estos siempre están al acecho, y es necesario evaluarlos minuciosamente con la mayor prontitud y proponer soluciones factibles, además debemos comentar si estas soluciones han surtido efecto, y en este caso, si son definitivas, o simples parches temporales.
  • Es una buena práctica generar gráficas para las métricas de rendimiento, para ser capaces de evaluar la eficiencia de los miembros (tiempo/tarea realizada) y su evolución durante los sprints.
  • Se reitera en definir y comunicar de forma precisa las soluciones a los problemas, detallando métricas, riesgos, procesos y causas específicas para evaluar su efectividad y garantizar un impacto medible de las acciones implementadas.

Feedback del día 28/02​

  • Realizar rankings de trabajadores.
  • Hacer una tabla con el niko-niko, relacionado con la satisfacción de los miembros del equipo.
  • Detallar si los problemas están solucionados, y el proceso para llevar eso a cabo. También decir si la solución ha perdurado en el tiempo, y sigue siendo efectiva.
  • Para analizar el trabjado del equipo, buscar una forma objetiva más que subjetiva, demostrar datos.
  • Poner un sistema de priorización de problemas.

Feedback del día 04/04​

  • Se sugiere estructurar la información sobre problemas encontrados y resueltos en un formato claro: Problema → Solución → Objetivos → Periodo → Trazabilidad.
  • Incluir objetivos claros y periodos específicos para contextualizar mejor el estado del proyecto. Esto permitirá evaluar si las soluciones implementadas están funcionando según lo planeado. Además de listar problemas, plantear posibles mejoras futuras que puedan optimizar el proyecto.
  • Incluir el número de métricas analizadas, pero siempre en contexto. Mostrar tendencias claras: de dónde venimos, dónde estamos y hacia dónde vamos. Esto ayudará a visualizar el progreso de manera más efectiva.
  • No es aceptable que haya personas que no hayan contribuido esfuerzo al proyecto. Se sugiere realizar una reflexión interna y proponer soluciones para mejorar la colaboración y responsabilidad del equipo.

En próximos feedbacks (última actualización: día 10/05), no se ha mencionado nada relacionado con el Sprint Retrospective, ya que este no forma parte de los objetivos establecidos para la presentación.