Reflexión fin de ciclo
Los procesos de software utilizan el desarrollo por incrementos del software, esto es por iteraciones o ciclos, como estrategia principal para mitigar el riesgo de una mala identificación de requerimientos.
En una iteración o ciclo el equipo de desarrollo produce un conjunto visible de nuevos requerimientos funcionales que pueden ser entregados y validados por el cliente. En cada ciclo, como regla básica, se selecciona un conjunto de funcionalidades qu se van a agregar al producto, estas funcionalidades se congelan, es decir, no se cambian mientras se termina el ciclo.
Si bien la motivación principal para realizar ciclos o iteraciones cortas está en la producción de un incremento del producto, también es una oportunidad para lograr una mejora del proceso de desarrollo y de la madurez del equipo. Por esta razón, es muy importante que al final de cada ciclo o iteración, el equipo realice una reflexión o postmortem sobre el trabajo realizado y la forma como éste se realizó y que además, proponga mejoras para el siguiente ciclo.
Para realizar esta actividad de reflexión 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: la Retrospectiva de la estrella de mar muy utilizada en las metodologías ágiles y el Postmortem del proceso Team Software process (TSP). (ver las referencias al final).
Retrospectiva de la estrella de mar
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:
Seguir haciendo
Qué de lo que estamos haciendo debemos seguir haciendo porque nos está funcionando para el éxito del proyecto
El equipo debe identificar las actividades o acciones que ya está haciendo y que debería seguir haciendo para, por ejemplo:
- resolver problemas o inconvenientes que estamos tenido?
- mitigar los riesgos que hemos identificado?
- motivar más a los integrantes?
- obtener mejor calidad de lo que producimos?
- aprender más y mejor?
- utilizar mejor las herramientas?
- distribuir mejor el tiempo, planear mejor?
- comunicar mejor?
Hacer Más de
Qué de lo que estamos haciendo debemos hacer más porque nos ayudaría mucho en el éxito del proyecto.
El equipo debe identificar las actividades o acciones que ya está haciendo pero que si hiciera más, sería útil para, por ejemplo:
- resolver problemas o inconvenientes que estamos tenido?
- mitigar los riesgos que hemos identificado?
- motivar más a los integrantes?
- obtener mejor calidad de lo que producimos?
- aprender más y mejor?
- utilizar mejor las herramientas?
- distribuir mejor el tiempo, planear mejor?
Menos de
Qué de lo que estamos haciendo debemos hacer menos porque no nos está ayudando mucho en el éxito del proyecto.
El equipo debe identificar las actividades o acciones que está haciendo pero que podría hacer menos dado que no está siendo tan útil porque, por ejemplo:
- Nos está causando inconvenientes en el grupo?
- No nos está ayudando a que nos comuniquemos bien?
- No nos está ayudando a que identifiquemos los riesgos?
- No ayuda en la motivar de los integrantes?
- No deja que lo que hacemos sea de buena calidad?
- No deja que planeamos bien?
- Se necesita cada vez menos….
Comenzar a hacer
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.
El equipo debe proponer actividades o acciones nuevas que les ayude en el éxito del proyecto para, por ejemplo:
- resolver problemas o inconvenientes que estamos tenido?
- mitigar los riesgos que hemos identificado?
- motivar más a los integrantes?
- obtener mejor calidad de lo que producimos?
- aprender más y mejor?
- utilizar mejor las herramientas?
- distribuir mejor el tiempo, planear mejor?
- comunicar mejor?
Dejar de hacer
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.
El equipo debe identificar las actividades o acciones que ya no se necesitan o que no están aportando al proyecto porque, por ejemplo:
- Nos está causando inconvenientes en el grupo?
- No nos está ayudando a que nos comuniquemos bien?
- No nos está ayudando a que identifiquemos los riesgos?
- No ayuda en la motivar de los integrantes?
- No deja que lo que hacemos sea de buena calidad?
- No deja que planeamos bien?
- No es productivo?
- Ya no se necesita.
Postmortem TSP
Cada nuevo proyecto debe ser una oportunidad para mejorar aprendiendo de las experiencias anteriores. Más aun, cada nuevo ciclo debe permitir un Mejoramiento continuo del proceso que consiste en analizar las oportunidades de mejoramiento y definir como cambiar las prácticas de los integrantes del equipo de desarrollo.
El postmortem es una oportunidad para evaluar:
- El producto producido
- El esfuerzo invertido para hacerlo
- El proceso seguido para hacerlo
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.
Insumos para el postmortem
Referencias
- Scrum: The Art of Doing Twice the Work in Half the Time. Jeff Sutherland. 2014
- Collaboration Explained. Facilitation Skills for Software Project Leaders. Jean Tabaka. Addison Wsley. 2006
- Introduction to the Team Software ProcessSM. Watts Humphrey. Addison Wesley. 2000 Capítulo 10