Ajedrez - antoniomartel.com

Archivos por Etiqueta: mantenimiento

Cómo ser ágiles en proyectos de mantenimiento

Son habituales en la industria ciertos proyectos, denominados de mantenimiento, en los que el trabajo consiste no en desarrollar nuevas funcionalidades al producto sino en realizar correcciones a bugs o las tareas mínimas para lograr que el sistema esté activo y dando servicio las 24 horas.

Pero a veces la carga de trabajo es tan alta, o la organización del equipo no es todo lo eficiente que debería ser, que no hay tiempo para corregir estos problemas de raíz y en lugar de corregir el código que produce los bugs ponemos parches que dan una patada hacia adelante a los problemas. Tampoco tenemos tiempo para refactorizar el código y aumentarle su calidad de forma que el número de errores tan alto que se come todo el tiempo de desarrollo. El problema llega a ser tan preocupante que, incluso cuando nuestro contrato incluye tareas de mantenimiento evolutivo, la corrección de bugs nos consume todo el tiempo disponible evitando que añadamos más valor a nuestro producto.

Si intentamos usar Scrum para poner orden en esto probablemente no nos vaya a funcionar porque semana tras semana nuevas tareas de corrección de bugs nos asaltan de forma urgente en nuestra planificación del sprint impidiendo que lleguemos nunca a cumplirlo. Retomar el trabajo días después hace que tardemos aún más debido a los cambios de contexto y porque nos vemos asaltados de nuevo por más bugs urgentes. Las planificaciones de los sprints no serán nada fiables, el análisis hecho para las nuevas funcionalidades caducará o habrá que revisarlo y ningún sprint se cumple.

Yo utilizaría Kanban en lugar de Scrum en una primera fase de estos proyectos. El uso de Kanban conlleva un menor cambio cultural en el equipo de trabajo y en los clientes y una menor sobrecarga de reuniones pero sobre todo permite una mayor agilidad para dar entrada a tareas urgentes en medio de la carga de trabajo de la semana.

En este Kanban utilizaría tres códigos de tarjetas de colores: Rojo para las tareas de corrección de bugs, amarillo para las tareas que corrigen deficiencias técnicas y code smells en nuestro código y que están haciendo que el código sea difícilmente mantenible o están produciendo bugs de forma continuada. Por último utilizaría el color verde para las tarjetas que implican el desarrollo de nuevas funcionalidades.

Tampoco separaría el equipo en dos partes, uno para corregir bugs y otro para desarrollar nuevas funcionalidades. Hacer eso está reconocido como una mala práctica debido a que los equipos dedicados a los nuevos desarrollos no aprenden lo que pasa cuando se introducen errores y por otro lado se castiga a los equipos de mantenimiento a que sólo arreglan desaguisados y con prisas y tampoco crean nada nuevo que aporte valor y reconocimiento al equipo.

En un principio nuestro Kanban estará lleno de tarjetas de color rojo pero si logramos introducir nuevas tarjetas de color amarillo y subirles la prioridad a aquellas que solucionan un número alto de bugs, en un periodo prudente de tiempo deberíamos conseguir bajar el número de bugs que se están produciendo obteniendo tiempo así para añadir al Kanban más tarjetas amarillas o incluso verdes.

Con el paso del tiempo, nuestro tablero Kanban deberá mostrar un reportorio más amplio de colores en el que finalmente, con suerte, predominará el color verde. Para esto sirven los tableros visuales Kanban, para dar visibilidad a lo que está sucediendo en nuestros proyectos.

Es en este momento, en el que el equipo realiza sobre todo tareas de mantenimiento evolutivo, cuando podríamos volver a pensar en utilizar Scrum para nuestro proyecto bajando un poco el factor de dedicación para solventar aquellas tareas urgentes que nos llegan ahora con menor asiduidad.

SCRUM para proyectos de mantenimiento

Hace algunos días hablaba con un colega en este mundillo ágil sobre si era posible aplicar SCRUM a proyectos en los que, además de las tareas previstas y planificadas, suele haber interrupciones frecuentes para resolver problemas de mantenimiento o corrección de errores. Muchos jefes de proyecto se enfrentan a este tipo de problemas y utilizan diversas aproximaciones para resolverlo. Aquí van un par de ellas:

Sprints cortos

Con esta solución mantendremos las tareas ya programadas en la planificación del sprint. Al tener sprints de 1 o 2 semanas de duración podremos incluir la tarea no planificada como prioritaria en la lista de cosas a hacer en el siguiente sprint. Si el sprint tiene 1 semana de duración tardaremos una media aproximada 3 días laborales en comenzar a acometer la tarea urgente.
Esto funcionaría en un mundo ideal pero no todas las tareas pueden esperar varios días para ser solucionadas. El servicio entero podría depender de ella.

Factor de dedicación bajo

Si sabemos que con frecuencia nos llegarán tareas inesperadas que debemos resolver con mucha rapidez podemos bajar el factor de dedicación durante el sprint para dar ‘hueco’ a la resolución de estos problemas.
Sabiendo que en cada sprint el equipo tiene capacidad para resolver 10 puntos de historias programadas podríamos comprometernos a entregar solo 7 para que el equipo tenga tiempo de resolver las incidencias urgentes. De este modo no fallaremos un sprint tras otro en entregar lo prometido.
En mi opinión esta solución puede ser útil en ciertos proyectos pero puede crear otro problema. Me explico: Habitualmente el factor de dedicación es del 75%, si lo bajamos para poder dedicar un 30% del tiempo del equipo a las tareas urgentes deberíamos aplicar un factor de dedicación del 40-50%. Sobre este 40% aplicamos SCRUM pero ¿cómo se está gestionando el resto del tiempo del equipo? ¿qué sabemos sobre esa pila de tareas que estamos resolviendo sprint tras sprint?

Un equipo separado por cada tipo de tarea

Esta solución consiste en tener un equipo SCRUM para las tareas identificadas y planeadas y un equipo Kanban para las incidencias de resolución urgente. Con Kanban podemos añadir las nuevas tareas a la columna TO-DO a medida que van llegando y así seguiremos su evolución hasta que llegan a DONE. Con esto el equipo será aún más ágil disminuyendo el overhead de reuniones y planificaciones que tiene SCRUM.
Aún sigue existiendo un problema con las tareas no planeadas y es que son eso, no planeadas. En ocasiones el equipo Kanban que da soporte podría estar sobredimensionado para las pocas incidencias ocurridas en ese momento pero una semana más tarde el número de incidencias y su importancia podría ser tan alta que toda ayuda es poca.
Para minimizar estos riesgos podemos apoyarnos en las soluciones anteriores: Un sprint corto para que el equipo SCRUM de desarrollo planifique sus tareas para la próxima iteración y usar también un factor de dedicación un poco más bajo para que el equipo tener un hueco en su planificación para echar una mano si fuese necesario. Del mismo modo, el equipo de soporte puede colaborar con las tareas planificadas para el sprint actual cuando su columna TO-DO se está quedando vacía. Para aprovechar esto al máximo sería bueno que los miembros de cada equipo se intercambiasen de vez en cuando para que todo el mundo conozca todos los aspectos del trabajo.

Suscríbete