Sprint Retrospective

Resumen ejecutivo

La intención del documento es reflejar por escrito el trabajo realizado por el equipo y sus procesos, para analizar y observar qué ha ido bien para elogiarlo, qué ha ido mal para tener consciencia de ello y qué hay que mejorar para afrontar de mejor forma el Sprint #3.

Metodología del equipo de desarrollo

En este primer apartado, se procede a analizar con detalle el cumplimiento del equipo ante las normativas declaradas de cara a afrontar el proyecto. Tras ello, se destacan las siguientes:

Gestión de Issues

Tras una mala asignación del Sprint Backlog durante el anterior Sprint y la consciencia del mismo, el equipo de trabajo realizó un replanteamiento del Product Backlog, de tal forma que se solventaran gran parte de los errores cometidos durante el anterior Sprint. En este punto, podemos destacar:

• Repartición de tareas: tras replantear las tareas del Product Backlog y organizar el Sprint Backlog, el equipo de trabajo contempló que habían tareas que podrían haber sido divididas en subtareas, de tal forma que se agilizase el trabajo de las mismas, además de darle otro sentido al Sprint organizando de nuevo las prioridades. Esto consiguió permitir que el nuevo Product Backlog fuese más fácil de trabajar y por tanto, las tareas se completaban con éxito y de forma más rápida.
• Estimaciones de las tareas: seguido con lo comentado anteriormente sobre el nuevo Product Backlog, el equipo de trabajo se comprometió en que todos los integrantes deberían participar en la estimación de tareas, además de aplicar una media aritmética de los resultados para hacer la estimación final. Esto ha conseguido que las tareas hayan sido gestionadas por todos y por tanto todo el equipo es consciente del esfuerzo y el tiempo que necesitan. Además, con el surgimiento de nuevas subtareas, se tuvieron que realizar nuevas estimaciones sobre las mismas.
• Gestión de tareas: aunque hay veces que la gestión de tareas no es la adecuada por faltar algo de contenido en algunas de estas, cabe destacar que también han mejorado. Se crearon nuevos tags, se trabajó en el uso de Markdown para reflejar mejor los detalles, y las descripciones de las mismas se elaboraron rigurosamente por algunos miembros del equipo de tal forma que la persona que tuviese asignada la tarea tuviera las menores confusiones posibles sobre la misma.

Gestión de ramas

Durante el Sprint #2, se ha seguido manteniendo la misma política de ramas (GitFlow), ya que esta funciona especialmente bien en el equipo de trabajo. A continuación, se explayan con rigurosidad los detalles sobre el tema:

• Nomenclatura de las ramas: salvo pequeños casos, la nomenclatura de las ramas en este Sprint se ha respetado mucho más que en el anterior, ya que al mejorar la comunicación con el equipo y realizar una guía de acceso rápido del reglamento y políticas a seguir, la mayoría estuvo al tanto de la normativa a seguir.
• Posición de ramas y cierre: de la misma forma, se ha respetado la división de las ramas desde develop, de la misma forma que antes de subir los cambios de una épica a develop, todas las subtareas deberán integradas en su rama épica correspondiente. De igual manera que en el anterior Sprint, las ramas en las que se haya finalizado el trabajo y se encuentren ya integradas en develop, han sido borradas para la limpieza del repositorio.

Commits y Pull Request

Tras comprobar en detalle algunas de las ramas del equipo de trabajo en los repositorios del proyecto, se puede observar que generalmente se ha cumplido con los establecido. Analizamos en detalle:

• Commits: generalmente, se han encontrado como se despachaba en la normativa, es decir, commits atómicos y sintetizados sobre que se incluye en este. Aunque hay alguna que otra excepción de commits que no siguen ni la estructura adecuada o que no son atómicos, pero son casos aislados.
• Pull Requests: debido a la mejora de la comunicación dentro de los canales ofrecidos en GitHub, el equipo de trabajo ha realizado una gran labor en comunicar mediante Pull Requests los cambios a integrar en otras ramas, arraigado a buenas reseñas por parte de otro miembros del equipo. Además, esta vez dentro del tablero Kanban no han quedado reflejadas las Pull Requests que se realizaban, por lo que el Product Backlog del GitHub Projects se ha respetado. En su lugar, se dedica una columna especial en el Project destinada a las Pull Requests aceptadas.

Commitment Agreement

En términos generales, se puede decir que el cumplimiento ha sido bueno por la mayoría de los miembros del equipo de trabajo, elogiando sobre todo el buen trabajo realizado en la colaboración y la comunicación en este Sprint. Sin duda, la decisión de priorizar GitHub como canal de comunicaciones ha ayudado a mejorar la colaboración y la comunicación del equipo, de tal forma que todo el mundo es consciente del cambio y las solicitudes que se realizar mediante un único medio y por varios como lo realizado en el anterior Sprint.

Sin embargo, también hay que saber reconocer los errores, por lo que a continuación se detallan los cometidos relacionados con el Commitment Agreement:

• Finalización de tareas: aunque ha sido en menor medida, el Sprint #2 se le ha vuelto a quedar grande al equipo de trabajo, al no finalizar algunas tareas asignadas para el mismo, activándose nuevamente el riesgo correspondiente y teniendo que aplicar como plan de contingencia el tener que posponerlas.
• Estándares de configuración: aunque el impacto ha sido más leve, se siguen cometiendo pequeños errores sobre los estándares de configuración en el equipo de desarrollo.

