Uso de Scrum en un proyecto de mantenimiento

Por Vanesa Savino, @VaneSavino

Tags

scrum, adaptación iterativa

Contexto

Yo era parte de un equipo de desarrollo en el que me desempeñaba como analista programadora desde hacía 2 años. Este equipo estaba a cargo del mantenimiento evolutivo de la aplicación más antigua de su organización.

Desafío

Junto con un compañero nos encontrábamos cursando las últimas materias de la carrera de Ingeniería en Informática. Dentro de los contenidos de esas materias vimos diversos métodos ágiles y nos sentimos motivados para intentar aplicarlos en nuestro día a día con la intención de mejorar nuestra forma de trabajo. Como teníamos un líder de proyecto abierto y flexible le contamos lo que habíamos aprendido, y nos permitió realizar una presentación de Scrum al resto del equipo. A todo el grupo le interesó nuestra propuesta y decidimos intentar aplicarla.

Solución

En el camino, adoptamos, descartamos y retomamos diversas prácticas. Resumo aquí algunos de esos idas y vueltas:

En un principio nuestros sprints eran de una duración variable de entre 2 y 3 semanas, como consecuencia de esta variación a veces incluíamos menos tareas de las que podíamos realizar en los sprints de 3 semanas y nos excedíamos de trabajo en los sprints de 2 semanas. Para solucionar este problema decidimos fijar la duración del sprint en 2 semanas y comenzamos a estimar las tareas de acuerdo a ese tiempo.

Durante las daily meeting los miembros del equipo se sentaban y explicaban las dudas o problemas que habían surgido durante su trabajo. Esto generaba que el resto de los asistentes perdiera su concentración, muchos miraban sus monitores o hacían otras cosas; no escuchaban activamente a la persona que estaba hablando y cuando se les preguntaba por algo que se había mencionado, no lo recordaban. Para solucionar este inconveniente comenzamos a realizar las reuniones de pie y limitamos su duración a 15 minutos. El interlocutor tenía una pelota de tenis que se iba pasando de mano en mano para tener presente que debía ser conciso cuando tuviera la palabra. De esta forma podíamos mantener la atención de los integrantes y todos recordaban los temas que se habían hablado. También escribíamos una minuta de la daily meeting, pero como luego nadie la leía decidimos descartar esta práctica.

Durante la retrospectiva escribíamos otra minuta de reunión que tampoco nadie leía. Por ello optamos por reemplazarla por carteles con dibujos de colores y frases cortas que se pegaban en las paredes. De esta forma teníamos presente a lo largo de toda la iteración los cambios que queríamos hacer y nos ayudaba a mantenernos enfocados.

Dado que parte de nuestro trabajo consistía en dar soporte al sistema productivo nuestro backlog de trabajo solía recibir ítems no planificados como consecuencia de incidentes urgentes aparecidos en el ambiente productivo. El atender estos incidentes impedía que completáramos todas las tareas comprometidas para el sprint. Para manejar estas situaciones comenzamos a asignar puntos a los incidentes urgentes a medida que surgían, esto nos permitía justificar con evidencia las tareas no resueltas al final de la iteración. Al mismo tiempo comenzamos a dejar cierto margen en la planificación de la iteración para la atención de incidentes urgentes surgidos en el ambiente productivo.

Para tener siempre presente el estado de nuestro sprint implementamos un tablero de tareas visual dividido por franjas verticales de colores diferentes para diferenciar los estados de las tareas: pendiente, en proceso, resuelto por desarrollo, en test y para producción.

También realizamos divisiones horizontales en el tablero para los distintos tipos de tareas: tareas planificadas desde un comienzo para el sprint e incidentes urgentes de producción.

Conclusión

Cuando uno adopta una metodología ágil tiene que tomar en cuenta de hacerlo en forma iterativa, incluyendo en la primera iteración sólo las prácticas que no pueden ser aplazadas, e ir refinando las prácticas que nos sirven con el avance de las iteraciones. Si nos proponemos aplicar todo de golpe podemos frustrarnos y abandonar al poco tiempo, ya que es probable que las cosas no salgan tan bien como las habíamos planeamos. Lo importante de destacar en esta situación es que se puede adaptar la metodología gradualmente, mejorando incluso aquellas situaciones que no pueden resolverse completamente. Esto se logra manteniendo al equipo enfocado en porqué se necesita hacer el cambio y con la participación de todos los miembros.