¿Dónde entra el mantenimiento en una iteración?

Todos los equipos tienen que lidiar en ocasiones con bugs e incidencias. Esa recepción no se planea, y en muchas ocasiones, por su naturaleza e importancia para el negocio, hace que tengan que ser acometidas con rapidez, posponiendo en ocasiones el trabajo planificado para una iteración concreta. En el caso de Scrum es el sprint el que sufre.

Existen varias maneras de gestionar los bugs y las incidencias dentro de una cultura ágil. Me gustaría dejar en este artículo una recopilación de ellas. Como conclusión final, me adelanto aquí al final del post, y como en otros muchos aspectos, servirá la que sirva al equipo. Dependerá mucho de la estructura de tu negocio o de cómo estén compuestos los equipos. Algunas de las opciones nombradas podrían encajar y otras quizás estén muy lejos de lo que consideras útil dentro de la cultura ágil de tu equipo. Lo que está claro es que la “fase” de mantenimiento como periodo posterior a la implementación y a la entrega, queda desechada de esta lista. Los desarrolladores tienen que lidiar con bugs e incidencias dentro de la implementación, y defender lo contrario es aferrarse a metodologías predictivas.

Comencemos:

Usar dos equipos diferentes.

Sí, se que suena un poco fuerte, pero en algunos sitios puede encajar tener equipos de desarrolladores y equipos especializados de QA que se dediquen principalmente al mantenimiento. Si te fijas digo, especializados, es decir, no significa que los otros equipos no asuman parte de los bugs e incidencias, sino que habrá un equipo especializado, que podrá trabajar conjuntamente con el resto.

La ventaja que rápidamente viene a la mente es que el resto de equipos se puede centrar más en desarrollar, en seguir adelante, que en corregir los fallos que surgen. Y como la otra cara de la moneda, la desventaja principal, es que esos desarrolladores que no están tan centrados en la resolución de incidencias, se convertirán en generadores de deuda técnica, incluso con más facilidad, ya que hay otro equipo “encargado” de resolverlo.

Además, el equipo de QA no dispone del conocimiento necesario, por muchos pdf’s que haya de documentación, para dar mantenimiento profesional de un producto o proyecto que no han implementado directamente. Se deduce que los equipos de desarrollo tendrá que tomar incidencias críticas, que con el tiempo (al no haberlas tomado en primera instancia) se habrán convertido en urgentes e impactarán a la iteración que tengan asignada.

Y por otro lado, no hay multifuncionalidad en el equipo de QA. Estancarse funcionalmente solamente en la resolución de incidencias chocha contra la multifuncionalidad que proclama, entre otros, Scrum.

Dentro de esta separación, también cabe que haya varios equipos y que unos tomen las incidencias de primer nivel y otros las de segundo y tercer nivel.

Usar dos backlogs diferentes.

Hay que tener en cuenta la volatilidad del soporte. Además de la información que podamos sacar para inspeccionar sobre los productos o proyectos, generalmente el soporte se acaba ahí. Se arregla lo que no funciona y se termina, principalmente, porque lo que tiene continuidad es el proyecto o el producto, no la incidencia.

Por eso, hay quien utiliza dos backlogs, uno para funcionalidades (historias de usuario) y otro para incidencias genéricas.

El primero, además de contener las funcionalidades que se añadirán al producto o proyecto, contiene también las incidencias que afectan al comportamiento de esas funcionalidades. Es priorizado y mantenido en su conjunto total por el Product Owner.

Por otro lado, el segundo backlog contiene las incidencias genéricas. En este caso la persona que lo prioriza puede ser un Product Owner o Scrum Master con conocimiento técnico suficiente, o directamente un miembro del equipo de desarrollo con perfil más experto y capaz de reducir la deuda técnica.

La ventaja principal de este enfoque es que el mantenimiento pasa a estar dentro de las iteraciones de manera natural.

Gestionar los bugs e incidencias con el backlog y con el product backlog.

EL título de esta opción necesita que estés un poco familiarizado con la Scrum Guide, pero no te preocupes, que se entiende muy bien.

En caso de que un bug o incidencia no sea bloqueante o urgente, se añade al backlog, como veíamos en la opción anterior. El Producto Owner, el Scrum Master (si necesario) y el equipo de Desarrollo le darán la prioridad correcta y entrará en la iteración que más convenga.

Pero si el bug o incidencia es bloqueante, entonces, se añade al product backlog dentro de la iteración actual, ya que debe ser tratado inmediatamente. Obviamente, este movimiento hará que algunas funcionalidades previstas para el fin de una iteración no estén listas al haberse caído de la carga de trabajo.

Y lo positivo de este enfoque es que solamente las incidencias críticas modificarán el sprint. El resto de incidencias serán gestionadas en los siguientes según la prioridad que tengan.

Podría ayudar, en caso de usar un panel Kanban físico o digital, representar las incidencias de una manera diferente, por ejemplo de un color más llamativo.

Porcentajes.

Puede ayudar también dejar un porcentaje de horas o de dedicación a nuevas funcionalidades y otro, también definido y acotado, a resolución de incidencias.

La ventaja principal es que la dedicación a incidencias está acotada y puede ayudar mucho a la hora de hacer el reparto de funcionalidades en una reunión de planning. Pero por el otro lado, hace más doloroso la recepción de una incidencia crítica y que las funcionalidades planeadas tengan que verse relegadas a un segundo plano.

Mezcla de las anteriores.

Por supuesto, la combinación de las opciones anteriores puede ayudar a conseguir la manera que mejor se adapte al equipo y al negocio.

Creo que este tema es en ocasiones eludido y que absolutamente todos los equipos tienen que lidiar con él. Definiendo una manera óptima mediante la inspección y adaptación constante hará que tu equipo mejore indudablemente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Crea un blog o un sitio web gratuitos con WordPress.com.

Subir ↑

A %d blogueros les gusta esto: