Ajedrez - antoniomartel.com

Archivos por Etiqueta: Kanban

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.

Estadísticas de uso de Scrum (2014)

Hace algo más de un año, en abril de 2013, publicaba una serie de gráficas y estadísticas sobre el uso de Scrum en los portales de empleo y sus búsquedas en Internet en general. Para hacerlo comencé por la demanda de profesionales que pudieran tener metodologías o técnicas como Scrum, Kanban o TDD. Contabilicé en primer lugar el número de veces que aparecían términos como estos en portales de empleo españoles, británicos y alemanes. Estos fueron los resultados que obtuve en 2013:

Comparativa 2013 de portales de empleo para Scrum, Agile, Kanban, Lean, TDD o PMP

He vuelto a buscar este año las palabras Scrum, Agile, Kanban, Lean, TDD, PMP, RUP y Waterfall en los portales de empleo Infojobs.net de España, Monster.co.uk del Reino Unido y el Monster.de de Alemania obteniendo los siguientes porcentajes de variación:

Comparativa 2014 de portales de empleo para Scrum, Agile, Kanban, Lean, TDD o PMP

Los términos ‘ágiles’ como Scrum, Agile, Kanban o TDD tienen una importante subida entre los anuncios de demanda de empleo de los tres países. Habría que destacar que mientras que en España la demanda de empleos que requieren de conocimientos en Scrum sube un 35%, en el Reino Unido sólo sube un 8% pero en Alemania baja incluso un 20%. Esto quizás se deba a que son mercados más maduros en los que términos como Scrum y Kanban están siendo sustituidos por otros más genéricos como Agile, que sube un 170% en Alemania mientras que Kanban baja un 19% en Inglaterra y un 9% en Alemania.

He buscado también el uso de estas palabras en todo Internet con la ayuda de Google Trends. Aquí tienen la gráfica de las búsquedas realizadas en Google por ciudadanos de todo el mundo para los términos ‘scrum -espn -rugby’ (para eliminar los resultados del deporte), ‘pmp’ y ‘agile’. Esta es la gráfica:

Incluyo también la gráfica en la que se muestra de qué países provienen las visitas del término Scrum. Es asombroso comprobar cómo una gran parte de las búsquedas proceden de los países del norte de Europa y de otros importantes países en la producción de software como la India o Argentina.

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

¿De qué va a ir todo esto?

Como un entusiasta más de metodologías ágiles como SCRUM, Kanban o Lean Software Development me he animado a crear este blog para contar en él lo que he aprendido en estos años sobre la gestión de proyectos, el desarrollo del software y la calidad del mismo.

Además de aportar mi parecer sobre la industria del software o la gestión de proyectos y servicios tecnológicos quisiera que el blog sirva también para encontrar recursos e información sobre todas estas metodologías y técnicas. No llegará a ser un compendio exhaustivo pero espero que lo encuentren de utilidad.

No pretendo con este blog evangelizar sobre estas prácticas ni teorizar sobre las mismas. Tampoco voy a llenar estas entradas de nombres de artefactos, stakeholders, backlogs sprints planning o burndown graphics ¡Dios me libre! Si algo me gusta de estas metodologías es que no necesitas formarte durante meses  para empezar a aplicarlas. Sólo debes entender sus principios para luego probar, fallar, mejorar, volver a probar, volver a fallar y así continuar mejorando (Kaizen lo llamaría)

Suscríbete