Estabilizar una aplicación mediante reuniones SCRUM
Por Joaquin Gracia
28 de Marzo de 2005
Primero de todo y antes de continuar, necesitas una herramienta de seguimiento y control de errores. Si no tienes una herramienta de este tipo instalada en tu organización, no hace falta que sigas leyendo porque todo lo que hagas no va a servir de nada.
Puedes encontrar una justificación para implantar una herramienta de seguimiento y control de errores en el mi artículo "Seguimiento y control de errores".
Si has seguido leyendo es porque tienes una herramienta de seguimiento y control de errores.
La creación del equipo
El equipo debe estar formado por el grupo de programadores, el grupo de probadores (también llamados testers) y el líder del grupo, que podría ser el gestor o el programador jefe.
Los roles parecen obvios, los programadores arreglan errores, los probadores prueban la aplicación reportando errores y el líder del grupo es el encargado de que todo funcione como debe ser y no se desmorone.
- Programadores. Arreglan los errores, evidente, no? Es de vital importancia que los programadores solo arreglen errores que hayan sido introducidos mediante la herramienta de gestión de errores.
- Probadores. Aparentemente tendrían un solo cometido que sería la de probar la aplicación buscando errores, pero tienen otro que es igual o más importante que el primero que es el de verificar que los errores arreglados realmente se han arreglado. Esto ocurre porque un porcentaje de los errores que los programadores arreglan no terminan de estar bien arreglados, errores en la reparación de errores. (diabólico pero cierto)
- Líder del grupo. Es una pieza clave en este proceso. Por un lado es el que conduce las reuniones SCRUM, realizando la tarea de facilitador del grupo, procurando que todo el mundo pueda realizar el trabajo lo mejor posible. Por otro lado es el encargado de priorizar los errores, es decir, indicar qué errores son más importantes y por consiguiente se repararán en primer lugar.
Priorizar los errores
Cuando los probadores empiezan a reportar errores, aparecen errores de todo tipo, desde el error que cuelga la aplicación o peor, todo el equipo, hasta el error de que le falta una tilde a tal o cual palabra.
Como nuestro objetivo es estabilizar la aplicación lo más rápidamente posible (véase el título del artículo), lo primero que haremos es indicar a los probadores qué criterios tienen que seguir para priorizar los errores.
Nosotros como líderes del equipo y responsables del proceso repasaremos las prioridades de los errores para verificar que han sido introducidas correctamente y modificaremos las que sean necesarias.
Podríamos establecer muchos tipos de clasificación de errores pero como lo que nos interesa es la estabilización de la aplicación, estableceremos por ejemplo la siguiente clasificación.
| Bloqueantes | Errores que impiden que se siga probando o se sigan arreglando errores, es decir errores que impiden seguir trabajando al equipo. |
| Críticos | Errores de tipo cuelgue de la aplicación, cuelgue del sistema, errores de programación no controlados, etc… |
| Normales | Mal funcionamiento de la aplicación, es decir, la aplicación no hace lo que debería hacer. |
| A partir de aquí no importa mucho para la estabilización de la aplicación pero son útiles para la mejora de la misma. |
| Estéticos | Fallos ortográficos o estéticos como alineación de botones, capitalización de títulos. |
| Mejoras | Sugerencias, mejoras de usabilidad, etc… |
Reuniones SCRUM
Estas reuniones se llevan a cabo hasta que el proyecto está listo para ser lanzarlo al mercado o puesto en producción. Se han de realizar todos los días antes de empezar a trabajar a primera hora de la mañana si es posible.
Primera Reunión
- Explicar al equipo cómo se va a trabajar. Se hace una breve introducción de cómo son este tipo de reuniones, reuniones cortas, no son reuniones para solucionar problemas, tan solo para coordinar trabajo. Si existe algún problema que impida trabajar se expone, para solucionarlo, pero no el trabajo en si. Tienen que servir para organizar no para resolver. Si hace falta una reunión para resolver alguna cuestión relacionada con los errores, se hace después, ya que posiblemente no hace falta que estén todo los miembros del equipo.
- Establecer los criterios para priorizar los errores. Se explica a todos cuál será el criterio para clasificar los errores, basándonos en la tabla anteriormente mostrada.
Primera reunión y siguientes
- ¿Qué es lo que se hizo desde la última reunión? Como las reuniones son diarias no habrá mucho que tratar, es importante destacar que sólo el trabajo que se hizo para la consecución del objetivo es válido. Todo lo demás se verá como un impedimento al objetivo.
- ¿Qué es lo que se va a hacer hasta la siguiente reunión? Es muy importante que quede claro que al salir de la reunión todo el mundo sabe lo que tiene que hacer, y todos están alineados en la misma dirección. La dirección que queremos seguir está clara, estabilizar la aplicación lo antes posible. Para lo cual corregiremos siempre los errores por prioridad, corrigiendo primero los bloqueantes que impiden que el equipo trabaje y seguidamente los críticos que provocan que la aplicación se estrelle.
Mucha gente no sabe organizarse y pierde el tiempo en cosas poco importantes, estas reuniones también sirven para organizar la agenda diaria de cada miembro del equipo y asegurarnos de que todos tienen el mismo objetivo.
- ¿Cómo se va a llevar a cabo? Todo el mundo tiene claro cómo va a hacer lo que tiene asignado, es el momento de que surjan a la luz todos los problemas que tienen las personas para la realización de su trabajo. ¿Existe hay necesidad de máquinas, personas, recursos o tiempo? Si es así el facilitador tiene la obligación de conseguir o si no es posible buscar otras formas de satisfacer esas necesidades.
La finalidad de las reuniones SCRUM es alinear a todas las personas en la misma dirección y sacar a la luz los problemas e impedimentos que hay para conseguir el objetivo.
El éxito de este sistema se basa en arreglar los errores por prioridades, los errores críticos hacen que la aplicación sea más difícil de probar y por tanto no se pruebe bien. Además de bajar la moral del equipo, así que cuánto antes los eliminemos mejor.
Es tu obligación como líder del grupo y responsable de la estabilización de la aplicación que se mantenga esta norma lo más estrictamente posible.
Es muy importante también que no se añadan funcionalidades ni mejoras hasta que la aplicación esté estable, la razón es que podemos multiplicar los errores fácilmente si realizamos modificaciones sobre aplicaciones inestables.
Resumiendo,
las claves de este sistema son:
- Priorizar la resolución de errores
- Mentalidad de equipo, mismo objetivo
- Organización del trabajo
Ya está, ahora solo te hace falta suerte, la vas a necesitar.