archivo

Archivo de la etiqueta: incidencia

En el artículo de ayer analicé el tratamiento de las incidencias en un enfoque iterativo incremental cuando las mismas se han detectado en el entorno de producción y se está trabajando en un sprint. En este voy a analizar el tratamiento de las incidencias que aparecen como consecuencias del trabajo que se está realizando en la iteración.

Estas incidencias pueden tener una doble naturaleza: ser resultado de actividades de la iteración (se desarrolla un componente o una pantalla y no funciona bien, se producen efectos colaterales, etc…) o bien ser el resultado de descubrir bugs no relacionados directamente con el sprint y que se han detectando haciendo tareas de testing sobre elementos del sprint.

Como en el caso anterior, resulta complicado dar una receta (no hay tallas únicas).

Mi opinión es que si las incidencias son sobre tareas de la iteración se deben corregir en la iteración, siguiendo el objetivo de que el producto resultante del sprint debería estar en disposición de ser entregado (pasarse a producción), de lo contrario no estamos terminando adecuadamente las historias de usuario y estamos huyendo hacia adelante empujando estas incidencias a futuras iteraciones.

Si las incidencias son externas a la iteración tenemos que evaluar el contexto en el que nos encontramos, es decir, ¿la resolución de la incidencia es sencilla y no impacta en el sprint?, se abordaría sin más, en caso contrario, ¿hay una línea de trabajo dedicada a resolver incidencias? Si la respuesta es afirmativa se crearía una entrada en la pila de tareas pendientes de ese equipo, ¿no existe esa línea?, ¿es crítica? el equipo tendrá que decidir (consultando al product owner) si la trata en la iteración, lo normal es que así sea, lo cual provocará probablemente que alguna tarea de las previstas para el sprint no se lleve a cabo (de ahí la necesidad de informar al responsable funcional).

En un enfoque iterativo incremental hay diversas formas de gestionar las incidencias. Vamos a considerar dos tipos de incidencias y las analizamos por separado: las que se producen sobre la aplicación en el entorno de producción y las que aparecen en la iteración en la que estamos trabajando.

En este artículo vamos a analizar el primer caso, en el artículo de mañana, el segundo.

En función de la criticidad e impacto de cada incidencia se puede decidir incluirlas en la pila de producto para ser tratadas en iteraciones sucesivas o bien trabajar con ellas dentro de este ciclo. En este segundo caso puede impactar sobre los objetivos del sprint porque las historias de usuario y tareas sobre las que se trabaja están adaptadas a la capacidad (velocidad) del equipo de trabajo y esas tareas de más implican que el equipo debe incrementar la velocidad para cumplir los objetivos, a veces se podrá (pero cuidado con la calidad de los resultados) y otras no será suficiente e implicará que alguno de los hitos de la iteración no se puedan ejecutar, salvo que se decida prolongar la duración del sprint.

No estoy hablando de metodologías concretas sino de un enfoque iterativo incremental y que cada cual lo gestione cómo crea que conviene mejor al proyecto y es mejor. Con respecto a retrasar la fecha de finalización del sprint yo no soy partidario, aunque en determinadas situaciones puede ser la mejor opción (no tenemos que encorsetarnos, nos debemos a los proyectos no a las metodologías).

Si se decide trabajar con incidencias dentro de este ciclo existe la posibilidad de tener una persona (o un conjunto de ellas) que se dediquen a corregir las mismas, “fuera” del equipo de personas que trabajan en el sprint. Lo pongo entre comillas porque perfectamente pueden ir rotándose con personal del equipo “principal” o ser parte de hecho de ese equipo principal pero no computarse su esfuerzo en la capacidad del equipo de trabajo (la rotación podría ser incluso dentro del mismo sprint).

El resultado del trabajo de estas personas podría sincronizarse con el sprint, conformar un sprint independiente o simplemente empaquetar incidencias corregidas y decidir el mejor momento para pasar a producción (sin sincronizarse con el sprint o adoptar un enfoque iterativo).

Estas personas podrían ayudar al equipo de desarrollo del sprint en caso de que no entrase suficiente carga de trabajo como consecuencia de incidencias.

La gestión proactiva pretende adelantarse a los posibles problemas que se pueden producir en un proyecto de desarrollo de software o en el ciclo de vida de un sistema de información lo que implica evaluar riesgos y decidir qué estrategia aplicar a cada uno de ellos en función de la probabilidad de que ocurra, de su impacto, del coste de la contramedida, etc…

Pero no se trata solo de de riesgos, se trata también de actuar contra problemas reales que ya tiene el sistema de información: incidencias recurrentes, mala experiencia de usuario, falta de productividad en el uso de la herramienta, problemas de rendimiento, problemas de seguridad, etc…

Actuar de forma proactiva permite actuar con mayor perspectiva haciendo un mejor aprovechamiento de los recursos disponibles, ya que independientemente de los ajustes que sean necesarios realizar, se trabaja sobre un plan.

La gestión reactiva se basa en dar respuesta a las incidencias, problemas y riesgos conforme van apareciendo y materializando. A nivel de gestión es mucho más simple, se trata de evaluar cuáles son los fuegos que tenemos en cada momento y dirigir los equipos a los focos más problemáticos.

Este modelo de gestión hace que el sistema se encuentre en una permanente crisis, que será más o menos acusada en función de la calidad (o no calidad) del mismo, la importancia del proceso o de los procesos que informatiza y el número de usuarios del sistema.

Si un sistema se encuentra en permanente crisis y no se actúa conforme a un plan que priorice las actuaciones sobre las deficiencias ya existentes, así como otras que pueden ocurrir o que están latentes, la evolución del sistema será muy lenta, con alto coste y con mucho desgaste, a lo que hay que sumar el riesgo de que cuando se actúa de manera desordenada y rápida sobre las incidencias y problemas, puede dar lugar a nuevas incidencias y problemas (efectos colaterales) sobre todo en sistemas con una alta deuda técnica.

Hay una cita de Milt Bryce que alerta sobre el riesgo de los gestores que presentan una orientación reactiva: “Ten cuidado con los ‘bomberos’, son probablemente los principales pirómanos”.

Este antipatrón se produce cuando conociendo la existencia de un error en el sistema no se le presta atención o no se considera prioritaria su corrección al asumirse que la ocurrencia del mismo no ocasiona perjuicio al sistema, los usuarios, el servicio que se ofrece y/o la continuidad del negocio, sin haber realizado previamente un análisis del riesgo objetivo del mismo.

Los desarrolladores podemos considerar una incidencia como intrascendente y sin embargo para los usuarios y/o el negocio ser muy negativa. Hay que tener en cuenta que el producto no es para nosotros sino para un tercero y para unos propósitos concretos, por lo que nuestra opinión no es la única que vale a la hora de analizar el impacto e importancia de un error.

Si para el usuario todas las incidencias son urgentes y además también lo son los evolutivos a realizar, toca hacerlo bajar a la realidad de los recursos disponibles y de la metodología utilizada, no será fácil que lo entienda, pero no tendrá más remedio que priorizar.