ReflexionFinal
Cada nuevo proyecto debe ser una oportunidad para mejorar aprendiendo de las experiencias anteriores. Más aún, cada nuevo ciclo debe permitir un Mejoramiento Continuo del proceso que consiste en analizar las oportunidades de mejora y definir cómo cambiar las prácticas de los integrantes del equipo de desarrollo.
Las retrospectivas de fin de ciclo son una oportunidad para evaluar y analizar, el proceso que el equipo siguió durante el ciclo:
- El proceso seguido para hacerlo
Independientemente de la herramienta que se utilice para hacer la retrospectiva, es muy importante que antes de comenzar, cada uno tenga claro:
- El producto producido: qué se logró y qué no se logró con respecto al producto. Esto incluye, lo que se implementó y la calidad de lo que se implementó.
- El esfuerzo invertido para hacerlo: se cumplieron los hitos? el tiempo que se estimó fue adecuado? las actividade se cumplieron a tiempo o no?
Estos elementos son todos resultado del trabajo de cada uno de los integrantes del equipo. Haberlo logrado o no es una consecuencia directa de la forma como el equipo trabajó, es decir, el proceso.
La retrospectiva lo que busca es evidenciar cómo el equipo trabajó, lo que hizo y lo que no hizo, para identificar cómo mejorar. Esto incluye: la comunicación, la coordinación, el seguimiento a los riesgos, la distribución de las tareas, el seguimiento a las tareas, las calidad del trabajo hecho, etc.
La clave para el mejoramiento exitoso son los pequeños cambios pero como estos son fáciles de olvidar es necesario escribir el Plan de Mejoramiento ( PIP: Process Improvement Proposal) e incluir las acciones en el plan del ciclo.
Existen varias herramientas metodológicas que ayudan a que el equipo pueda realizar una discusión honesta y constructiva sobre el trabajo hecho en el ciclo y encuentre cómo plantear acciones de mejora buscando ser más efectivos, más eficientes y más felices (motivados y entusiastas). Vamos a ver dos de estas herramientas muy utilizadas en las metodologías ágiles:
- Retrospectiva de la estrella de mar
- [DAKI: Drop, Add, Keep Improve] (https://dc-consultants.net/animate-an-agile-retrospective-with-daki-retrospective )
Una retrospectiva es un análisis que se hace sobre actividades pasadas. La retrospectiva de la estrella de mar es una herramienta utilizada en las metodologías ágiles, especialmente en Scrum. Se llama de la estrella de mar porque tiene cinco (5) ejes de análisis. La retrospectiva consiste en completar los ejes de la estrella a partir de las opiniones de los miembros del equipo y de la discusión que se realice entre todos. La figura muestra los ejes con los nombres propuestos para realizar la discusión y el análisis.
Figura 3
El análisis consiste primero en ser conscientes de las tareas, acciones, actividades que realizamos o que pensamos que realizamos durante el ciclo.
Previo a la reunión, es importante tener el listado de las reglas de funcionamiento para ver si estamos cumpliéndolas o no, o para ver si, de pronto, están mal definidas o nos faltan algunas. Igualmente, deberíamos tener claros los objetivos que nos planteamos, lo que obtuvimos, ojalá con métricas sobre lo que pasó y por supuesto, la opinión de cada uno sobre cómo le fue en el ciclo, cómo fue su relación con los demás en términos de entendimiento, comunicación, colaboración, etc.
Por ejemplo, para ilustrar, supongamos que en un equipo de desarrollo donde los integrantes son Juan Luis, Luisa y Pedro y lo siguiente es la preparación para la reunión de la retrospectiva:
Reglas de funcionamiento:
- Asistir a las reuniones de manera puntual
- Comunicar de manera constante los avances en la herramienta de seguimiento
- Entregar a tiempo
- Utilizar los issues de github para comunicar problemas potenciales o "bad smells" en el código
Objetivos del ciclo:
- Disminuir el porcentaje de issues
- Mejorar el cubrimiento de las pruebas en un 15%
Al final del ciclo tuvimos:
- Efectivamente un incremento en el cubrimiento de las pruebas pero no alcanzamos al 15%.
- Algunas tareas no fueron lo suficientemente detalladas y crearon confusión y ambigüedad que retrasó el trabajo.
- El riesgo del desconocimiento de la tecnología se disparó en el caso de Juan.
Algunas opiniones individuales al final del ciclo:
- Juan reconoce que su trabajo hubiera podido ser mejor si hubiera trabajado más en los talleres de tecnología.
- Luisa piensa que Pedro no fue de gran ayuda a la hora de sincronizar las partes
- Luis cree que a su liderazgo le faltó estar más pendiente de las entregas de cada uno y de la calidad.
- Pedro cree que él hubiera debido hacer más pruebas unitarias sobre su código.
Teniendo en cuenta este escenario vamos a describir los ejes y a identificar acciones concretas que el equipo tendrá que hacer.
El propósito es identificar qué acciones, tareas, actividades, de las que estamos haciendo debemos seguir haciendo porque nos están funcionando para el éxito del proyecto.
En la reunión, el equipo se da reconoce que:
- Las reuniones semanales son muy importantes, así como el que todos sean puntuales. Se concluye que esto es algo que debemos seguir haciendo.
El propósito es identificar qué acciones, tareas, actividades, de las que estamos haciendo debemos hacer más porque nos ayudaría mucho en el éxito del proyecto.
En la reunión, el equipo se da cuenta que ha debido hacer más:
- Seguimiento a las acciones de mitigación de los riesgos, quizás esa tarea se estaba haciendo muy informalmente y hay que hacer más de ella.
- Desarrollar, más pruebas unitarias para lograr la calidad esperada.
- El líder debe conversar más con su equipo para tratar de identificar problemas y debe revisar el cronograma para verificar el cumplimiento de las entregas.
- Detallar las tareas para que cada uno sepa exactamente que se espera que haga. Debe ser claro cada entregable o el resultado de cada tarea.
El propósito es identificar qué de lo que estamos haciendo debemos hacer menos porque no nos está ayudando mucho en el éxito del proyecto.
En la reunión, el equipo se da cuenta que debe:
- Demorar la integración de cada uno en el repositorio de fuentes
- Dejar pasar defectos al revisar el código y no anotar en github todos los issues
Cuáles actividades o acciones no estamos haciendo y creemos que deberíamos comenzar a hacer porque nos va a ayudar mucho en el éxito del proyecto.
En la reunión, el equipo se da cuenta que debe comenzar a:
- Medir el tiempo que invierte en las tareas
- Definir etiquetas sobre las tareas de acuerdo con algunas categorías como desarrollo, pruebas, gestión, para identificar en qué se gasta la mayor cantidad de tiempo.
- Revisar los issues en Sonarqube e ir planeando quién y cuándo los va a ir resolviendo.
Qué de lo que estamos haciendo debemos dejar de hacer porque no está siendo útil o porque ya no se necesita para el éxito del proyecto.
En la reunión, el equipo se da cuenta que tal vez lo más crítico es la participación comprometida de todos. Entonces ha decidido dejar de:
- No contestar los correos ni participar en las discusiones.
- Subir a github sin haber terminado las pruebas
Esta técnica, utilizada también en las metodologías ágiles, tiene como objetivo ayudar al equipo a identificar aspectos del proceso que se está siguiendo y que llevó a los resultados actuales, pensando en qué deberíamos dejar de hacer (Drop), que deberíamos Adicionar o empezar a hacer (Add), que deberíamos Continuar Haciendo (Keep) y qué deberíamos mejorar (Improve).
Algunos ejemplos pueden ser:
D (Drop) : Eliminar cosas que estamos haciendo y que no nos está ayudando. Ejemplos:
a. No dedicar suficiente tiempo e interés grupal al seguimiento semanal y a la elaboración del plan
b. No estar conectado en los canales del grupo para comunicar avances y/o inconvenientes
c. No estar suficientemente preparado con las tecnologías necesarias para realizar las tareas.
d. No contestar los correos ni participar en las discusiones.
e. Subir a github sin haber terminado las pruebas
A (Add) : Adicionar tareas o actitudes que no estamos teniendo y que creemos puede contribuir con el buen trabajo:
a. Medir el tiempo que invierte en las tareas
b. Definir etiquetas sobre las tareas de acuerdo con algunas categorías como desarrollo, pruebas, gestión, para identificar en qué se gasta la mayor cantidad de tiempo.
c. Revisar los issues en Sonarqube e ir planeando quién y cuándo los va a ir resolviendo.
d. Hacer integración continua
K (Keep): Seguir haciendo:
a. Cumplir los compromisos con el equipo: ir a clase, llegar a tiempo a las reuniones, etc.
b. Actualizar la matriz de traza de requerimientos
c. Colaborar con los demás
I (Improve): QUé podemos mejorar:
a. La colaboración. Por ejemplo, definir parejas de apoyo y seguimiento.
b. La entrega de las tareas a tiempo.
c. La comunicación. Informar si tengo un inconveniente o no he entendido algo de la tecnología.
Este libro fue creado para el curso ISIS2603 Desarrollo de Sw en Equipos en la Universidad de los Andes. © Desarrollado por Rubby Casallas con la colaboración de César Forero, Kelly Garcés y Jaime Chavarriaga. Universidad de los Andes, Bogotá, Colombia. 2019