Reflexión del Sprint

El apartado se dedica a hacer una reflexión general sobre cómo ha funcionado el Sprint en términos de interacción con el equipo y los procesos establecidos.

Al comienzo de Sprint, el equipo se encontraba en una situación delicada, al haber fallado en la planificación de Sprint #1. Por ello, el Sprint #2 comenzaba con un acarreamiento de tareas del Sprint anterior, sumado a una reestimación del Product Backlog.

Sin embargo, toda esta nueva estimación ha conseguido que se solventen las tareas con menor esfuerzo y más rápido. Además, la mejora de la comunicación ha permitido la constancia del cambio y el contacto del equipo de trabajo de forma más fácil.

Sin embargo, como se ha comentado en apartados anteriores, el Sprint #2 se vuelve a quedar algo grande, ya que no se han completado las tareas, además de los problemas del entorno de programación que no fueron solventados con tiempo e impidieron seguir un ritmo favorable para trabajar.

• Logros y éxitos:

  • Registro del tiempo: hay que elogiar el buen trabajo realizado para controlar el tiempo. Tras el feedback recibido, se actuó rápido para crear nuevas etiquetas, instalar extensiones, etc. Además, la revisión constante de los coordinadores ha permitido detectar errores de estándares en el Clockify con mucha rapidez.
  • Documentación: como en el anterior Sprint, el equipo de trabajo se puede sentir orgulloso de tener una documentación de calidad, al redactar documentos con rigurosidad, hacer revisiones constantes y aplicar procesos de calidad para el aseguramiento de una buena redacción.
  • Planificación: este también es un gran punto a destacar, ya que la reestimación del Product Backlog, ha permitido mejorar la forma de trabajar de los miembros del equipo, con tareas más sencillas y más detalles, además de gestionar de forma rápida todas las semanas el surgimiento de nuevas tareas tras recibir feedback del profesorado.
  • Mitigación de riesgos: de nuevo, se ha llevado una buena mitigación de riesgos por parte del equipo tras tener un buen plan desarrollado para el mismo.
  • Gestión de la comunicación: este es el punto más destacable de este Sprint. El uso de un único canal común a todos los miembros del equipo, ha permitido mejorar la constancia del cambio y la calidad de la comunicación, con mejor recepción de la información en las tareas, discusiones, etc.
  • Código bien implementado si bien la llegada de código funcional ha sido algo tardía, lo que se tiene de este es bastante sólido, considerando múltiples casos y limitaciones. Asimismo, se han ejecutado sus respectivas pruebas para garantizar su funcionamiento correcto.

• Desafíos y dificultades:

  • Entorno de desarrollo: de nuevo, el entorno de desarrollo ha supuesto un grave problema para un flujo normal de trabajo. A pesar de que se ha tratado de gestionar, ha sido demasiado tarde de cara al entregable cuando se ha conseguido solventar este problema, por lo que algunas tareas de desarrollo se han quedado sin finalizar para el Sprint.
  • Complejidad de las tecnologías a utilizar nuevamente las herramientas que se usan resultan complejas para la mayoría de integrantes del equipo, dificultando la finalización de tareas de desarrollo.
  • Cierre de tareas debido a que los miembros del equipo no siempre estaban disponibles para aceptar las Pull Requests han habido tareas que han permanecido en revisión durante mucho tiempo sin poder cerrarse.
  • Dependencia de tareas algunos integrantes no han podido realizar algunas tareas debido a que para comenzarlas, tenían que esperar a que otro compañero finalizara la suya. Es por tanto que las dependencias entre tareas ha favorecido a que no se hayan terminado todas las tareas previstas.
  • Surgimiento de tareas no contempladas días previos a la entrega el equipo se dio cuenta de que había una tarea necesaria que no había sido contemplada por el equipo

Plan de acción

De esta manera, tras analizar las circunstancias que se han dado durante el Sprint, se puede obtener el siguiente plan de acción, el cual está destinado a anotar aquellas mejoras y consejos para comenzar a tener en cuenta por los integrantes para el próximo entregable, o “start doing”, situaciones que el equipo debería continuar haciendo, o “continue doing”, ya que funcionan y se hacen de manera correcta y acciones que se deben de dejar de hacer porque están perjudicando el desempeño grupal, o “stop doing”.

Con este plan de acción se pretende que todos los miembros del equipo tengan constancia de qué acciones son viables y lo apliquen para siguientes entregables o proyectos. A continuación, se muestra la lista:

START	STOP	CONTINUE
Seguir estándares de configuración rígidamente	Dejar las pull request abiertas por mucho tiempo	Hacer documentos con alta calidad
Agilizar la gestión de errores software	Desinterés por la asignatura de algunos miembros	Mantener una buena comunicación
Seguir el Commitment Agreement	Asignar tareas a quienes más tengan	Registro de horas en Clockify
Finalizar las tareas de Sprints anteriores	Superar las 10 horas semanales	Monitorizar correctamente y semanalmente los riesgos
	Posponer tareas para el siguiente Sprint	Hacer la documentación en Docusaurus directamente